Apache sembolik bağlantıları takip etmeyecek (403 Yasak)

Ubuntu'da Apache'yi kurarken bazı sorunlar yaşıyorum. Bu kılavuzu takip ediyorum .

# /usr/sbin/apache2 -v
Server version: Apache/2.2.17 (Ubuntu)
Server built:   Feb 22 2011 18:33:02

Genel dizinim / var / www, içine yerleştirilen PHP sayfalarını başarıyla sunabilir ve çalıştırabilir. Bununla birlikte, / var / www içinde, ana klasörümdeki bir dizine işaret eden ve oradaki sayfaları sunan bir sembolik bağlantı oluşturmak istiyorum.

[root /var/www]# ll
total 36
drwxr-xr-x  3 root root 4096 2011-09-11 14:22 .
drwxr-xr-x 14 root root 4096 2011-06-04 22:49 ..
lrwxrwxrwx  1 root root   16 2011-09-11 13:21 about -> /root/site/about

Tarayıcıdan erişmeye çalıştığımda / hakkında

Forbidden

You don't have permission to access /about on this server.

Bildiğim kadarıyla, sunmak istediğim dosyalara yeterli ayrıcalıklar verdim:

[root ~/site/about]# ll
total 24
drwxr-xr-x 5 root root 4096 2011-09-11 13:20 .
drwxr--r-- 3 root root 4096 2011-09-11 13:19 ..
drwxr-xr-x 2 root root 4096 2011-09-11 13:21 contact
-rwxr-xr-x 1 root root 1090 2011-09-11 13:19 index.php
drwxr-xr-x 2 root root 4096 2011-09-11 13:20 me
drwxr-xr-x 2 root root 4096 2011-09-11 13:21 resume

FollowSymLinks seçeneğinin farkındayım ve / etc / apache2 / sites-enabled / 000-default dosyamda ayarlandığına inanıyorum:

DocumentRoot /var/www
<Directory />
    Options FollowSymLinks
    AllowOverride None
</Directory>
<Directory /var/www/>
    Options FollowSymLinks Indexes MultiViews
    AllowOverride None
    Order allow,deny
    allow from all
</Directory>

Neyi özleyebileceğime dair bir fikrin var mı?

Apache haklarını yürütmek sahip olduğunu kontrol edin /root, /root/siteve /root/site/about.

Çalıştırmak:

chmod o+x /root /root/site /root/site/about

403 hatası, şifrelenmiş bir dosya sisteminden, örneğin şifrelenmiş bir ana klasöre bir sembolik bağdan da kaynaklanabilir .

Sembolik bağlantınız şifrelenmiş klasöre işaret ederse, apache kullanıcısı (örn. Www-data), apache ve dosya / klasör izinleri doğru ayarlanmış olsa bile içeriğe erişemez. Www-data kullanıcısının erişimi böyle bir çağrı ile test edilebilir:

sudo -u www-data ls -l /var/www/html/<your symlink>/

Bunun için geçici çözümler / çözümler vardır, örneğin www-data kullanıcısını özel grubunuza eklemek (şifrelenmiş veriyi web kullanıcısına gösterir) veya şifrelenmemiş bir senkronizasyon klasörü kurarak (muhtemelen oldukça güvenli). Ben muhtemelen geliştirme sırasında bir rsync çözümüne gideceğim.

/ubuntu/633625/public-folder-in-an-encrypted-home-directory

Amacım için uygun bir araç lsyncd . Bu, doğrudan şifrelenmiş ana klasörümde çalışmama ve apache web sayfasındaki değişiklikleri neredeyse anında görebilmeme olanak sağlıyor. Senkronizasyon, dosya sistemindeki değişikliklerle tetiklenir ve bir rsync çağırılır. Yalnızca oldukça küçük web sayfaları ve komut dosyaları üzerinde çalıştığım için senkronizasyon çok hızlı. 0 saniyelik bir gecikme ayarlamak mümkün olsa da, rsync başlamadan önce 1 saniyelik kısa bir gecikme kullanmaya karar verdim .

Lsyncd'yi yükleme (Ubuntu'da):

sudo apt-get install lsyncd

Arka plan hizmetini başlatma:

lsyncd -delay 1 -rsync /home/<me>/<work folder>/ /var/www/html/<web folder>/

Yeni sunucumda uzun süredir çözemediğim benzer bir sorun yaşıyordum. Palacsint'in cevabına ek olarak, sorulacak iyi bir soru şudur: Apache 2.4 kullanıyor musunuz? Apache 2.4'te, yukarıdaki yapılandırma kullanılarak yapıldığında çalışmayan izinleri ayarlamak için farklı bir mekanizma vardır, bu yüzden bu blog yazısında açıklanan çözümü kullandım .

Temel olarak, yapmam gereken şey yapılandırma dosyamı şundan dönüştürmekti:

Alias /demo /usr/demo/html

<Directory "/usr/demo/html">
    Options FollowSymLinks
    AllowOverride None
    Order allow,deny
    allow from all

</Directory>

to:

Alias /demo /usr/demo/html

<Directory "/usr/demo/html">
    Options FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

Sipariş ve izin verme satırlarının, Tüm verilmiş olanı zorunlu kıl ile nasıl değiştirildiğine dikkat edin

