Vraag Wat is de verschillende gebruiksmogelijkheden voor sites beschikbaar ten opzichte van de directory conf.d voor nginx


Ik heb enige ervaring met het gebruik van Linux, maar geen enkele met behulp van Nginx. Ik ben belast met het onderzoeken van opties voor het in evenwicht brengen van de belasting van een toepassingsserver.

Ik heb apt-get gebruikt om nginx te installeren en alles lijkt in orde.

Ik heb een paar vragen.

Wat is het verschil tussen de map met de beschikbare sites en de map conf.d. Beide mappen zijn INBEGREPEN in de standaard configuratie-instellingen voor nginx. Zelfstudies gebruiken beide. Waar zijn ze voor en wat is de beste werkwijze?

Waar wordt de map met sites voor gebruikt? Hoe gebruik ik het?

De standaardconfiguratie verwijst naar een gebruiker van www-data? Moet ik die gebruiker maken? Hoe geef ik die gebruiker optimale rechten voor het uitvoeren van nginx?


73
2017-07-31 14:20


oorsprong


Vermijd de omvang van kruipen bij het stellen van een vraag; www-data is een apart onderwerp. De meeste besturingssystemen definiëren een afzonderlijke gebruiker met lagere machtigingen die het proces kan uitvoeren als na binding aan poort 80 als root. Het is gedefinieerd in het configuratiebestand. Pas vanaf daar basale beveiligingsprocedures toe; laat de gebruiker niet schrijven naar iets waar de webserver niet naartoe hoeft te schrijven, laat andere gebruikers niet schrijven naar de bestanden, tenzij het opzettelijk is. - Andrew B


antwoorden:


De sites- * mappen worden beheerd door nginx_ensite en nginx_dissite. Voor Apache httpd-gebruikers die dit vinden met een zoekopdracht, zijn de equivalenten dat a2ensite/a2dissite.

De sites-available map is voor opslag allemaal van uw vhost-configuraties, ongeacht of deze momenteel zijn ingeschakeld.

De sites-enabled map bevat symlinks naar bestanden in de map met beschikbare sites. Hiermee kunt u vhosts selectief uitschakelen door de symlink te verwijderen.

conf.d doet het werk, maar je moet iets uit de map verwijderen, verwijderen of wijzigen wanneer je iets moet uitschakelen. De map abstractie-sites maakt de zaken een beetje overzichtelijker en stelt u in staat ze te beheren met afzonderlijke ondersteunende scripts.

(tenzij je bent zoals ik, en een van de vele debian-beheerders die de symlinks net hebben beheerd, niet wetend over de scripts ...)


69
2017-07-31 15:01



Heb ik iets fout gedaan? Het downvote niet begrijpen. - Andrew B
ik ben nieuwsgierig is dit ingebouwd in nginx? ik heb handmatig geïnstalleerd github.com/perusio/nginx_ensite - lfender6445
Het is belangrijk om dat op te merken sites-available|sites-enabled is een Debian-ism en is niet iets dat nginx of Apache doet. Het was in het verleden waarschijnlijk behoorlijk nuttig, maar het nut ervan is enigszins beperkt in een tijdperk van configuratiebeheer en containers. - Michael Hampton♦


Ik zou aan de vorige antwoorden willen toevoegen dat het belangrijkste niet is hoe je de mappen noemt (hoewel dat een erg nuttige conventie is), maar wat je eigenlijk in nginx.conf. Voorbeeldconfiguratie:

http {
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*.conf;
    include /etc/nginx/sites-enabled/my_own_conf;
...
}

De enige richtlijn die hier wordt gebruikt is omvattener is dus geen intern verschil tussen b.v. conf.d/ en sites-enabled/.

Uit de bovenstaande documentatie:

Syntax:     include file | mask;
Default:    —
Context:    any

Includes another file, or files matching the specified mask, 
into configuration. Included files should consist of 
syntactically correct directives and blocks.

Dus, om de oorspronkelijke vraag te beantwoorden: er is geen intern verschil en u kunt ze op de best mogelijke manier gebruiken, denk hierbij aan advies van de andere antwoorden. En vergeet alsjeblieft niet om het 'juiste' antwoord te kiezen.


28
2018-04-16 20:29



Rechts, sites-enabled is enigszins verzonnen door enige betoging, rondslingerend als een vervelende tussenpersoon. Ga nginx pakken de officiële bron: je krijgt een up-to-date product, maar ook het wegwerken van deze configuratie rotzooi / hel. - Bernard Rosset
Dit verklaart waarom er geen enkele verwijzing is naar deze naamconventie in de officiële Nginx-documentatie. Het is een project van derden! github.com/perusio/nginx_ensite - AxeEffect


