Nginx için conf.d dizinindeki vs sitelerde kullanılabilen farklı kullanımlar nedir


98

Linux kullanma konusunda bazı tecrübelerim var ancak hiçbiri nginx kullanmıyor. Bir uygulama sunucusu için yük dengeleme seçeneklerini araştırmakla görevlendirildim.

Nginx'i kurmak için apt-get kullandım ve hepsi iyi görünüyor.

Birkaç sorum var.

Sites kullanılabilir klasör ve conf.d klasör arasındaki fark nedir. Bu klasörlerin her ikisi de nginx için varsayılan yapılandırma ayarlarında DAHİLDİR. Öğreticiler her ikisini de kullanır. Onlar ne için ve en iyi uygulama nedir?

Sitelerin etkin olduğu klasör ne için kullanılır? Bunu nasıl kullanabilirim?

Varsayılan yapılandırma www-data kullanıcısına başvuruyor mu? Bu kullanıcıyı oluşturmak zorunda mıyım? Bu kullanıcıya nginx çalıştırmak için en uygun izinleri nasıl veririm?


Bir soru sorurken kapsamın kaymasını önlemek için deneyin; www-dataayrı bir konudur. Çoğu işletim sistemi, işlemin 80 numaralı bağlantı noktasına root olarak bağlandıktan sonra çalışabileceği daha düşük izinlere sahip ayrı bir kullanıcı tanımlar. Config dosyasında tanımlanmıştır. Temel güvenlik uygulamalarını oradan uygulayın; Kullanıcının, web sunucusunun yazması gerekmeyen herhangi bir şeyi yazmasına izin verme, kasıtlı olmadığı sürece diğer kullanıcıların dosyalara yazmasına izin vermeyin.
Andrew B,

Yanıtlar:


93

Sites- * klasörleri nginx_ensiteve tarafından yönetilir nginx_dissite. Bunu bir arama ile bulan Apache httpd kullanıcıları için, eşdeğerleri a2ensite/ a2dissite.

Bu sites-availableklasör, etkin olan olsun veya olmasın, tüm vhost yapılandırmalarınızı saklamak içindir .

sites-enabledKlasör sites-available klasördeki dosyalara sembolik içerir. Bu, sembolik bağlantıyı kaldırarak vhost'ları seçici olarak devre dışı bırakmanıza izin verir.

conf.dBir işi klasörden çıkarmak, silmek ya da bir şeyi devre dışı bırakmanız gerektiğinde değiştirmek zorundasınız. Sites- * folder soyutlaması işleri biraz daha organize hale getirir ve ayrı destek komut dosyaları ile yönetmenize izin verir.

(benden hoşlanmadığın sürece, ve doğrudan işaretleri doğrudan yöneten, senaryoları bilmeyen birçok debian yöneticisinden biri ...)


12
Yanlış bir şey mi buldum? Olumsuz oyu anlamadım.
Andrew B

1
Merak ediyorum bu nginx içine inşa edilmiştir? el ile kurdum github.com/perusio/nginx_ensite
lfender6445

18
Bunun sites-available|sites-enabledbir Debian-ism olduğunu ve nginx veya Apache'nin yaptığı bir şey olmadığını not etmek önemlidir . Muhtemelen geçmişte oldukça faydalıydı, ancak faydası bir konfigürasyon yönetimi ve konteynır çağında bir şekilde sınırlı.
Michael Hampton

Konfigürasyon yönetiminin ve konteynırların sitelere uygun | sitelere uygun |
karthik vee

1
@karthikvee nokta şu ki sunucular genellikle tek bir web sitesine / hizmetine hizmet veren geçici konteynerler olarak görünüyorlar, bu yüzden nginx.confherhangi bir okunabilirlik kaybı olmadan dahil edilebilir . Bu, birkaç yıl önce, sunucuların normalde onlarca web sitesini saklayacağı yaklaşımın tam tersidir.
adamczi

38

Daha önceki cevaplara, en önemlisi, dizinleri nasıl çağırdığınızı (çok yararlı bir kongre olmasına rağmen) değil, gerçekte ne koyduğunuzu da eklemek isterim nginx.conf. Örnek yapılandırma:

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

Burada kullanılan tek yönerge aşağıdakileri içerir , bu nedenle örneğin conf.d/ve arasında hiçbir iç fark yoktur sites-enabled/.

Yukarıdaki belgelerden:

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.

Dolayısıyla, asıl soruya cevap vermek için: içsel bir fark yoktur ve diğer cevapların önerilerini hatırlayarak bunları en iyi şekilde kullanabilirsiniz. Ve lütfen, 'doğru' cevabı seçmeyi unutma.


1
Doğru, sites-enabledbiraz rahatsız edici bir ara öğenin yaptığı gibi dalga geçerek, bir miktar dağıtım tarafından icat edildi. Resmi kaynağından nginx'i alın : güncel bir ürün elde etmenin yanı sıra bu yapılandırmadan / cehennemden kurtulacaksınız.
Bernard Rosset,

