Skocz do zawartości
Zoel

Nginx Plus - komercyjny Nginx

Polecane posty

I dobrze chłopaki robią :) Konkurencja dla onapp i litespeed.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Żeby był tak Nginx do Directadmina jak ma to miejsce w przypadku LiteSpeed.. i wsparcie dla .htaccess :)

  • Upvote 1

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

A .htaccess jak ktoś chce to za $ ktoś mu napisze.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Wielki szum o htaccess ogranicza się najczęściej do napisania jednej linijki, żeby serwis w ogóle działał i do kilkunastu jeśli serwis ma być również zabezpieczony z odpowiednimi uprawnieniami.

 

Pomijając fakt, że masz gotowe formułki do znalezienia na googlu, chyba do każdego możliwego popularnego skryptu to zamiana .htaccessu na nginxowy config to też roboty na kilkadziesiąt minut max.

Edytowano przez Archi (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

No tak ale ja mówię o sytuacji gdzie mamy na serwerze np shared i każdy user chce użyć czegoś innego i jest przyzwyczajony do wszędobylskiego htaccessa.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

No to jak już nauczysz się przepisywać htaccess na nginx to możesz się pokusić o plugin do DA aby każde .htaccess parsował do nginxa. Albo zwyczajnie w cronie

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

DA tu raczej nie ma nic do roboty, bo zmianę można zrobić z poziomu SSH czy FTP i wtedy tego nie zauważy. Tak jak Karol wspomniał najlepiej byłoby to oprzeć na parserze w cronie albo na pluginie do nginx działającym live.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Ja to zrobiłem na bazie pliku typu user.vhost, który sobie includuję w głównym bloku server {} usera via include /home/user/system/user.vhost, a zmiana tego pliku automatycznie wywołuje service nginx reload. W ten sposób user może sobie sam definiować regułki i nawet całego swojego vhosta bez dostępu do innych plików i userów. Oczywiście symlink /home/user/system/user.vhost -> /etc/nginx/sites-available/user -> /etc/nginx/sites-enabled/user.

 

Plus ostatnio dodałem do tego fakt, że jeśli reload zwrócił inny kod niż 0 (czyli error) to powraca poprzednią wersję pliku, a user.vhost zmienia na user.vhost.bugged.

Edytowano przez Archi (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

date i stat pliczek.vhost ;). Unix time jest bardziej użyteczny niż większość osób sądzi.

Chyba, że chodzi Ci o sam fakt sprawdzania plików to na początku sobie dodałem moduł do kernela, ale stwierdziłem, że to słabe rozwiązanie i prosty skrypt w bashu sprawdzający działa nieco lepiej.

Edytowano przez Archi (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość patrys

Jezuu jak Ty kombinujesz, moduł do kernela ?

Tak czytam i nie wiem jak to rozwiązanie może działać stabilnie na hostingu współdzielonym ;)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

date i stat pliczek.vhost ;). Unix time jest bardziej użyteczny niż większość osób sądzi.

Chyba, że chodzi Ci o sam fakt sprawdzania plików to na początku sobie dodałem moduł do kernela, ale stwierdziłem, że to słabe rozwiązanie i prosty skrypt w bashu sprawdzający działa nieco lepiej.

A mógłbyś podzielić się tym rozwiązaniem?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Jezuu jak Ty kombinujesz, moduł do kernela ?

Tak czytam i nie wiem jak to rozwiązanie może działać stabilnie na hostingu współdzielonym ;)

Nie bierz tego aż tak dosłownie ;). Na produkcję bym czegoś takiego nie wrzucił, przecież dlatego właśnie bashowy skrypt zrobiłem.

 

A mógłbyś podzielić się tym rozwiązaniem?

 

Cóż... Zobacz:

 

root@archi ~ # date +%s
1377435188
root@archi ~ # stat -c %Y fixpax.sh
1375998906
A teraz prosty skrypt bashowy wrzucony do crona, który co np. 5 min. sprawdza każdy plik *.vhost z /home/*/nginx i jeśli różnica date'a ze statem jest mniejsza niż... no właśnie ;). Reszta już powinna być prosta.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Tak to czytam i mam inną opinię na robienie .htaccess w nginxie. Poczytać można tutaj: http://wiki.nginx.org/LikeApache-htaccess

 

Jeśli rzeczywiście masz taką opinię to nie masz żadnego pojęcia po co i dlaczego powinno się konwertować .htaccess na nginxowy config ;). Nikt tu nie mówi o parsowaniu .htaccess co request bo to rzeczywiście jest bezsens, ale opinia że .htaccess jest zbędne i nie należy w ogóle tego dotykać jest nieco śmieszna ;).

Edytowano przez Archi (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

A dlaczego trzeba wzorować się na Apachu?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

A dlaczego trzeba wzorować się na Apachu?

 

Rewrite? Czysty nginx nie ma żadnych regułek i chociażby przyjazne dla SEO linki Ci działać nie będą. To jest jedna linijka, o której wspomniałem wyżej.

 

A czasem i wiele innych, które są wymagane.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

A dając userowi dostęp do edycji vhosta nie obawiasz się, że podopisuje coś, co może negatywnie wpłynąć na inne vhosty?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

A dając userowi dostęp do edycji vhosta nie obawiasz się, że podopisuje coś, co może negatywnie wpłynąć na inne vhosty?

 

Jeśli blokujesz go w bloku server { } to nie może popsuć czegokolwiek co wpływa na inne bloki server { }. Co najwyżej może popsuć config, a od tego mam fallback.

 

Pewnie, jakby się uprzeć to można to zabusować, ale mam zaufanie do tego co hostuję u siebie. Poza tym nie wiem jaka mogłaby być najbardziej szkodliwa rzecz, którą można wrzucić w blok server { }. Może @patrys mi pomoże :).

Edytowano przez Archi (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Jeśli masz zaufanie, to po co te paranoidalne paxy i inne dziwactwa... Przecież takie mechanizmy stosuje się właśnie przez zasadę ograniczonego zaufania do swoich użytkowników.

 

A co można napsuć w server{}?

Ano chociażby pobawić się dyrektywą root, ewentualnie może jakieś proxy_pass?

Pamiętaj, że w sam daemon www działa sobie dalej na uprawnieniach www-data/nobody,

i statykę serwuje ze wspólnego uid. No chyba, że stawiasz każdemu własną instancję nginx,

a później jakimś frontendowym balancerem dopiero sam routing.

 

Forkowanie odpowiedniego procesu z przełączeniem efektywnego uid w obecnym modelu to też ryzyko,

bo proces master będący pierwszą linią frontu (odbiera request, analizuje hostname i robi forka) musi być

odpalony z uid root'a

 

 

 

A co do głównego tematu - to ciekawie kontrastuje się to z lsws.

Bo w olsws chociaż nie ma obsługi htaccessów, to w konfiguracji vhosta

da się wkleić regułki kompatybilne z Apache i to działa. ;)

Edytowano przez kafi (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

proxy_pass można zabronić, dyrektywę root można ustawić stałą. Symlinka user nie stworzy (chyba, że pointującego do jego folderu/pliku) bo tak działa grsec enforce.

 

P.S. To co napisałem już mam. Myślałem o czymś bardziej złożonym ;).

Edytowano przez Archi (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

include jest odporne na "}"? Czyli user wpisuje location {...}} server{listen 80;...} i to includuje jako kawałek poprzedniego i robi następny blok server{}.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Bądź aktywny! Zaloguj się lub utwórz konto

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto

Zarejestruj nowe konto, to proste!

Zarejestruj nowe konto

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się


×