Konfiguracja wirtualnych hostów

[PapaSmerf 497]

Zastanawiam się, czy w przypadku serwerów, na których stoją prywatne/firmowe projekty, są jakieś przeciwskazania w kwestii przechowywania konfiguracji vhostów w katalogach domowych użytkownika i dołączania ich z głównego pliku konfiguracyjnego?

 

Coś w ten deseń:

include /home/*/config/nginx/development.conf;

Są jakieś minusy takiego rozwiązania (o możliwości nadpisania każdego vhosta wiem i jestem tego świadom)? Robicie coś podobnego w ten sposób?

[Pan Kot 1535]

To będzie straszne co powiem, ale najbezpieczniejszym rozwiązaniem jest użycie frontendu dla usera, bez dostępu do backendu.

 

Ja np. polecam panel ISPConfig, działa z moim ukochanym nginxem, user jest w stanie sobie założyć stronę, ustawić jej limity, klienta ftp, a nawet nginxowe rewrite'y sobie napisać.

 

Poza tym do samej możliwości pisania configów dochodzi Ci jeszcze fakt ich weryfikacji, bo jeśli każdemu z userów dasz możliwość restartowania apache'a/nginxa po każdej zmianie to będziesz miał taki młyn na serwerze, że to poezja, a do tego dochodzi jeszcze sytuacja w której config będzie miał np. syntax errora i usługa już nie wstanie, np. po restarcie.

 

Generalnie, jak nie jeden, to inny, ale panel, obowiązkowo, ew. jak masz siłę to własne rozwiązanie oparte o podobny scenariusz. Przy panelu jesteś swiadomy tego co user może wyklikać, a np. taki ISPConfig pomimo, że udostępnia doklejanie własnych linijek do configów vhostów, to jeszcze je weryfikuje (to czy nginx wstanie po restarcie, jeśli nie - przywraca "fallback"). Poza tym bardziej ufam open-sourceowym rozwiązaniom i ludziom, którzy doprecyzowali co user może wpisać w okienku niż własnym (nawet dość dobrym) skryptom, które mogą nie wychwycić wszystkiego.

 

Korzystając z jakiegoś panelu zawsze jest szansa, że ktoś inny kiedyś już wpadł na podobny problem i go załatał. Stosowanie własnych rozwiązań to takie wpadanie i podnoszenie się z rowów .

Edytowano Październik 5, 2014 przez Archi (zobacz historię edycji)

[PapaSmerf 497]

To będzie straszne co powiem, ale najbezpieczniejszym rozwiązaniem jest użycie frontendu dla usera, bez dostępu do backendu.

 

Ja nie wierzę własnym oczom w to co czytam

 

Ale tam są tylko nasze projekty, dostęp do serwera ma dwie osoby (w tym ja), przy czym tylko jedna do roota (to ja) *. Nie wpadłbym nawet na to, żeby userom coś takiego dać - aż takim wariatem nie jestem.

 

Po prostu szlag mnie trafia, jak po kolejnym commicie, gdzie dodajemy jakiś ficzer mający związek z configiem webservera, muszę grzebać w configach. Poza tym, ułatwiło by nam to wersjonowanie configów np. przy migracji na inną maszynę albo przy przenoszeniu części funkcjonalności.

 

* tak, zostawiam logowanie po ssh dla roota, ale tylko po kluczu

[Pan Kot 1535]

Wiesz, decyzja należy do Ciebie . Jeśli ufasz osobom, które mają dostęp do zmian w configach to możesz zaryzykować, zacisnąć zęby i dostęp dać, chociaż ja nawet w takiej sytuacji preferowałbym dać dostęp po panelu, tym bardziej że wszystko z niego można wyklikać, włącznie z dyrektywami vhosta w nginxie.

[malu 460]

Zdecydowanie porada Archi'ego wydaje się sensowna. ISPConfig3 jest moim zdaniem b. fajny i sporo moich klientów, którzy mają środowiska bardziej dev, aniżeli produkcyjne właśnie z tego korzystają.
Panel ma sporo fajnych ficzerów np. możliwość ustawienia reverse_proxy, gotowe regułki do rewrite www => non-www itd.. (Co prawda niezgodne ze sztuką bo: IfIsEvil )

No i przede wszystkim będzie spełniał Twoje kryteria odnośnie dostępu do doklejania pierdół do configu.

To co Cię interesuje wygląda to mniej więcej tak:
http://prntscr.com/4thwhl

[PapaSmerf 497]

O to mi chodziło - czy poza kwestiami bezpieczeństwa są jakieś inne przeciwskazania. Dzięki chłopaki.

 

Jeśli chodzi o same configi, to tutaj kwestii bezpieczeństwa nie ma - tam stać będą tylko nasze projekty firmowe, a wszystko leci z dev do repozytorium Git (każda zmiana jest widoczna) a potem mamy taki flow:

dev => git => CI => git (prod) => staging => production

Wszystko do leci z automatu (jeśli CI przepuści). Alt tutaj całkowicie odpada jakaś kwestia dopisania czegoś niedziałającego, bo mamy na devie identyczne środowisko jak na staging/prod. Kwestia dopisania czegoś specjalnie to już w ogóle odpada

 

Chodziło właśnie o to, żeby to zautomatyzować - często mamy za dużo zmian w obrębie jednej aplikacji i czasem warto oszczędzić te 30 minut.