Apa perbedaan penggunaan untuk situs-tersedia dengan direktori conf.d untuk nginx


99

Saya punya pengalaman menggunakan linux tetapi tidak ada yang menggunakan nginx. Saya telah ditugaskan untuk meneliti opsi load-balancing untuk server aplikasi.

Saya telah menggunakan apt-get untuk menginstal nginx dan semuanya tampak baik-baik saja.

Saya punya beberapa pertanyaan.

Apa perbedaan antara folder yang tersedia dengan folder dan folder conf.d. Kedua folder tersebut TERMASUK dalam pengaturan konfigurasi default untuk nginx. Tutorial menggunakan keduanya. Untuk apa mereka dan apa praktik terbaik?

Untuk apa folder dengan dukungan situs digunakan? Bagaimana saya menggunakannya?

Konfigurasi default merujuk pada pengguna data-www? Apakah saya harus membuat pengguna itu? Bagaimana cara saya memberikan izin optimal kepada pengguna untuk menjalankan nginx?


Cobalah untuk menghindari cakupan creep ketika mengajukan pertanyaan; www-dataadalah topik yang terpisah. Sebagian besar sistem operasi mendefinisikan pengguna terpisah dengan izin yang lebih rendah yang dapat dijalankan oleh proses setelah mengikat ke port 80 sebagai root. Itu didefinisikan dalam file konfigurasi. Terapkan praktik keamanan dasar dari sana; jangan biarkan pengguna menulis apa pun yang tidak perlu ditulis server web, jangan biarkan pengguna lain menulis ke file kecuali itu disengaja.
Andrew B

Jawaban:


94

Folder situs- * dikelola oleh nginx_ensitedan nginx_dissite. Untuk pengguna Apache httpd yang menemukan ini dengan pencarian, padanannya adalah a2ensite/ a2dissite.

The sites-availablefolder untuk menyimpan semua konfigurasi vhost Anda, apakah atau tidak mereka sedang diaktifkan.

The sites-enabledfolder berisi symlink ke file dalam folder sites-available. Ini memungkinkan Anda untuk menonaktifkan vhosts secara selektif dengan menghapus symlink.

conf.dmelakukan pekerjaan, tetapi Anda harus memindahkan sesuatu dari folder, menghapusnya, atau membuat perubahan ketika Anda perlu menonaktifkan sesuatu. Abstraksi folder situs * membuat segalanya menjadi lebih teratur dan memungkinkan Anda untuk mengelolanya dengan skrip dukungan terpisah.

(kecuali jika Anda seperti saya, dan satu dari banyak admin debian yang baru saja mengelola symlink secara langsung, tidak mengetahui tentang skrip ...)


12
Apakah saya melakukan kesalahan? Tidak memahami downvote.
Andrew B

1
saya ingin tahu apakah ini dibangun ke nginx? saya menginstal secara manual github.com/perusio/nginx_ensite
lfender6445

18
Penting untuk dicatat bahwa itu sites-available|sites-enabledadalah Debian-isme dan bukan sesuatu yang dilakukan nginx atau Apache. Itu mungkin cukup berguna di masa lalu, tetapi utilitasnya agak terbatas di zaman manajemen konfigurasi dan wadah.
Michael Hampton

Bisakah Anda berkomentar bagaimana manajemen konfigurasi dan wadah membatasi utilitas situs yang tersedia | situs yang diaktifkan?
karthik vee

1
@karthikvee intinya adalah bahwa server saat ini sering muncul sebagai wadah ephemerical yang hanya melayani satu situs web / layanan, sehingga ini dapat dimasukkan nginx.conftanpa kehilangan keterbacaan. Ini bertentangan dengan pendekatan dari beberapa tahun yang lalu ketika server biasanya akan menyimpan puluhan situs web.
adamczi

38

Saya ingin menambahkan jawaban sebelumnya bahwa yang paling penting bukanlah bagaimana Anda memanggil direktori (meskipun itu adalah konvensi yang sangat berguna), tetapi apa yang sebenarnya Anda masukkan nginx.conf. Contoh konfigurasi:

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

Satu-satunya arahan yang digunakan di sini adalah termasuk , jadi tidak ada perbedaan internal antara misalnya conf.d/dan sites-enabled/.

Dari dokumentasi di atas:

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.

Jadi, untuk menjawab pertanyaan awal: tidak ada perbedaan internal, dan Anda dapat menggunakannya sebaik mungkin, mengingat nasihat dari jawaban lain. Dan tolong, jangan lupa untuk memilih jawaban yang 'benar'.


