From e8ec7aa8e38a93f5b034ac74cebce5de23710317 Mon Sep 17 00:00:00 2001 From: hongbotian Date: Mon, 30 Nov 2015 01:45:08 -0500 Subject: upload http JIRA: BOTTLENECK-10 Change-Id: I7598427ff904df438ce77c2819ee48ac75ffa8da Signed-off-by: hongbotian --- .../httpd-2.0.64/docs/manual/sections.html.tr.utf8 | 472 +++++++++++++++++++++ 1 file changed, 472 insertions(+) create mode 100644 rubbos/app/httpd-2.0.64/docs/manual/sections.html.tr.utf8 (limited to 'rubbos/app/httpd-2.0.64/docs/manual/sections.html.tr.utf8') diff --git a/rubbos/app/httpd-2.0.64/docs/manual/sections.html.tr.utf8 b/rubbos/app/httpd-2.0.64/docs/manual/sections.html.tr.utf8 new file mode 100644 index 00000000..c8dbec32 --- /dev/null +++ b/rubbos/app/httpd-2.0.64/docs/manual/sections.html.tr.utf8 @@ -0,0 +1,472 @@ + + + +Yapılandırma Bölümleri - Apache HTTP Sunucusu + + + + + +
<-
+

Yapılandırma Bölümleri

+
+

Mevcut Diller:  en  | + es  | + ja  | + ko  | + tr 

+
+

Yapılandırma dosyalarındaki +yönergeler sunucunun tamamına uygulanacağı gibi sadece belli dizinler, +dosyalar, konaklar veya URL’lere uygulanmakla sınırlanabilir. Bu belgede, +yapılandırma bölümü taşıyıcılarınının veya .htaccess dosyalarının, +yapılandırma dosyalarındaki diğer yönergelerin etki alanlarını değiştirtirmek +için nasıl kullanılacağı açıklanmıştır.

+
+ +
top
+
+

Yapılandırma Bölümü Taşıyıcılarının Türleri

+ + + +

İki temel taşıyıcı türü vardır. Taşıyıcıların çoğu her istek için +değerlendirmeye alınır. Taşıyıcılardaki yönergeler ise sadece bu taşıyıcılarla +eşleşen istekler için uygulanır. Diğer yandan, <IfDefine> ve <IfModule> taşıyıcıları sadece sunucu başlatılırken veya yeniden +başlatılırken değerlendirmeye alınır. Başlatma sırasında gerektirdikleri +koşullar sağlanıyorsa içerdikleri yönergeler tüm isteklere uygulanır. Aksi +takdirde, içerdikleri yönergeler yok sayılır.

+ +

<IfDefine> yönergesi +sadece httpd komut satırında uygun parametreler +tanımlanmışsa uygulanabilecek yönergeleri içerir. Örneğin, aşağıdaki +yapılandırma ile tüm isteklerin diğer siteye yönlendirilebilmesi sadece +sunucu httpd -DClosedForNow komut satırı ile başlatıldığı +takdirde mümkün olur:

+ +

+<IfDefine ClosedForNow>
+ + Redirect / http://otherserver.example.com/
+
+</IfDefine> +

+ +

<IfModule> yönergesi +sadece belli bir modülün sunucuda kullanılabilir durumda olması halinde +uygulanabilecek yönergeleri içerir. Modülün ya sunucuyla birlikte durağan +olarak derlenmiş olması ya da devingen olarak derlenmiş ve yapılandırma +dosyasında yönergeden önce o modüle ilişkin bir LoadModule satırının bulunması gerekir. Bu yönergeyi sadece +belli bir modülün varlığının veya yokluğunun yapılandırma dosyanızın +çalışmasını etkilememesini istediğiniz durumlarda kullanmalısınız. +Eksik modüllerle ilgili hata iletilerini engellediğinden, taşıyıcı içine, +her zaman çalışması istenen yönergeler konulmamalıdır.

+ +

Aşağıdaki örnekte, MimeMagicFiles yönergesi sadece mod_mime_magic +modülü mevcutsa uygulanacaktır.

+ +

+<IfModule mod_mime_magic.c>
+ + MimeMagicFile conf/magic
+
+</IfModule> +

+ +

<IfDefine> ve +<IfModule> yönergelerinin her +ikisi de önüne "!" konularak olumsuz koşullar için uygulanabilir. Ayrıca, bu +bölümler daha karmaşık sınırlamalar elde etmek amacıyla bir diğerinin içinde +kullanılabilirler.

+
top
+
+

Dosya Sistemi ve Site Alanı

+ +