2
Bu, resmi Nginx belgelerinde bu ad sözleşmesinin tek bir referansının neden olmadığını açıklar. Bu üçüncü parti bir projedir! github.com/perusio/nginx_ensite
AxeEffect

30

Genelde, sites-enabledklasör sanal sunucu tanımları conf.diçin kullanılırken, genel sunucu yapılandırması için kullanılır. Birden fazla web sitesini (yani, sanal ana bilgisayarları) destekliyorsanız, her biri kendi dosyasını alır, böylece dosyaları içeri ve dışarı taşıyarak sites-enabled(veya büyük olasılıkla sembolik bağlantılar oluşturarak ve kaldırarak) kolayca etkinleştirebilir ve devre dışı bırakabilirsiniz. daha iyi bir fikir).

Kullanım conf.dmodül yükleme, günlük dosyaları ve tek bir sanal ana özgü olmayan diğer şeyler gibi şeyler için.

Varsayılan yapılandırma www-data kullanıcısına başvuruyor mu? Bu kullanıcıyı oluşturmak zorunda mıyım?

Kök olmayan bir kullanıcı olarak çalışan nginx'e sahip olmalısınız. Bu adlandırılmış bazı durumlarda www-data, ancak istediğiniz herhangi bir şeyi adlandırabilirsiniz .

Bu kullanıcıya nginx çalıştırmak için en uygun izinleri nasıl veririm?

Bu sorunun cevabından daha az emin değilim (şu anda nginx kullanmıyorum), ancak Apache gibi bir şey varsa, www-datakullanıcının sadece statik dosyalara okuma izinlerine ihtiyacı var (ve dizinlerde okuma + yürütme) ) Sunmakta olduğunuz veya CGI betikleri gibi şeyler için izinleri okuduğunuz / yürüttüğünüz ve başka hiçbir yerde izin vermediğiniz.


1
web sunucusu çalıştırmak için özel bir kullanıcıya sahip olmak, bu kullanıcının geçerli kabuk kaydını kaldırarak oturum açma özelliğini devre dışı bırakması nedeniyle de önemlidir.
DukeLion

> 'Kök olmayan bir kullanıcı olarak çalışan nginx'e sahip olmalısınız' - bu konuda daha fazla bilgi verebilir misiniz?
lfender6445

1
Ayrıcalıklı olmayan bir kullanıcı olarak çalışmak, uzak bir uzlaşmadan kaynaklanabilecek hasarı içermenin bir yoludur. Bir web sunucusu kullanıyorsanız rootve bir tür uzak bir uzlaşma varsa, saldırgan sisteme hemen erişebilir. Ayrıcalıklı olmayan bir kullanıcı olarak çalışırken, idari erişim yalnızca bir tür yerel sömürü ile birlikte kullanılabilir.
larsks

14

Neler oluyor?

Beri, Debian veya Ubuntu kullanıyor olmalı kötülük sites-available / sites-enabledmantık tarafından kullanılmaz nginx upstream ambalaj dan http://nginx.org/packages/ .

Her iki durumda da, her ikisi de standart includedirektifin yardımı ile bir yapılandırma sözleşmesi olarak uygulanır /etc/nginx/nginx.conf.

İşte /etc/nginx/nginx.confnginx.org'dan resmi bir yukarı akış nginx paketinin parçası:

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

İşte /etc/nginx/nginx.confDebian / Ubuntu'dan bir pasaj :

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

Bu nedenle, NGINX'in bakış açısından tek fark, dosyaların conf.ddaha önce işlenmesinden kaynaklanacak ve bu şekilde, eğer birbirleriyle sessizce çatışan konfigürasyonlara sahipseniz, o zamankiler öncekilerden conf.döncelikli olabilir sites-enabled.


İyi Uygulama mı conf.d.

/etc/nginx/conf.dStandart bir kongre olduğu için kullanıyor olmalısınız ve her yerde çalışmalısınız.

Bir siteyi devre dışı bırakmanız gerekirse, dosya adını artık bir .confsonek, çok kolay, basit ve hatasız hale gelmeyecek şekilde yeniden adlandırın :

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

Veya bir siteyi etkinleştirmek için tam tersi :

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


Kaçının sites-availableve sites-enabledHer Neyse.