1
Benar, sites-enabledtelah sedikit diciptakan oleh beberapa pembedaan, fuzzing sekitar sebagai perantara tidak. Pergi ambil nginx dari sumber resmi : Anda akan mendapatkan produk terbaru, serta menyingkirkan konfigurasi omong kosong / neraka ini.
Bernard Rosset

2
Ini menjelaskan mengapa tidak ada satu referensi tunggal dari konvensi nama ini pada dokumentasi Nginx resmi. Ini adalah proyek pihak ketiga! github.com/perusio/nginx_ensite
AxeEffect

30

Biasanya, sites-enabledfolder digunakan untuk definisi host virtual, sementara conf.ddigunakan untuk konfigurasi server global. Jika Anda mendukung beberapa situs web - mis., Host virtual - maka masing-masing mendapatkan file sendiri, sehingga Anda dapat mengaktifkan dan menonaktifkannya dengan sangat mudah dengan memindahkan file masuk dan keluar dari sites-enabled(atau membuat dan menghapus symlink, yang mungkin ide yang lebih baik).

Gunakan conf.duntuk hal-hal seperti memuat modul, file log, dan hal-hal lain yang tidak spesifik untuk satu host virtual.

Konfigurasi default merujuk pada pengguna data-www? Apakah saya harus membuat pengguna itu?

Anda harus menjalankan nginx sebagai pengguna non-root. Ini dalam beberapa kasus bernama www-data, tetapi Anda dapat memberi nama apa pun yang Anda inginkan.

Bagaimana cara saya memberikan izin optimal kepada pengguna untuk menjalankan nginx?

Saya kurang yakin dengan jawaban untuk pertanyaan ini (saya tidak menjalankan nginx saat ini), tetapi jika itu seperti Apache jawabannya adalah bahwa www-datapengguna hanya perlu izin baca untuk file statis apa pun (dan baca + jalankan pada direktori ) bahwa Anda melayani, atau membaca / mengeksekusi izin pada hal-hal seperti skrip CGI, dan tidak ada izin di tempat lain.


1
memiliki pengguna yang berdedikasi untuk menjalankan server web juga penting karena menonaktifkan kemampuan login untuk pengguna ini dengan menghapus catatan shell yang valid.
DukeLion

> 'Anda seharusnya menjalankan nginx sebagai pengguna non-root' - dapatkah Anda menjelaskan lebih lanjut tentang ini?
lfender6445

1
Berjalan sebagai pengguna yang tidak memiliki hak adalah cara untuk mengatasi kerusakan yang dapat terjadi akibat kompromi jarak jauh. Jika Anda menjalankan server web rootdan ada semacam kompromi jarak jauh, penyerang segera memiliki akses penuh ke sistem. Saat dijalankan sebagai pengguna yang tidak memiliki hak, akses administratif hanya akan tersedia dalam kombinasi dengan semacam eksploitasi lokal.
larsks

14

Apa yang sedang terjadi?

Anda harus menggunakan Debian atau Ubuntu, karena iblis sites-available / sites-enabledlogika tidak digunakan oleh kemasan hulu nginx dari http://nginx.org/packages/ .

Dalam kedua kasus, keduanya diimplementasikan sebagai konvensi konfigurasi dengan bantuan includearahan standar di /etc/nginx/nginx.conf.

Berikut cuplikan dari /etc/nginx/nginx.confpaket hulu resmi nginx dari nginx.org:

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

Berikut cuplikan /etc/nginx/nginx.confdari Debian / Ubuntu :

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

Jadi, dari sudut pandang NGINX, satu-satunya perbedaan adalah bahwa file dari conf.ddapat diproses lebih cepat, dan, dengan demikian, jika Anda memiliki konfigurasi yang secara diam-diam bertentangan satu sama lain, maka dari yang conf.dmungkin lebih diutamakan daripada yang masuk sites-enabled.


Praktik Terbaik Adalah conf.d.

Anda harus menggunakan /etc/nginx/conf.d, karena itu adalah konvensi standar, dan harus bekerja di mana saja.

Jika Anda perlu menonaktifkan situs, cukup ganti nama file menjadi tidak lagi memiliki .confakhiran, sangat mudah, langsung dan bukti kesalahan:

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

Atau sebaliknya untuk mengaktifkan situs:

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


Hindari sites-available& Apa sites-enabledPun Biaya.