Typisch, de sites-enabled map wordt gebruikt voor virtuele hostdefinities, terwijl conf.d wordt gebruikt voor wereldwijde serverconfiguratie. Als u meerdere websites ondersteunt, d.w.z. virtuele hosts, krijgt elk een eigen bestand, zodat u ze heel eenvoudig kunt in- en uitschakelen door bestanden in en uit te verplaatsen sites-enabled (of het maken en verwijderen van symlinks, wat waarschijnlijk een beter idee is).

Gebruik conf.d voor zaken als het laden van modules, logbestanden en andere dingen die niet specifiek zijn voor een enkele virtuele host.

De standaardconfiguratie verwijst naar een gebruiker van www-data? Moet ik   creëer die gebruiker?

U moet nginx als een niet-rootgebruiker laten uitvoeren. Dit wordt in sommige gevallen genoemd www-data, maar je kunt het alles noemen wat je wilt.

Hoe geef ik die gebruiker optimale rechten voor   nginx draaien?

Ik ben minder zeker van het antwoord op deze vraag (ik gebruik momenteel nginx niet), maar als het zoiets is als Apache, is het antwoord dat www-data de gebruiker heeft alleen leesbevoegdheden nodig voor statische bestanden (en lees + uitvoer in mappen) die u gebruikt, of lees / uitvoerrechten voor zaken als CGI-scripts en geen rechten elders.


25
2017-07-31 14:59



het hebben van een toegewijde gebruiker voor het uitvoeren van een webserver is ook belangrijk vanwege het uitschakelen van de aanmeldmogelijkheid voor deze gebruiker door geldige shellrecords te verwijderen. - DukeLion
> 'U moet nginx laten uitvoeren als een niet-rootgebruiker' - kunt u hier meer over vertellen? - lfender6445
Uitgevoerd als een onbevoegde gebruiker is een manier om de schade te beperken die zou kunnen voortvloeien uit een compromis op afstand. Als u een webserver draait zoals root en er is een compromis op een of andere manier, de aanvaller heeft onmiddellijk volledige toegang tot het systeem. Bij gebruik als niet-bevoorrechte gebruiker zou administratieve toegang alleen beschikbaar zijn in combinatie met een of andere lokale exploit. - larsks


Wat gebeurd er?

U moet Debian of Ubuntu gebruiken, aangezien de slecht  sites-available / sites-enabled logica wordt niet gebruikt door de stroomopwaartse verpakking van nginx van http://nginx.org/packages/.

In beide gevallen zijn beide geïmplementeerd als een configuratieconventie met behulp van de standaard include richtlijn in /etc/nginx/nginx.conf.

Hier is een fragment van /etc/nginx/nginx.conf van een officieel upstream pakket van nginx van nginx.org:

