เว็บไซต์ควรอยู่ใน / var / หรือ / usr / ตามการใช้งานที่แนะนำหรือไม่

ตามคำแนะนำเกี่ยวกับโครงสร้างไดเรกทอรีลินุกซ์ , /usr/สำหรับไฟล์โปรแกรมและ/var/เป็นไฟล์ที่มีการเปลี่ยนแปลง (ผมถือว่านี้หมายความว่า "ไฟล์ที่อยู่ในการใช้งาน") ถูกต้องหรือไม่

หากเป็นกรณีนี้ฉันจะฉีกขาดระหว่างการใช้งาน เว็บไซต์เป็นแอปพลิเคชั่น (หากเป็นแบบไดนามิกดังนั้นจะพูดได้) แต่ในกรณีอื่นมันเป็นเพียงชุดของไฟล์ที่ Apache ใช้

www dir เริ่มต้นใช้ชีวิต/var/www/ดังนั้นเราควรทำตามความเหมาะสมโดยใช้/var/websites/(หรือบางอย่างที่คล้ายกัน) หรือเลือก/usr/websites/เนื่องจากอาจเป็นแอปพลิเคชัน

นี่เป็นคำถามที่ไม่สำคัญมากนัก แต่มันก็ยังบั่นทอนฉันอยู่ดี ในกรณีของเราฉันกำลังโน้มตัวไปข้างหน้า/usr/webหรืออะไรทำนองนั้นเนื่องจากเว็บไซต์ของเราเป็นแอปพลิเคชันทั้งหมด

ปรับปรุง:

นี่สำหรับเว็บไซต์ บริษัท ของเรา ไม่ใช่เซิร์ฟเวอร์โฮสต์ที่ใช้ร่วมกันดังนั้นเราจึงไม่ต้องกังวลว่าจะแยกพวกเขาออกจากกัน/home/หรืออะไรทำนองนั้น

ตามที่FHS , /usrเป็นshareable, read-only data- ไม่ได้ที่คุณต้องการที่จะนำเว็บไซต์ นี่คือที่ที่คุณควรใส่รหัสของคุณ (เช่น Fedora ทำสิ่งนี้เพื่อ Wordpress) ดูคู่มือบรรจุภัณฑ์เนื้อหาเว็บสำหรับ Fedora

/varคือ "ไฟล์ข้อมูลผันแปรซึ่งรวมถึงไดเรกทอรีสปูลและไฟล์ข้อมูลการดูแลระบบและการบันทึกและไฟล์ชั่วคราวและชั่วคราว" - ดีกว่า แต่ก็ยังไม่ถูกต้อง - แต่ระบบจำนวนมากจะใช้/var/wwwดังนั้นแม้ว่าคุณจะผิดที่จะใส่ไว้ในนั้นคุณอยู่ใน บริษัท ที่ดี

/srvใช้สำหรับ "ข้อมูลเฉพาะไซต์ที่ให้บริการโดยระบบนี้" - ซึ่งดูเหมือนว่าจะเป็นการจับคู่ที่ดี แต่พบได้น้อยกว่า/var/wwwมาก

สถานที่ทั่วไปอื่น ๆ ที่จะนำไฟล์ไซต์นั้นอยู่ภายใต้/home- โดยการสร้างผู้ใช้พิเศษที่เรียกว่าwebsiteหรือเช่นนั้นจากนั้นวางไฟล์ภายใน homedir ของผู้ใช้ (เช่น, /home/website)

ลองดูที่ลำดับขั้นของมาตรฐานระบบไฟล์ ( Wikipedia ) ฉันเองใช้ / srv / web / $ domain / {htdocs, บันทึก, cgi-bin, ... }

เว็บไซต์ควรอยู่ในไดเรกทอรีหลักของผู้ใช้ พวกเขาเป็นข้อมูลผู้ใช้ควรถูกแยกออกโดยผู้ใช้หนึ่งคนต่อไซต์และเนื้อหาแบบไดนามิกควรทำงานในฐานะผู้ใช้ที่แยกต่างหากอีกครั้งด้วยไฟล์ที่เนื้อหาแบบไดนามิกจำเป็นต้องอ่านและแก้ไขตามสิทธิ์ที่เหมาะสมในการทำเช่นนั้น