Saya sama sekali tidak melihat alasan untuk menggunakan sites-available/ sites-enabled:

  • Beberapa orang telah menyebutkan nginx_ensitedan nginx_dissiteskrip - nama skrip ini bahkan lebih buruk daripada sisa bencana ini - tetapi skrip ini juga tidak ditemukan - mereka tidak ada dalam nginxpaket bahkan di Debian (dan mungkin di Ubuntu juga) , dan tidak hadir dalam paket mereka sendiri, juga, plus, apakah Anda benar-benar membutuhkan skrip pihak ketiga yang tidak standar untuk hanya memindahkan dan / atau menautkan file di antara dua direktori ?!

  • Dan jika Anda tidak menggunakan skrip (yang sebenarnya merupakan pilihan cerdas seperti di atas), maka muncul masalah bagaimana Anda mengelola situs:

    • Apakah Anda membuat tautan simbolis dari sites-availableke sites-enabled?
    • Salin file?
    • Pindahkan file?
    • Edit file pada tempatnya sites-enabled?

Di atas mungkin tampak seperti beberapa masalah kecil untuk diatasi, sampai beberapa orang mulai mengelola sistem, atau sampai Anda membuat keputusan cepat, hanya untuk melupakannya berbulan-bulan atau bertahun-tahun ...

Yang membawa kita ke:

  • Apakah aman menghapus file sites-enabled? Apakah itu tautan lunak? Tautan yang sulit? Atau satu-satunya salinan konfigurasi? Contoh utama dari konfigurasi neraka.

  • Situs mana yang telah dinonaktifkan? (Dengan conf.d, lakukan pencarian inversi untuk file yang tidak diakhiri dengan .conf- find /etc/nginx/conf.d -not -name "*.conf", atau gunakan grep -v.)

Tidak hanya semua hal di atas, tetapi juga perhatikan includearahan khusus yang digunakan oleh Debian / Ubuntu - /etc/nginx/sites-enabled/*- tidak ada akhiran nama file yang ditentukan untuk sites-enabled, tidak seperti untuk conf.d.

  • Apa artinya ini adalah bahwa jika suatu hari Anda memutuskan untuk mengedit satu atau dua file dengan cepat /etc/nginx/sites-enabled, dan Anda emacsmembuat file cadangan seperti default~, maka, tiba-tiba, Anda memiliki keduanya defaultdan default~dimasukkan sebagai konfigurasi aktif, yang, tergantung pada arahan yang digunakan, bahkan mungkin tidak memberikan Anda mendapat peringatan, dan menyebabkan sesi debug yang berkepanjangan terjadi. (Ya, itu memang terjadi pada saya; itu selama hackathon, dan saya benar-benar bingung mengapa conf saya tidak berfungsi.)

Jadi, saya yakin itu sites-enabledadalah kejahatan murni!


Selain semua hal di atas, ternyata, sangat umum untuk membuat symlink yang salah! stackoverflow.com/a/14107803/1122270 Kalau-kalau Anda tidak berpikir sites-enableditu cukup jahat!
cnst

Atau, kadang-kadang, dapat terjadi bahwa seseorang memutuskan untuk mengedit file sites-enabled, namun kemudian orang lain memutuskan untuk menonaktifkannya dengan menghapusnya, mungkin berpikir itu hanya sebuah symlink, yang memerlukan dump memori berikutnya dari nginx heap untuk memulihkan file conf: stackoverflow.com/q/45852224/1122270
cnst

Saya harus tidak setuju dengan pernyataan tentang sites-availabledan sites-enabled; penting untuk dapat menyiapkan file konfigurasi di luar direktori pickup 'live' sehingga jika nginx dimuat ulang atau dimulai ulang sehingga tidak akan mengambil sebagian file konfigurasi. Ini juga dapat berguna untuk menyimpan file konfigurasi yang tidak lagi digunakan secara aktif. Membuat symlink bukanlah tugas yang sulit jika Anda memiliki cukup pengalaman untuk mengelola nginx sejak awal, IMO.
BE77Y

@ BE77Y Anda mengambil pendekatan yang lebih rumit. Dalam pemrograman, ini dianggap praktik terbaik untuk sepenuhnya menghapus kode yang tidak digunakan, bukan hanya menonaktifkan atau berkomentar; Saya tidak melihat alasan mengapa DevOps harus berbeda - jika sebuah konfigurasi tidak lagi diperlukan, hapus saja (itu masih ada di VCS Anda). Sama dengan file konfigurasi sebagian - mengapa Anda mengeditnya diaktifkan dan memiliki nginx dimuat kembali di belakang Anda? ( USR1, yang membuka kembali log, tidak memuat ulang conf.) Saya menemukan komentar "pengalaman" symlink Anda salah arah - masalahnya adalah masalah konsistensi, yang tidak ada hubungannya dengan pengalaman.
cnst

2
Jelas bahwa a) ini bukan media yang tepat untuk diskusi ini dan mungkin lebih penting lagi, b) kemungkinan tidak akan menghasilkan apa-apa. Mari kita sepakat untuk tidak setuju.
BE77Y
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.