http {
    …
    include /etc/nginx/conf.d/*.conf;
}

Hier is een fragment van /etc/nginx/nginx.conf van Debian / Ubuntu:

http {
    …
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

Dus, vanuit het oogpunt van NGINX, zou het enige verschil zijn dat bestanden van conf.d moet eerder worden verwerkt, en als zodanig configuraties hebben die in stilte conflicteren met elkaar, dan zijn die van conf.d kan voorrang hebben boven die in sites-enabled.


Best Practice is conf.d.

Je zou moeten gebruiken /etc/nginx/conf.d, want dat is een standaardconventie en zou overal moeten werken.

Als u een site moet uitschakelen, hernoemt u de bestandsnaam om niet langer een .conf achtervoegsel, zeer eenvoudig, duidelijk en foutbestendig:

sudo mv -i /etc/nginx/conf.d/default.conf{,.off}

Of het tegenovergestelde van in staat stellen een site:

sudo mv -i /etc/nginx/conf.d/example.com.conf{.disabled,}


vermijden sites-available & sites-enabled Tegen elke prijs.

Ik zie absoluut geen reden om te gebruiken sites-available / sites-enabled:

  • Sommige mensen hebben genoemd nginx_ensite en nginx_dissite scripts - de namen van deze scripts zijn nog erger dan de rest van dit debacle - maar deze scripts zijn ook nergens te vinden - ze zijn afwezig in de nginx pakket, zelfs in Debian (en waarschijnlijk ook in Ubuntu), en niet aanwezig in een eigen pakket, plus, heb je echt een heel niet-standaard script van een derde nodig om de bestanden eenvoudig te verplaatsen en / of te koppelen tussen de twee mappen ?!

  • En als u de scripts niet gebruikt (wat in feite een slimme keuze is zoals hierboven), dan komt de vraag hoe u de sites beheert:

    • Maak je symbolische links van sites-available naar sites-enabled?
    • Kopieer de bestanden?
    • Verplaats de bestanden?
    • Bewerk de bestanden op hun plaats in sites-enabled?

Het bovenstaande lijkt misschien een paar kleine problemen om aan te pakken, totdat verschillende mensen het systeem gaan beheren, of totdat je een snelle beslissing neemt, alleen om het maanden of jaren later te vergeten ...

Wat ons brengt om:

  • Is het veilig om een ​​bestand van te verwijderen? sites-enabled? Is het een zachte link? Een harde link? Of de enige kopie van de configuratie? Een goed voorbeeld van configuratie-hel.

  • Welke sites zijn uitgeschakeld? (Met conf.d, doe gewoon een inversie-zoekopdracht voor bestanden die niet eindigen op .conf - find /etc/nginx/conf.d -not -name "*.conf", of gebruik grep -v.)

Niet alleen al het bovenstaande, maar let ook op het specifieke include richtlijn gebruikt door Debian / Ubuntu - /etc/nginx/sites-enabled/*- er is geen achtervoegsel voor bestandsnamen opgegeven sites-enabled, in tegenstelling tot voor conf.d.

  • Wat dit betekent is dat als je op een dag besluit om snel een bestand of twee binnen te bewerken /etc/nginx/sites-enabled, en jouw emacs maakt een back-upbestand zoals default~dan heb je allebei plotseling default en default~ opgenomen als actieve configuratie, die, afhankelijk van de gebruikte richtlijnen, u mogelijk zelfs geen waarschuwingen geeft en een langdurige foutopsporingssessie veroorzaakt. (Ja, het is mij overkomen, het was tijdens een hackathon en ik was totaal verbaasd over waarom mijn conf. Niet werkte.)

Dus ik ben ervan overtuigd dat sites-enabled is puur kwaad!


6
2017-08-27 20:08



Naast al het bovenstaande is het blijkbaar ook heel gebruikelijk om onjuiste symlinks te maken! stackoverflow.com/a/14107803/1122270  Voor het geval je het niet dacht sites-enabled was kwaad genoeg! - cnst
Of, soms kan het gebeuren dat iemand besluit om de bestanden te bewerken sites-enabled, maar dan besluit een andere persoon om het uit te schakelen door het te verwijderen, mogelijk denkend dat het slechts een symlink was, waardoor een volgende geheugendump van nginx heap nodig was om het conf-bestand te herstellen: stackoverflow.com/q/45852224/1122270 - cnst
Ik moet het niet eens zijn met de beweringen over sites-available en sites-enabled; het is belangrijk om config-bestanden buiten de 'live' ophaalmap te kunnen voorbereiden, zodat als nginx opnieuw geladen of opnieuw gestart zou worden, het geen gedeeltelijke configuratiebestanden zou oppikken. Het kan ook handig zijn om configuratiebestanden bij te houden die niet langer in actief gebruik zijn. Het maken van symlinks is geen bijzonder moeilijke taak als je genoeg ervaring hebt om nginx in de eerste plaats te beheren, IMO. - BE77Y
@ BE77Y u neemt een meer gecompliceerde aanpak. Bij het programmeren wordt het als de beste praktijk beschouwd om ongebruikte code volledig te verwijderen, niet alleen uit te schakelen of een commentaar te geven; Ik zie geen reden waarom DevOps anders zou zijn - als een configuratie niet langer nodig is, verwijder deze dan (deze moet nog steeds bestaan ​​in je VCS). Hetzelfde met gedeeltelijke conf-bestanden - waarom zou je ze bewerken en nginx herladen achter je rug? (USR1, die logs opnieuw opent, herlaadt conf niet.) Ik vind uw symlink "experience" -reacties verkeerd geadresseerd - het probleem is een kwestie van consistentie, die weinig met ervaring te maken heeft. - cnst
Het is duidelijk dat a) dit niet het juiste medium is voor deze discussie en misschien nog belangrijker: b) het is in elk geval waarschijnlijk vruchteloos. Laten we eens zijn om het oneens te zijn. - BE77Y