En sık kullanılan yapılandırma bölümü taşıyıcıları dosya sistemindeki +veya site alanındaki belli yerlerin yapılandırmalarını değiştirmekte +kullanılanlardır. Öncelikle, bu ikisi arasındaki farkları bilmek önemlidir. +Dosya sistemi disklerinizin işletim sistemi tarafından size gösterilen halidir. +Örneğin, öntanımlı kurulumda Apache, Unix sistemlerinde +/usr/local/apache2 altındayken Windows sistemlerinde +"c:/Program Files/Apache Group/Apache2" altındadır. +(Bilgi: Windows için bile, Apache’de dosya yolu belirtilirken tersbölü değil +normal bölü karakterleri kullanılır.) Site alanı ise sunucu tarafından +istemciye sunulan dizin ağacıdır. Yani, site alanı içindeki /dir/ +dizini, Apache’nin Unix üzerinde dosya sistemine öntanımlı olarak kurulduğu +yer göz önüne alınarak, dosya sistemindeki +/usr/local/apache2/htdocs/dir/ dizinine karşılıktır. Site +sayfaları veritabanlarından veya başka yerlerden devingen olarak +üretilebildiğinden site alanlarının doğrudan dosya sistemine eşlenmesi gerekli +değildir.

+ +

Dosya Sistemi Taşıyıcıları

+ +

<Directory> +ve <Files> taşıyıcıları, +düzenli ifade karşılıkları ile beraber, yönergeleri dosya sisteminin +parçalarına uygularlar. Bir <Directory> bölümü içindeki yönergeler belli bir dosya sistemi +dizinine ve onun alt dizinlerine uygulanır. Aynı etki .htaccess dosyaları kullanılarak da +sağlanabilir. Örneğin aşağıdaki yapılandırmada, /var/web/dir1 +dizini ve alt dizinlerinde dizin içeriğinin listelenmesi etkin kılınmaktadır.

+ +

+<Directory /var/web/dir1>
+ + Options +Indexes
+
+</Directory> +

+ +

Bir <Files> bölümü içindeki +yönergeler, hangi dizinde bulunduğuna bakılmaksızın ismi belirtilen dosyalara +uygulanır. Örneğin, aşağıdaki yapılandırma yönergeleri yapılandırma dosyasının +ana bölümüne yerleştirildiği takdirde gizli.html isimli dosyalara +nerede bulunursa bulunsun erişime izin vermeyecektir.

+ +

+<Files gizli.html>
+ +Order allow,deny
+Deny from all
+
+</Files> +

+ +

Dosya sisteminin belli bir yerindeki belli dosyalarla ilgili yaptırımlar +için <Files> ve +<Directory> bölümleri +birlikte kullanılabilir. Örneğin, aşağıdaki yapılandırma +/var/web/dir1/gizli.html, +/var/web/dir1/subdir2/gizli.html, +/var/web/dir1/subdir3/gizli.html ve +/var/web/dir1/ altında bulunabilecek diğer tüm +gizli.html dosyalarına erişimi yasaklar.

+ +

+<Directory /var/web/dir1>
+ +<Files gizli.html>
+ +Order allow,deny
+Deny from all
+
+</Files>
+
+</Directory> +

+ + +

Site Alanı Taşıyıcıları

+ +

<Location> yönergesi ve +yönergenin düzenli ifade karşılığı site alanındaki içerik için yapılandırmayı +değiştirir. Örneğin aşağıdaki yapılandırma, /gizli ile başlayan +URL yollarına erişimi engeller. Özellikle, +http://siteniz.mesela.dom/gizli, +http://siteniz.mesela.dom/gizli123 ve +http://siteniz.mesela.dom/gizli/dir/dosya.html istekleri yanında +/gizli ile başlayan diğer isteklere de uygulanır.

+ +

+<Location /gizli>
+ +Order Allow,Deny
+Deny from all
+
+</Location> +

+ +

Dosya sistemi ile etkileşime girmeyen herşey için <Location> yönergesi gerekir. +Aşağıdaki örnekte, belli bir URL’nin mod_status modülü +tarafından sağlanan bir dahili Apache eylemcisine nasıl eşlenebileceği +gösterilmiştir. Bu örnek için dosya sisteminde server-status +adında bir dosya veya dizin bulunması gerekli değildir.

+ +

+<Location /server-status>
+ +SetHandler server-status
+
+</Location> +

+ + +

Dosya Adı Şablonları ve Düzenli İfadeler

+ +

<Directory>, +<Files> ve +<Location> yönergelerinde, +Standart C kütüphanesindeki fnmatch işlevindeki gibi kabuk tarzı +dosya ismi kalıpları kullanılabilir. "*" karakteri herhangi bir karakter dizisi +ile eşleşirken "?" karakteri tek tek karakterlerle ve "[seq]" kalıbı +ise seq içindeki her karakterle eşleşir. "/" karakteri her hangi bir +kalıp karakteri ile eşleşmez; açıkça belirtilmesi gerekir.