sites-available/ sites-enabled: Kullanmak için kesinlikle hiçbir neden göremiyorum.

  • Bazı insanlar bahsettiler nginx_ensiteve nginx_dissitesenaryolar - bu senaryoların isimleri bu debacle'nin geri kalanından bile daha kötü - ama bu senaryolar aynı zamanda bulunamayacak bir yerde değil nginx- Debian'da (ve muhtemelen Ubuntu'da da) bile yok. , ve kendi paketlerinde bulunmuyor, ayrıca, iki dizin arasındaki dosyaları basitçe taşımak ve / veya bağlamak için gerçekten de standart dışı bir üçüncü taraf komut dosyasına ihtiyacınız var mı ?!

  • Ve eğer komut dosyalarını kullanmıyorsanız (aslında yukarıdakilere göre akıllıca bir seçimdir), o zaman siteleri nasıl yönettiğiniz konusunda bir sorun var:

    • Eğer gelen sembolik bağlantılar oluşturmak musunuz sites-availableiçin sites-enabled?
    • Dosyaları kopyala?
    • Dosyalar taşınsın mı?
    • Yerinde dosyalar düzenleniyor sites-enabledmu?

Yukarıdakiler, bazı kişiler sistemi yönetmeye başlayana kadar ya da hızlı bir karar verene kadar sadece birkaç ay ya da yıllarca unutmak için çözülecek bazı küçük sorunlar gibi görünebilir.

Bu bizi bize getiriyor:

  • Bir dosyayı kaldırmak güvenli sites-enabledmidir? Yumuşak bağlantı mı? Sert bir bağlantı mı? Veya yapılandırmanın tek kopyası? Yapılandırma cehenneminin en iyi örneği.

  • Hangi siteler devre dışı bırakıldı? (İle conf.d, sadece .conf- ile bitmeyen find /etc/nginx/conf.d -not -name "*.conf"ya da kullanamayan dosyaları ters çevirme araması yapın grep -v.)

Yukarıdakilerin tümü değil, aynı zamanda includeDebian / Ubuntu tarafından kullanılan özel yönergeye de dikkat edin - /etc/nginx/sites-enabled/*- için sites-enabledaksine hiçbir dosya adı soneki belirtilmez conf.d.

  • Bunun anlamı, bir gün içinde bir veya iki dosyayı hızlı bir şekilde düzenlemeye karar verirseniz /etc/nginx/sites-enabledve ani emacsgibi bir yedekleme dosyası oluşturursanız default~, aniden, kullanılan direktiflere bağlı olarak bile kullanamayabileceğiniz aktif bir yapılandırma olarak ekler defaultve default~eklemiş olursunuz. Herhangi bir uyarı ve uzun bir hata ayıklama oturumu gerçekleşmesine neden olur. (Evet, bana da oldu; bir hackathon sırasındaydı ve kafamın neden işe yaramadığı konusunda tamamen şaşırmıştım.)

Böylece sites-enabledsaf kötülük olduğuna ikna oldum !


Yukarıdakilerin hepsine ek olarak, görünüşe göre, yanlış sembolik bağlantılar oluşturmak da çok yaygındır! stackoverflow.com/a/14107803/1122270sites-enabled Yeterince kötü olmadığını düşündüğünüzde !
21'de

Veya, bazen, birisi dosyaları düzenlemeye karar vermiş olabilir sites-enabled, ancak o zaman başka bir kişi , dosyayı silmek için silme kararı almaya karar verir, muhtemelen sadece dosyayı kopyalamak için, nginx öbek bellek dökümünü gerekli kılmak için sadece bir bağlantı olduğunu düşünür: stackoverflow.com/q/45852224/1122270
cnst

Ben yaklaşık iddiaların katılmıyorum zorunda sites-availableve sites-enabled; Nginx yeniden yüklendiyse veya yeniden başlatıldıysa, kısmi yapılandırma dosyalarını açmayacak şekilde, 'live' alma dizini dışındaki config dosyalarını hazırlayabilmek önemlidir. Artık aktif kullanımda olmayan yapılandırma dosyalarını saklamakta yararlı olabilir. IMO ilk başta nginx'i yönetmek için yeterli deneyime sahipseniz, sembolik bağlantılar oluşturmak özellikle zor bir iş değildir.
BE77Y,

@ BE77Y daha karmaşık bir yaklaşım benimsiyorsunuz. Programlamada, kullanılmayan kodu tamamen kaldırmak, sadece devre dışı bırakmak veya yorum yapmak değildir; DevOps'un farklı olmasının bir nedeni olmadığını görüyorum - eğer bir yapılandırma artık gerekli değilse, kaldırın (hala VCS'nizde mevcut olmalıdır). Kısmi conf dosyalarında olduğu gibi - neden onları etkin hale getirdiniz ve nginx'in arkanızdan yeniden yüklenmesini mi istiyorsunuz? ( USR1günlükleri yeniden açan, conf yeniden yüklemez.) Simge bağlantınızı "deneyim" yanlış yönlendirilmiş yorumlar buluyorum - sorun, deneyim ile ilgisi olmayan bir tutarlılık sorunudur.
cnst

2
A) bu tartışma için uygun ortam olmadığı ve belki de daha da önemlisi, b) her durumda sonuçsuz olacağı açıktır. Kabul etmemeyi kabul edelim.
BE77Y
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.