Bu soruyla ilgili olarak, vhost'umun bana neden 403'ü verdiğini anladım.

Bu soruda TÜM olasılıkları ve diğerlerini şanssız olarak test ettim. Neredeyse beni deli ediyor.

Sembolik bağlantılar aracılığıyla Capistrano'ya benzer sürüm dağıtımına sahip bir sunucu kuruyorum ve DocRoot klasörüne erişmeye çalıştığımda (şu anda mevcut sürüm klasörüne bir sembolik bağlantı) bana 403 verdi.

Benim vhost'um:

DocumentRoot /var/www/site.com/html
<Directory /var/www/site.com/html>
        AllowOverride All
        Options +FollowSymLinks
        Require all granted
</Directory>

ve ana httpd.conf dosyam şuydu (varsayılan Apache 2.4 kurulumu):

DocumentRoot "/var/www"
<Directory "/var/www">
    Options -Indexes -FollowSymLinks -Includes
(...)

Ana Seçenekler tanımının sankonlar alanıma göre öncelik kazandığı ortaya çıktı (benim için bu sezgisel değil). Ben de şu şekilde değiştirdim:

DocumentRoot "/var/www"
<Directory "/var/www">
    Options -Indexes +FollowSymLinks -Includes
(...)

ve Eureka! (MAIN httpd.conf dosyasında FollowSymLinks'den önceki artı işaretine dikkat edin. Umarım bu, diğer kayıp ruhlara yardımcı olur.

Benim durumumda keşfettiğim gibi, sembolik bağların sizi hayal kırıklığına uğratmasının başka bir yolu daha var. Sunucu olarak bir SELinux sisteminiz varsa ve sembolik bağlantılar NFS'ye bağlı bir klasörü işaret ediyorsa (diğer dosya sistemleri benzer belirtiler httpdverebilir ), yanlış bağlamları görebilir ve hedef klasörlerin içeriğini sunmayı reddedebilir.

Benim durumumda SELinux bağlamı /var/www/html(buradan edinebilirsiniz ls -Z) unconfined_u:object_r:httpd_sys_content_t:s0. İçindeki sembolik bağlantılar /var/www/htmlaynı içeriğe sahip olacaktır, ancak hedeflerinin bağlamı, NFS'ye bağlı bir klasördür system_u:object_r:nfs_t:s0.

Solüsyon eklemektir fscontext=unconfined_u:object_r:httpd_sys_content_t:s0için mountseçenekler (mesela # mount -t nfs -o v3,fscontext=unconfined_u:object_r:httpd_sys_content_t:s0 <IP address>:/<server path> /<mount point>). rootcontextilgisizdir ve defcontextNFS tarafından reddedilir. Ben kendim denemedim context.

Önce selinux'u devre dışı bırakın (vim / etc / selinux / config)

vim /etc/httpd/conf/httpd.conf, sembolik bağlantılar ve dizin indeksleme için aşağıdaki satırları düzenleyin:

documentroot /var/www/html
<directory /var/www/html>
    Options Indexes FollowSymLinks
    AllowOverride None
</directory>

.Htaccess dosyası ise, AllowOverride all

14.04 /ubuntu/452042/why-is-my-apache-not-working-after-upgrading-to-ubuntu-14-04 sürümüne yükseltme yaptıktan sonra sorun yaşayan herkes için, yükseltmeden önce kök değişti = / yükseltmeden sonra var / www = / var / www / html

Diğer yanıtların da belirttiği gibi izinleri değiştirmenin yanı sıra, etkili olması için apache'yi yeniden başlatmam gerekiyordu:

sudo service apache2 restart

Yine bir başka ince tuzak, ihtiyacınız olması durumunda AllowOverride All:

Fs ağacının derinliklerinde bir yerde, yaşlı bir .htaccesssahip

    Options Indexes

onun yerine

    Options +Indexes

FollowSymLinksSunucu yapılandırmasındaki seti kayıtsız bir şekilde devre dışı bırakmak ve burada gizemli bir 403 oluşturmak için gereken tek şeydi .

FollowSymLinks seçeneği etkinken:

$ rg "FollowSymLinks" /etc/httpd/
/etc/httpd/conf/httpd.conf
269:    Options Indexes FollowSymLinks

httpd'nin kullandığı kullanıcı tarafından çalıştırılabilir olması için symlink'teki tüm dizinlere ihtiyacınız var.

yani bu genel kullanım durumu için:

cd /path/to/your/web
sudo ln -s $PWD /srv/http/

Sahibin izinlerini namei ile kontrol edebilirsiniz :

$ namei -m /srv/http/web
f: /srv/http/web
 drwxr-xr-x /
 drwxr-xr-x srv
 drwxr-xr-x http
 lrwxrwxrwx web -> /path/to/your/web
   drwxr-xr-x /
   drwxr-xr-x path
   drwx------ to
   drwxr-xr-x your
   drwxr-xr-x web

Benim durumumda, todizin yalnızca kullanıcım için yürütülebilirdi:

Başkalarının yürütmesini etkinleştirin sorunu çözün:

chmod o+x /path/to

Yürütülebilir olmayan dizinin farklı olabileceğini görün veya sizin durumunuza bağlı olarak diğerleri yerine grupları etkilemeniz gerekir.