Nginx Plus - komercyjny Nginx

[Zoel 9]

http://nginx.com/products/

 

się dzieje.

[HaPe 242]

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

[Zoel 9]

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

[Gość patrys]

Było już dawno, nginx dla DirectAdmin może działać.

[HaPe 242]

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

[Zoel 9]

Skoro jest opcja Plus za $$ to właśnie to by było zapłacenie za htaccess :]

[Pan Kot 1535]

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 Sierpień 24, 2013 przez Archi (zobacz historię edycji)

[Zoel 9]

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.

[chmuri 89]

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

[HaPe 242]

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.

[Pan Kot 1535]

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 Sierpień 24, 2013 przez Archi (zobacz historię edycji)

[HaPe 242]

Jak sprawdzasz zmianę pliku?

[Pan Kot 1535]

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 Sierpień 24, 2013 przez Archi (zobacz historię edycji)

[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

[HaPe 242]

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?

[Pan Kot 1535]

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.

[bermut 18]

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

[Pan Kot 1535]

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 Sierpień 25, 2013 przez Archi (zobacz historię edycji)

[HaPe 242]

A dlaczego trzeba wzorować się na Apachu?

[Pan Kot 1535]

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.

[HaPe 242]

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

[Pan Kot 1535]

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 Sierpień 25, 2013 przez Archi (zobacz historię edycji)

[kafi 2425]

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 Sierpień 25, 2013 przez kafi (zobacz historię edycji)

[Pan Kot 1535]

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 Sierpień 25, 2013 przez Archi (zobacz historię edycji)

[Misiek08 285]

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