ปรับปรุง:

เพียงเพราะไม่ใช่เซิร์ฟเวอร์การโฮสต์ที่ใช้ร่วมกันไม่ได้หมายความว่าคุณไม่ควรมีส่วนร่วมในการปฏิบัติด้านความปลอดภัยที่ดีและแยกบทบาทอิสระออกเป็นโซนความปลอดภัยของตนเอง

คำแนะนำที่ชัดเจนคือมาตรฐานระบบไฟล์ลำดับชั้นซึ่งบอกว่า/srvเป็นสถานที่ที่เหมาะสม

สถานที่ที่พวกเขาอาศัยอยู่บนดิสก์มีเรื่องเล็กน้อย เป็นที่ที่คุณต้องการ

ฉันมี symlink จาก / www บนเครื่องทั้งหมดของฉันไปยังที่ที่พวกเขาอาศัยอยู่จริง ๆ ดังนั้นฉันจึงไม่ต้องสงสัยจากเครื่องหนึ่งไปยังอีกเครื่อง เครื่องรุ่นเก่าบางเครื่องมี / u0 และ / u1 สำหรับดิสก์ผู้ใช้และฉันวางสิ่งต่างๆบนเว็บไว้ที่นั่น บางคนมี / ติดตั้งที่บ้านโดยตรงดังนั้นพวกเขาไปที่นั่น แต่ / www ชี้ไปยังสถานที่ที่เหมาะสมเสมอ

ฉันยังไม่ได้ใส่การกำหนดค่าใด ๆ ใน / usr หรือใน / var มันจะไปใน / local (ซึ่งคุณเดาได้ว่ามันเป็น symlink ที่ไหนสักแห่งใน / u0 หรือ / u1 โดยทั่วไป) ทำให้การสำรองข้อมูลเป็นเรื่องง่าย ฉันเพียงแค่สำรองดิสก์ของผู้ใช้

แน่นอนว่าฉันมีเว็บไซต์กระจายข้อมูลหลักสำหรับระบบปฏิบัติการที่ฉันเลือก NetBSD ฉันสร้างระบบเหมือนที่ฉันต้องการในเครื่องหลักนี้ (เป็นอินสแตนซ์ xen) และ rsync / usr ทำให้ชีวิตของฉันง่ายขึ้น

Apache เว็บเซิร์ฟเวอร์มีเว็บไซต์เริ่มต้นภายใต้/ var / www /แต่แนะนำให้ใส่เว็บไซต์อื่นภายใต้/ srv /

ฉันสังเกตเห็นสิ่งนี้บน Ubuntu Server 14.04 LTS ไฟล์ apache2.conf เริ่มต้นประกอบด้วยบล็อกที่มีความคิดเห็น:

#<Directory /srv/>
#   Options Indexes FollowSymLinks
#   AllowOverride None
#   Require all granted
#</Directory>

ตามที่ฉันคุณไม่ควรและไม่เคยใส่บริการอินเทอร์เน็ตใด ๆ ในโซนระบบทั่วไป

บริการอินเทอร์เน็ตของคุณ (Apache / Tomcat / SSH เป็นต้น) เป็นประตูหน้าจากนั้นถ้าคุณใส่บริการเหล่านั้นไว้ใน System Zone ของคุณคุณอาจเสี่ยงต่อการถูกโจมตี

ยิ่งกว่านั้นถ้าคุณได้ให้บริการ differents ของคุณในโซนแซนด์บ็อกซ์ที่ปลอดภัยเช่นเดียวกับพาร์ติชันแยกส่วน

นี่คือตัวอย่างของโครงสร้างที่คุณสามารถใช้ได้:

/ --> Root System --> On SDA1 --> Root and System security operator access only
 |
 | -->/usr /etc /var etc.

/SRV --> Web Root --> On SDB1 --> Web users access with minimal rights access.
 |
 |-->/srv/bin & /srv/dta
      |
      |-->/srv/bin/apache (or any other APPLICATION Binaries)
      |-->/srv/dta/SQL (or any other APPLICATION Datas like a 
                        database or web PHP files etc.)