+ +

Daha esnek bir eşleşmenin gerekli olduğu durumlar için her taşıyıcının bir +düzenli ifade karşılığı vardır. <DirectoryMatch>, <FilesMatch> ve <LocationMatch> yönergelerinde gerekli eşleşmeleri seçmek için perl +uyumlu düzenli ifadelerin kullanımına izin +verilir. Ayrıca, yönergelerin uygulanışının düzenli ifade bölümleri +kullanılarak nasıl değiştirileceğini öğrenmek için, aşağıda, yapılandırmanın +katıştırılmasıyla ilgili bölüme de bakınız.

+ +

Tüm kullanıcı dizinlerine ilişkin yapılandırmayı değiştirmek için dosya ismi +kalıpları şöyle kullanılabilirdi:

+ +

+<Directory /home/*/public_html>
+ +Options Indexes
+
+</Directory> +

+ +

Düzenli ifade bölümleri kullanarak çeşitli türlerdeki resim dosyalarına +erişimi bir defada yasaklayabiliriz:

+

+<FilesMatch \.(?i:gif|jpe?g|png)$>
+ +Order allow,deny
+Deny from all
+
+</FilesMatch> +

+ + + +

Ne, Ne Zaman Kullanılır?

+ +

Dosya sistemi taşıyıcıları ile site alanı taşıyıcıları arasında seçim +yapmak aslında oldukça kolaydır. Dosya sisteminde bulunan nesnelere +uygulanacak yönergeler için daima <Directory> veya <Files> kullanılır. Dosya sisteminde bulunmayan +nesnelere (bir sayfanın bir veritabanı tarafından üretilmesi gibi) +uygulanacak yönergeler için ise <Location> kullanılır.

+ +

Dosya sistemindeki nesnelere erişimi kısıtlarken asla <Location> kullanmamak önemlidir. +Bunun sebebi farklı site alanı konumlarının (URL’ler) aynı dosya sistemi +konumuna eşlenebilmesi dolayısıyla kısıtlamalarınızın etrafından +dolaşılabilmesine izin vermesidir. Örneğin, aşağıdaki yapılandırmayı +ele alalım:

+ +

+<Location /dir/>
+ +Order allow,deny
+Deny from all
+
+</Location> +

+ +

http://siteniz.mesela.dom/dir/ için bir istek yapılmışsa +bu doğru çalışacaktır. Fakat dosya sistemi harf büyüklüğüne duyarsızsa +ne olacak? Kısıtlamanız, istek http://siteniz.mesela.dom/DIR/ +şeklinde yapılarak kolayca geçersiz kılınabilir. Halbuki <Directory> yönergesi isteğin nasıl +yapıldığına bakılmaksızın bu konumdan sunulan her türlü içeriğe uygulanacaktı. +(Dosya sistemi bağlarıyla bu da aşılabilir. Sembolik bağlar kullanılarak aynı +dizin dosya sisteminin bir çok yerine yerleştirilebilir. <Directory> yönergesi dosya yolunu +sıfırlamaksızın sembolik bağları izleyecektir. Bu bakımdan, en yüksek seviyede +güvenlik için uygun Options yönergesi ile +sembolik bağların izlenmesi devredışı bırakılabilir.)

+ +

Belki de siz sırf harf büyüklüğüne duyarlı bir dosya sistemi +kullanıyorsunuz diye böyle uygulamalara ihtiyacınız olmadığını düşünüyor +olabilirsiniz, fakat aynı site alanını çok sayıda dosya sistemi konumuna +eşleyecek daha bir sürü yol bulunduğunu unutmayınız. Bu bakımdan dosya +sisteminde yapacağınız kısıtlamalarda daima dosya sistemi taşıyıcılarını +kullanmalısınız. Bununla birlikte bu kuralın da bir istisnası vardır. +Yapılandırma kısıtlamalarının bir <Location/> bölümü +içine koyulması, bu bölüme konan yönergelerin etki alanının belli bir URL +ile sınırlı olmaması nedeniyle mükemmelen güvenlidir.

+ + +
top
+
+

Sanal Konaklar

+ +

<VirtualHost> +taşıyıcısının içinde belli bir konağa uygulanan yönergeler bulunur. +Aynı makinede çok sayıda konağı farklı yapılandırmalarla sunuyorsanız +bu taşıyıcı çok işinize yarar. Daha fazla bilgi için Sanal Konak Belgeleri bölümüne bakınız.

+
top
+
+

Vekil

+ +

<Proxy> +ve <ProxyMatch> +taşıyıcıları, sadece belli bir URL ile eşleşen mod_proxy +vekil sunucusu üzerinden erişilen sitelere uygulanan yapılandırma +yönergelerini bulundururlar. Örneğin aşağıdaki yapılandırma +cnn.com sitesine erişim için vekil sunucunun kullanılmasını +engelleyecektir.

+ +

+<Proxy http://cnn.com/*>
+ +Order allow,deny
+Deny from all
+
+</Proxy> +

+
top
+
+

Hangi Yönergelere İzin Veriliyor?

+ +

Hangi yönergelere hangi yapılandırma bölümlerinde izin verildiğini öğrenmek +için yönerge bağlamına bakınız. +<Directory> bölümlerinde +izin verilen herşeye sözdizimsel olarak ayrıca +<DirectoryMatch>, +<Files>, +<FilesMatch>, +<Location>, +<LocationMatch>, +<Proxy> +ve <ProxyMatch> +bölümlerinde de izin verilir. Yine de bazı istisnai durumlar mevcuttur:

+ + +
top
+
+

Bölümler Nasıl Katıştırılır?

+ +

Yapılandırma bölümleri belli bir sıra ile uygulanır. Yapılandırma +yönergelerinin yorumlanışı üzerinde önemli etkilere sahip olabilmesi +nedeniyle neyin ne zaman çalıştığını anlamak çok önemlidir.

+ +

Yapılandırma bölümlerinin katıştırılma sırası şöyledir:

+ +
    +
  1. <Directory> (düzenli ifadeler hariç) + ve .htaccess aynı anda işleme sokulur + (.htaccess ile eğer izin verilmişse <Directory> içindeki bazı + yönergeler geçersiz kılınabileceği için).
  2. + +
  3. <DirectoryMatch> + (ve <Directory ~>).
  4. + +
  5. <Files> ve <FilesMatch> aynı anda işleme sokulur.
  6. + +
  7. <Location> + ve <LocationMatch> + aynı anda işleme sokulur.
  8. +
+ +

<Directory> + bölümündekiler hariç, her grup, yapılandırma dosyasında bulundukları + sıraya göre işleme sokulurlar. Yukarıda 1. grup olan <Directory> bölümü en kısa dizin + elemanından en uzun dizin elemanına doğru işleme sokulur. Yani, örneğin, + <Directory /var/web/dir> bölümü <Directory + /var/web/dir/subdir> bölümünden önce işleme sokulacaktır. + Eğer aynı uzunlukta çok sayıda dizin varsa <Directory> bölümleri yapılandırma dosyasında + bulundukları sıraya göre işleme sokulurlar. Include yönergeleri ile yapılandırmaya dahil + edilen dosyaların içerikleri Include + yönergesinin bulunduğu yere konulduktan sonra işleme sokulurlar.

+ +

<VirtualHost> + bölümlerinin içindeki bölümler, sanal konak tanımı dışındaki + karşılıklarından sonra uygulanırlar.

+ +

Sonraki bölümler öncekileri geçersiz kılmak üzere işleme alınırlar.

+ +

Bazı Teknik Bilgiler

+ Aslında, isim dönüşüm aşamasından (Aliases ve + DocumentRoots, URL’leri dosya isimlerine eşlemek için + kullanılırken) hemen önce uygulanan bir + <Location>/<LocationMatch> + dizisi vardır. Bu dizinin sonuçları isim dönüşüm aşaması tamamlandıktan + sonra tamamen elden çıkarılır. +
+ +

Bazı Örnekler

+ +

Aşağıdaki yapay örnekte katıştırma sırası gösterilmiştir. Hepsinin aynı +isteğe uygulandığı varsayımıyla, bu örnekteki yönergeler A > B > C > D > +E sırasıyla uygulanacaktır.

+ +

+<Location />
+E
+</Location>
+
+<Files f.html>
+D
+</Files>
+
+<VirtualHost *>
+<Directory /a/b>
+B
+</Directory>
+</VirtualHost>
+
+<DirectoryMatch "^.*b$">
+C
+</DirectoryMatch>
+
+<Directory /a/b>
+A
+</Directory>
+
+

+ +

Daha somut bir örnek olarak aşağıdakini ele alalım. <Directory> bölümlerindeki erişim sınırlamaları ne +olursa olsun <Location> +bölümü son olarak değerlendirmeye alınacak ve sunucuya sınırsız erişim verecektir. +Başka bir deyişle, katıştırma sırası önemlidir, bu nedenle dikkatli olmalısınız!

+ +

+<Location />
+ + Order deny,allow
+ Allow from all
+
+</Location>
+
+# Alooo! Bu <Directory> bölümünün hiçbir hükmü yok.
+<Directory />
+ + Order allow,deny
+ Allow from all
+ Deny from kkadam.mesela.dom
+
+</Directory> +

+ + + +
+
+

Mevcut Diller:  en  | + es  | + ja  | + ko  | + tr 

+
+ \ No newline at end of file -- cgit 1.2.3-korg