From: Vincent Bray
Configuring Apache to listen on specific addresses and ports.
@@ -168,7 +169,8 @@ es | fr | ja | - ko + ko | + tr diff --git a/docs/manual/bind.html.es b/docs/manual/bind.html.es index 1c8794d7f9e..06fd8bcc286 100644 --- a/docs/manual/bind.html.es +++ b/docs/manual/bind.html.es @@ -22,7 +22,8 @@ es | fr | ja | - ko + ko | + trCómo configurar Apache para que escuche en direcciones IP @@ -178,7 +179,8 @@ es | fr | ja | - ko
+ ko | + tr diff --git a/docs/manual/bind.html.fr b/docs/manual/bind.html.fr index dd41cb000f2..25bc05d2f76 100644 --- a/docs/manual/bind.html.fr +++ b/docs/manual/bind.html.fr @@ -22,7 +22,8 @@ es | fr | ja | - ko + ko | + trConfiguration des adresses et ports sur lesquels Apache écoute.
@@ -185,7 +186,8 @@ es | fr | ja | - ko + ko | + tr diff --git a/docs/manual/bind.html.ja.utf8 b/docs/manual/bind.html.ja.utf8 index 2fde2b52562..03109953ef4 100644 --- a/docs/manual/bind.html.ja.utf8 +++ b/docs/manual/bind.html.ja.utf8 @@ -22,7 +22,8 @@ es | fr | ja | - ko + ko | + trApache HTTP Sunucusu Sürüm 2.0
-Apacheânin belli adresleri ve portları dinlemek üzere - yapılandırılması.
-İlgili Modüller | İlgili Yönergeler |
---|---|
Apache baÅlatıldıÄında yerel makinedeki bazı adres ve portları kendine - baÄlar ve gelecek istekleri bekler. Ãntanımlı olarak makine üzerindeki - tüm adresleri dinler. Bununla birlikte, belli portları veya sadece - seçilmiÅ bazı adresleri ya da her ikisini de dinlemesi için bunun - belirtilmesi gerekebilir. Bu çoÄunlukla, Apacheânin farklı IP - adreslerine, konak isimlerine ve portlarına nasıl yanıt vereceÄinin - belirlendiÄi sanal konak özelliÄi ile birlikte yürür.
- -Listen
yönergesi sunucuya
- gelen istekleri sadece belli portlardan veya belli adres ve port
- birleÅimlerinden kabul etmesini söyler. Listen
yönergesinde sadece port
- numarası belirtilmiÅse sunucu tüm arabirimlerin belirtilen portunu
- dinleyecektir. Portla birlikte bir IP adresi de belirtilmiÅse sunucu
- belirtilen portu ve arabirimi dinleyecektir. Ãok sayıda adres ve portu
- dinlemek için çok sayıda Listen
yönergesi kullanılabilir. Sunucu
- böyle bir durumda belirtilen bütün adres ve portlardan gelen isteklere
- yanıt verecektir.
ÃrneÄin, sunucunun hem 80 portundan hem de 8000 portundan gelen - baÄlantıları kabul etmesini saÄlamak için,
- -
- Listen 80
- Listen 8000
-
yapılandırmasını kullanabilirsiniz. Sunucunun 80 portuna gelen - baÄlantıları bir arabirimden 8000 portuna gelenleri ise baÅka bir - arabirimden kabul etmesini saÄlamak için ise,
- -
- Listen 192.0.2.1:80
- Listen 192.0.2.5:8000
-
yapılandırmasını kullanabilirsiniz. IPv6 adresleri aÅaÄıdaki örnekteki - gibi köÅeli ayraçlar içine alınarak belirtilmelidir:
- -
- Listen [2001:db8::a00:20ff:fea7:ccea]:80
-
IPv6âyı gerçekleyen platformların sayısı giderek artmaktadır. Bu - platformların çoÄunda APR, Apacheânin IPv6 - soketleri ayırmasını mümkün kılarak IPv6âyı desteklemekte ve IPv6 - üzerinden gönderilmiÅ istekleri elde etmektedir.
- -Apache yöneticilerinin kafasını karıÅtırıran tek Åey IPv6 soketlerin
- hem IPv4 hem de IPv6 baÄlantılarını kabul edip etmeyeceÄidir. IPv4
- baÄlantılarını kabul eden IPv6 soketleri IPv4 eÅlemli IPv6 adresleri
- kullanırlar. Bu çoÄu sistemde öntanımlı olarak böyleyken, FreeBSD,
- NetBSD ve OpenBSDâde sistem geneline uygulanan kurallar gereÄince
- öntanımlı olarak buna izin verilmez; bu sistemlerde özel bir
- configure
parametresi ile Apacheânin davranıÅı
- deÄiÅtirilebilir.
Apacheânin IPv4 ve IPv6 adresleri, IPv4 eÅlemli IPv6 adreslerin
- kullanımını gerektiren en az sayıda soketle kabul etmesini
- istiyorsanız, configure
betiÄine
- --enable-v4-mapped
seçeneÄini belirtiniz ve Listen
yönergesini örnekteki gibi
- kullanınız:
- Listen 80
-
--enable-v4-mapped
seçeneÄi ile derlenen Apache
- tarafından oluÅturulan öntanımlı yapılandırma dosyasındaki Listen
yönergeleri bu biçimi
- kullanacaktır. --enable-v4-mapped
seçeneÄi, FreeBSD,
- NetBSD ve OpenBSD hariç tüm platformlarda öntanımlıdır. Muhtemelen siz
- de Apacheânin böyle derlenmesini isterdiniz.
Platformunuzun ve APRânin neyi desteklediÄine bakmaksızın Apacheânin
- sadece IPv4 adresleri kabul etmesini istiyorsanız, tüm Listen
yönergelerinde örnekteki gibi
- IPv4 adresleri belirtiniz:
- Listen 0.0.0.0:80
- Listen 192.0.2.1:80
-
Apacheânin IPv4 ve IPv6 adresleri ayrı soketlerden kabul etmesini
- (yani IPv4 eÅlemli IPv6 adreslerin iptalini) istiyorsanız
- configure
betiÄine --disable-v4-mapped
- seçeneÄini belirtiniz ve bu amaca yönelik Listen
yönergelerini örnekteki gibi
- belirtiniz:
- Listen [::]:80
- Listen 0.0.0.0:80
-
--disable-v4-mapped
seçeneÄi ile derlenen Apache
- tarafından oluÅturulan öntanımlı yapılandırma dosyasındaki Listen
yönergeleri bu biçimi
- kullanacaktır. --disable-v4-mapped
seçeneÄi, FreeBSD,
- NetBSD ve OpenBSDâde öntanımlıdır.
Listen
yönergesi sanal
- konaklar için gerçeklenmemiÅtir; sadece ana sunucuya hangi adresleri ve
- portları dinleyeceÄini söyler. Hiç <VirtualHost>
yönergesi kullanılmamıÅsa sunucu
- kabul edilen tüm isteklere aynı Åekilde davranacaktır. EÄer bir veya
- daha fazla adres ve port için farklı bir davranıŠbelirtmek
- istiyorsanız <VirtualHost>
kullanabilirsiniz. Bir sanal
- konaÄı gerçeklemek için önce sunucunun sanal konak için kullanacaÄı
- adres ve portu dinleyeceÄini belirtmek gerekir. Bundan sonra bu sanal
- konaÄın davranıÅını ayarlamak üzere belirtilen adres ve port için bir
- <VirtualHost>
bölümü
- oluÅturulmalıdır. Yalnız dikkat edin, eÄer <VirtualHost>
için belirtilen adres ve port
- sunucu tarafından dinlenmiyorsa ona eriÅemezsiniz.
Apache HTTP Sunucusu Sürüm 2.0
+Apacheânin belli adresleri ve portları dinlemek üzere + yapılandırılması.
+İlgili Modüller | İlgili Yönergeler |
---|---|
Apache baÅlatıldıÄında yerel makinedeki bazı adres ve portları kendine + baÄlar ve gelecek istekleri bekler. Ãntanımlı olarak makine üzerindeki + tüm adresleri dinler. Bununla birlikte, belli portları veya sadece + seçilmiÅ bazı adresleri ya da her ikisini de dinlemesi için bunun + belirtilmesi gerekebilir. Bu çoÄunlukla, Apacheânin farklı IP + adreslerine, konak isimlerine ve portlarına nasıl yanıt vereceÄinin + belirlendiÄi sanal konak özelliÄi ile birlikte yürür.
+ +Listen
yönergesi sunucuya
+ gelen istekleri sadece belli portlardan veya belli adres ve port
+ birleÅimlerinden kabul etmesini söyler. Listen
yönergesinde sadece port
+ numarası belirtilmiÅse sunucu tüm arabirimlerin belirtilen portunu
+ dinleyecektir. Portla birlikte bir IP adresi de belirtilmiÅse sunucu
+ belirtilen portu ve arabirimi dinleyecektir. Ãok sayıda adres ve portu
+ dinlemek için çok sayıda Listen
yönergesi kullanılabilir. Sunucu
+ böyle bir durumda belirtilen bütün adres ve portlardan gelen isteklere
+ yanıt verecektir.
ÃrneÄin, sunucunun hem 80 portundan hem de 8000 portundan gelen + baÄlantıları kabul etmesini saÄlamak için,
+ +
+ Listen 80
+ Listen 8000
+
yapılandırmasını kullanabilirsiniz. Sunucunun 80 portuna gelen + baÄlantıları bir arabirimden 8000 portuna gelenleri ise baÅka bir + arabirimden kabul etmesini saÄlamak için ise,
+ +
+ Listen 192.0.2.1:80
+ Listen 192.0.2.5:8000
+
yapılandırmasını kullanabilirsiniz. IPv6 adresleri aÅaÄıdaki örnekteki + gibi köÅeli ayraçlar içine alınarak belirtilmelidir:
+ +
+ Listen [2001:db8::a00:20ff:fea7:ccea]:80
+
IPv6âyı gerçekleyen platformların sayısı giderek artmaktadır. Bu + platformların çoÄunda APR, Apacheânin IPv6 + soketleri ayırmasını mümkün kılarak IPv6âyı desteklemekte ve IPv6 + üzerinden gönderilmiÅ istekleri elde etmektedir.
+ +Apache yöneticilerinin kafasını karıÅtırıran tek Åey IPv6 soketlerin
+ hem IPv4 hem de IPv6 baÄlantılarını kabul edip etmeyeceÄidir. IPv4
+ baÄlantılarını kabul eden IPv6 soketleri IPv4 eÅlemli IPv6 adresleri
+ kullanırlar. Bu çoÄu sistemde öntanımlı olarak böyleyken, FreeBSD,
+ NetBSD ve OpenBSDâde sistem geneline uygulanan kurallar gereÄince
+ öntanımlı olarak buna izin verilmez; bu sistemlerde özel bir
+ configure
parametresi ile Apacheânin davranıÅı
+ deÄiÅtirilebilir.
Apacheânin IPv4 ve IPv6 adresleri, IPv4 eÅlemli IPv6 adreslerin
+ kullanımını gerektiren en az sayıda soketle kabul etmesini
+ istiyorsanız, configure
betiÄine
+ --enable-v4-mapped
seçeneÄini belirtiniz ve Listen
yönergesini örnekteki gibi
+ kullanınız:
+ Listen 80
+
--enable-v4-mapped
seçeneÄi ile derlenen Apache
+ tarafından oluÅturulan öntanımlı yapılandırma dosyasındaki Listen
yönergeleri bu biçimi
+ kullanacaktır. --enable-v4-mapped
seçeneÄi, FreeBSD,
+ NetBSD ve OpenBSD hariç tüm platformlarda öntanımlıdır. Muhtemelen siz
+ de Apacheânin böyle derlenmesini isterdiniz.
Platformunuzun ve APRânin neyi desteklediÄine bakmaksızın Apacheânin
+ sadece IPv4 adresleri kabul etmesini istiyorsanız, tüm Listen
yönergelerinde örnekteki gibi
+ IPv4 adresleri belirtiniz:
+ Listen 0.0.0.0:80
+ Listen 192.0.2.1:80
+
Apacheânin IPv4 ve IPv6 adresleri ayrı soketlerden kabul etmesini
+ (yani IPv4 eÅlemli IPv6 adreslerin iptalini) istiyorsanız
+ configure
betiÄine --disable-v4-mapped
+ seçeneÄini belirtiniz ve bu amaca yönelik Listen
yönergelerini örnekteki gibi
+ belirtiniz:
+ Listen [::]:80
+ Listen 0.0.0.0:80
+
--disable-v4-mapped
seçeneÄi ile derlenen Apache
+ tarafından oluÅturulan öntanımlı yapılandırma dosyasındaki Listen
yönergeleri bu biçimi
+ kullanacaktır. --disable-v4-mapped
seçeneÄi, FreeBSD,
+ NetBSD ve OpenBSDâde öntanımlıdır.
Listen
yönergesi sanal
+ konaklar için gerçeklenmemiÅtir; sadece ana sunucuya hangi adresleri ve
+ portları dinleyeceÄini söyler. Hiç <VirtualHost>
yönergesi kullanılmamıÅsa sunucu
+ kabul edilen tüm isteklere aynı Åekilde davranacaktır. EÄer bir veya
+ daha fazla adres ve port için farklı bir davranıŠbelirtmek
+ istiyorsanız <VirtualHost>
kullanabilirsiniz. Bir sanal
+ konaÄı gerçeklemek için önce sunucunun sanal konak için kullanacaÄı
+ adres ve portu dinleyeceÄini belirtmek gerekir. Bundan sonra bu sanal
+ konaÄın davranıÅını ayarlamak üzere belirtilen adres ve port için bir
+ <VirtualHost>
bölümü
+ oluÅturulmalıdır. Yalnız dikkat edin, eÄer <VirtualHost>
için belirtilen adres ve port
+ sunucu tarafından dinlenmiyorsa ona eriÅemezsiniz.
Verfügbare Sprachen: de | en | es | - ko
+ ko | + trVerfügbare Sprachen: de | en | es | - ko
+ ko | + trAvailable Languages: de | en | es | - ko
+ ko | + trThis glossary defines some of the common terminology related to Apache in @@ -440,7 +441,8 @@
Available Languages: de | en | es | - ko
+ ko | + tr diff --git a/docs/manual/glossary.html.es b/docs/manual/glossary.html.es index 5b08dc32466..5f4cf55936d 100644 --- a/docs/manual/glossary.html.es +++ b/docs/manual/glossary.html.es @@ -21,7 +21,8 @@Idiomas disponibles: de | en | es | - ko
+ ko | + trIdiomas disponibles: de | en | es | - ko
+ ko | + tr°¡´ÉÇÑ ¾ð¾î: de | en | es | - ko
+ ko | + tr°¡´ÉÇÑ ¾ð¾î: de | en | es | - ko
+ ko | + tr diff --git a/docs/manual/glossary.html.tr.utf8 b/docs/manual/glossary.html.tr.utf8 index 1ef86f86202..4972b20fb4f 100644 --- a/docs/manual/glossary.html.tr.utf8 +++ b/docs/manual/glossary.html.tr.utf8 @@ -1,460 +1,460 @@ - - - -Apache HTTP Sunucusu Sürüm 2.0
-Bu sözlük, genelinde HTML sayfa sunumuna, özelinde Apache HTTP Sunucusuna - özgü ortak terminolojinin bir kısmını içerir. Her kavram ile ilgili daha - ayrıntılı bilgi baÄlarla saÄlanmıÅtır.
-apxs
kılavuz
- sayfasına bakınız.
- httpd
- çalıÅtırılabilir dosyasından ayrı olarak derlenmiÅ â modüllerin ortak adı./resimler/.*(jpg|gif)$
â düzenli
- ifadesi yazılabilir. Apache, PCRE
- kütüphanesi ile saÄlanan Perl uyumlu düzenli ifadeleri kullanır.
- cgi-script
eylemcisi dosyaları
- â CGIâler tarafından iÅlenebilir hale
- getirmek üzere iÅleme sokar./usr/local/apache2/conf/httpd.conf
olup derleme
- sırasındaki yapılandırmayla veya çalıÅma anındaki yapılandırmayla
- baÅka bir yer belirtilebilir.text/html
,
- image/gif
ve application/octet-stream
örnek
- olarak verilebilir. HTTP protokolünde MIME türleri
- Content-Type
â baÅlıÄında
- aktarılır.httpd
- çalıÅtırılabiliri içinde derlenmiÅ modüllere duraÄan modüller
- adı verilirken ayrı bir yerde saklanan ve çalıÅma anında isteÄe baÄlı
- olarak yüklenebilen modüllere devingen modüller veya
- â DSOâlar denir. Yapılandırmaya öntanımlı
- olarak dahil edilen modüllere temel modüller denir. Apache
- için kullanılabilecek modüllerin çoÄu Apache HTTP Sunucusunun
- â tar paketi içinde daÄıtılmaz; bunlara
- üçüncü parti modüller denir.INCLUDES
çıkıŠsüzgeci, belgeleri â sunucu taraflı içerik için iÅleme sokar.httpd.apache.org
tam alan adında httpd
bir konak
- adıyken apache.org
bir alan adıdır.
- tar
uygulaması kullanılarak bir araya getirilmiÅ
- dosyalardan oluÅan bir paket. Apache daÄıtımları sıkıÅtırılmıŠtar
- arÅivleri içinde veya pkzip kullanılarak saklanır.
- http
veya
- https
gibi bir Åemayı takip eden bir konak adı ve bir dosya
- yolundan oluÅurlar. ÃrneÄin, bu sayfanın URLâsi
- http://httpd.apache.org/docs/2.0/glossary.html
olurdu.
- GET
,
- POST
ve PUT
verilebilir.
- Apache HTTP Sunucusu Sürüm 2.0
+Bu sözlük, genelinde HTML sayfa sunumuna, özelinde Apache HTTP Sunucusuna + özgü ortak terminolojinin bir kısmını içerir. Her kavram ile ilgili daha + ayrıntılı bilgi baÄlarla saÄlanmıÅtır.
+apxs
kılavuz
+ sayfasına bakınız.
+ httpd
+ çalıÅtırılabilir dosyasından ayrı olarak derlenmiÅ â modüllerin ortak adı./resimler/.*(jpg|gif)$
â düzenli
+ ifadesi yazılabilir. Apache, PCRE
+ kütüphanesi ile saÄlanan Perl uyumlu düzenli ifadeleri kullanır.
+ cgi-script
eylemcisi dosyaları
+ â CGIâler tarafından iÅlenebilir hale
+ getirmek üzere iÅleme sokar./usr/local/apache2/conf/httpd.conf
olup derleme
+ sırasındaki yapılandırmayla veya çalıÅma anındaki yapılandırmayla
+ baÅka bir yer belirtilebilir.text/html
,
+ image/gif
ve application/octet-stream
örnek
+ olarak verilebilir. HTTP protokolünde MIME türleri
+ Content-Type
â baÅlıÄında
+ aktarılır.httpd
+ çalıÅtırılabiliri içinde derlenmiÅ modüllere duraÄan modüller
+ adı verilirken ayrı bir yerde saklanan ve çalıÅma anında isteÄe baÄlı
+ olarak yüklenebilen modüllere devingen modüller veya
+ â DSOâlar denir. Yapılandırmaya öntanımlı
+ olarak dahil edilen modüllere temel modüller denir. Apache
+ için kullanılabilecek modüllerin çoÄu Apache HTTP Sunucusunun
+ â tar paketi içinde daÄıtılmaz; bunlara
+ üçüncü parti modüller denir.INCLUDES
çıkıŠsüzgeci, belgeleri â sunucu taraflı içerik için iÅleme sokar.httpd.apache.org
tam alan adında httpd
bir konak
+ adıyken apache.org
bir alan adıdır.
+ tar
uygulaması kullanılarak bir araya getirilmiÅ
+ dosyalardan oluÅan bir paket. Apache daÄıtımları sıkıÅtırılmıŠtar
+ arÅivleri içinde veya pkzip kullanılarak saklanır.
+ http
veya
+ https
gibi bir Åemayı takip eden bir konak adı ve bir dosya
+ yolundan oluÅurlar. ÃrneÄin, bu sayfanın URLâsi
+ http://httpd.apache.org/docs/2.0/glossary.html
olurdu.
+ GET
,
+ POST
ve PUT
verilebilir.
+ Dieses Dokument umfaßt nur die Kompilierung und Installation des @@ -397,7 +398,8 @@ es | ja | ko | - ru
+ ru | + tr diff --git a/docs/manual/install.html.en b/docs/manual/install.html.en index 1f27a6e0bdd..3d9dd349bff 100644 --- a/docs/manual/install.html.en +++ b/docs/manual/install.html.en @@ -23,7 +23,8 @@ es | ja | ko | - ru + ru | + tr @@ -377,7 +378,8 @@ $ tar xvf httpd-2_0_NN.tar es | ja | ko | - ru + ru | + tr diff --git a/docs/manual/install.html.es b/docs/manual/install.html.es index 796cc695d84..7a771486e40 100644 --- a/docs/manual/install.html.es +++ b/docs/manual/install.html.es @@ -23,7 +23,8 @@ es | ja | ko | - ru + ru | + trApache HTTP Sunucusu Sürüm 2.0
-Bu belge Apacheânin sadece Unix ve Unix benzeri sistemlerde - derlenmesini ve kurulmasını kapsar. Windows üzerinde derleme ve kurulum - için Apacheânin Microsoft Windows ile - kullanımı bölümüne bakınız. DiÄer platformlar için ise platform belgelerine bakınız.
- -Apache 2.0âın yapılandırma ve kurulum ortamı Apache 1.3âe göre tamamen deÄiÅmiÅtir. Apache 1.3, kurulumu kolaylaÅtırmak için özel bazı betikler kullanırdı. Apache 2.0 ise artık derleme ortamını oluÅturmak için çoÄu Açık Kaynak Kodlu projenin yaptıÄı gibi libtool
ve autoconf
kullanmaktadır.
EÄer sadece sürüm yükseltiyorsanız (2.0.50âden 2.0.51âe yükseltmek - gibi) lütfen doÄrudan Yükseltme bölümüne - atlayınız.
- -İndirme | - -$ lynx http://httpd.apache.org/download.cgi
- |
-
Paketi açma | - -$ gzip -d httpd-2_0_NN.tar.gz |
Yapılandırma | - -$ ./configure --prefix=ÃNEK
- |
-
Derleme | - -$ make |
-
Kurulum | - -$ make install |
-
KiÅiselleÅtirme | - -$ vi ÃNEK/conf/httpd.conf |
-
Deneme | - -$ ÃNEK/bin/apachectl start
- |
-
NN yerine kuracaÄınız alt sürümü, ÃNEK
- yerine de dosya sisteminde sunucunun altına kurulacaÄı dizin yolunu
- yazınız. ÃNEK
belirtilmezse
- /usr/local/apache2
öntanımlıdır.
Derleme ve kurulum iÅleminin her aÅaması, Apache httpdânin derlenmesi - ve kurulması için gerekenler baÅta olmak üzere aÅaÄıda ayrıntılı olarak - açıklanmıÅtır.
-Apacheâyi derleyebilmek için Åunlar mevcut olmalıdır:
- -PATH
ortam deÄiÅkeninizin içerdiÄi
- yollarda make
gibi temel derleme araçları da
- bulunmalıdır.ntpdate
veya
- xntpd
programları kullanılır. NTP yazılımları ve halka
- açık zaman sunucuları hakkında daha ayrıntılı bilgi için NTP sitesine ve Usenet comp.protocols.time.ntp haber
- grubuna bakınız.apxs
veya
- dbmmanage
gibi bazı betikleri desteklemek için
- Perl 5 yorumlayıcısı gerekir (5.003 veya daha yeni sürümleri
- yeterlidir). EÄer sisteminizde birden fazla Perl yorumlayıcı
- kuruluysa (örneÄin, sistem geneli için Perl 4, kendi kullanımızı için
- Perl 5 kurulu olabilir), doÄru sürümün kullanılacaÄından emin olmak
- bunu configure
betiÄine --with-perl
- seçeneÄini kullanarak belirtmeniz önerilir. EÄer
- configure
betiÄi sisteminizde Perl 5 yorumlayıcısı
- bulamazsa bu betikleri kullanamazsınız. Ancak, bu durum Apache
- 2.0âın derlenip kurulmasına engel deÄildir.Apache HTTP Sunucusunu, çeÅitli yansıların da listelendiÄi Apache HTTP Sunucusu
- indirme sayfasından indirebilirsiniz. Unix benzeri sistemler
- kullanan Apache kullanıcılarının kaynak paketlerinden birini indirip
- derlemeleri daha iyi olacaktır. Derleme iÅlemi (aÅaÄıda açıklanmıÅtır)
- kolaydır ve sunucunuzu ihtiyaçlarınıza uygun olarak kiÅiselleÅtirmenize
- imkan tanır. Ayrıca, hazır derlenmiÅ paketler çoÄunlukla en son kaynak
- sürüm kadar güncel deÄildirler. EÄer böyle bir paket indirmiÅseniz,
- kurarken paketin içinde bulunan INSTALL.bindist
- dosyasındaki talimatlara uyunuz.
İndirme iÅleminin ardından Apache HTTP Sunucusunun eksiksiz ve - deÄiÅikliÄe uÄramamıŠolduÄunun doÄrulanması önemlidir. Bu indirilen - tar paketinin PGP imzasına göre sınanması ile saÄlanabilir. Bunun nasıl - yapılacaÄı indirme - sayfasında anlatıldıÄı gibi PGP - kullanımının anlatıldıÄı daha geniÅ bir örnek de vardır.
- -Apache HTTPD tar paketinden sıkıÅtırmayı kaldırdıktan sonra tar - arÅivinden dosyaları çıkarmak basit bir iÅlemdir:
- -
-$ gzip -d httpd-2_0_NN.tar.gz
-$ tar xvf httpd-2_0_NN.tar
-
Bu iÅlem bulunduÄunuz dizinin içinde daÄıtımın kaynak dosyalarını
- içeren yeni bir dizin oluÅturacaktır. Sunucuyu derleme iÅlmine
- baÅlayabilmek için önce cd
ile bu dizine geçmelisiniz.
Sonraki adım, Apache kaynak aÄacının platformunuza ve kiÅisel
- gereksinimlerinize uygun olarak yapılandırılmasıdır. Bu iÅlem daÄıtımın
- kök dizininde bulunan configure
betiÄi kullanılarak
- yapılır. (Apache kaynak aÄacının CVS sürümünü
- indiren geliÅtiricilerin sistemlerinde autoconf
ve
- libtool
kurulu olması ve sonraki adıma geçmek için
- buildconf
çalıÅtırmaları gerekir. Bu iÅlem resmi
- daÄıtımlar için gerekli deÄildir.)
Kaynak aÄacını tamamen öntanımlı seçenekler kullanılarak derlemek için
- ./configure
komutunu vermek yeterlidir. Ãntanımlı
- seçenekleri deÄiÅtirmek için configure
betiÄi
- çeÅitli deÄiÅkenler ve komut satırı seçenekleri kabul eder.
En önemli seçenek, Apacheânin kurulacaÄı yerin belirlenmesini,
- dolayısıyla Apacheânin bu konumda doÄru olarak çalıÅması için
- yapılandırılmasını saÄlayan --prefix
âtir. Kurulacak
- dosyaların yerleri ile ilgili daha ayrıntılı denetim ek yapılandırma
- seçenekleri ile mümkün kılınmıÅtır.
Bu noktada ayrıca, Apacheâde hangi özelliklerin bulunmasını
- istediÄinizi modülleri etkin kılarak veya iptal
- ederek belirtebilirsiniz. Apache, öntanımlı olarak içerilmiÅ temel modüllerle gelir. DiÄer
- modüller --enable-modül
seçenekleri
- kullanılarak etkinleÅtirilir. Buradaki modül
,
- önünden mod_
dizgesi kaldırılmıŠve içindeki altçizgi
- imleri tire imleri ile deÄiÅtirilmiÅ modül ismidir. Ayrıca,
- --enable-modül=shared
seçeneklerini kullanarak
- modülleri çalıÅma anında gerektiÄinde yüklemek veya kaldırmak üzere paylaÅımlı nesneler (DSOâlar) olarak derlemeniz de
- mümkündür. Temel modülleri de benzer Åekilde
- --disable-modül
seçenekleriyle iptal
- edebilirsiniz. configure
betiÄi mevcut olmayan
- modüller için sizi uyarmayıp, seçeneÄi yok saymakla yetineceÄinden, bu
- seçenekleri kullanırken dikkatli olmalısınız.
Ek olarak, bazen kullandıÄınız derleyici, kütüphaneler veya baÅlık
- dosyalarının yerleri hakkında configure
betiÄine
- ilave bilgiler saÄlamanız gerekir. Bu iÅlem
- configure
betiÄine ya ortam deÄiÅkenleriyle ya da
- komut satırı seçenekleriyle bilgi aktarılarak yapılır. Daha fazla bilgi
- için configure
kılavuz sayfasına bakınız.
Apacheâyi derlerken ne gibi olasılıklara sahip olduÄunuz hakkında bir
- izlenim edinmeniz için aÅaÄıda tipik bir örneÄe yer verilmiÅtir. Bu
- örnekte, Apacheânin /sw/pkg/apache
önekiyle baÅlayan
- dizinlere kurulması, belli bir derleyici ve derleyici seçenekleriyle
- derlenmesi ve mod_rewrite
ve
- mod_speling
modüllerinin de DSO mekanizması üzerinden
- daha sonra yüklenmek üzere derlenmesi istenmektedir:
- $ CC="pgcc" CFLAGS="-O2" \
- ./configure --prefix=/sw/pkg/apache \
- --enable-rewrite=shared \
- --enable-speling=shared
-
configure
betiÄi baÅlatıldıÄında sisteminizde
- mevcut özelliklerin iÅe yararlıÄını sınamak ve sonradan sunucuyu
- derlemek için kullanılacak Makefile dosyalarını oluÅturmak için bir kaç
- dakika çalıÅacaktır.
configure
seçeneklerinin tamamı ayrıtılı olarak
- configure
kılavuz sayfasında açıklanmıÅtır.
Artık, Apache paketini Åekillendiren çeÅitli parçaları derlemek için - basitçe aÅaÄıdaki komutu verebilirsiniz:
- -$ make
Bu komutu verdikten sonra lütfen sabırlı olunuz. Temel yapılandırmanın - derlenmesi bir Pentium III/Linux 2.2 makinede 3 dakika alsa da - modüllerin derlenmesi donanımınıza ve seçtiÄiniz modüllerin sayısına - baÄlı olarak daha uzun süre gerektirecektir.
-Åimdi sıra ÃNEK
dizini altına kurulmak üzere
- yapılandırdıÄınız (yukarı --prefix
seçeneÄine bakınız)
- paketi kurmaya geldi. Basitçe Åu komutu veriniz:
# make install
ÃNEK
dizininde genellikle yazma izinlerinin
- sınırlı oluÅu nedeniyle bu adım genellikle root yetkilerini
- gerektirir.
EÄer sürüm yükseltiyorsanız, kurulum sırasında mevcut yapılandırma - dosyalarının ve belgelerin üzerine yazılmayacaktır.
-Bu adımda, Apache HTTP sunucunuzu ÃNEK/conf/
- dizini altındaki yapılandırma
- dosyalarını düzenleyerek kiÅiselleÅtirebilirsiniz.
$ vi ÃNEK/conf/httpd.conf
Bu kılavuz ve kullanılabilecek yapılandırma yönergelerinin kılavuzlarını - docs/manual/ altında bulabileceÄiniz gibi en - son sürümünü daima http://httpd.apache.org/docs/2.0/ adresinde - bulabilirsiniz.
-Artık Apache HTTP sunucunuzu baÅlatmaya - hazırsınız. Hemen Åu komutu verin:
- -$ ÃNEK/bin/apachectl start
http://localhost/
üzerinden ilk belgeniz için bir istek
- yapmalısınız. Genellikle DocumentRoot
olarak bilinen
- ÃNEK/htdocs/
altındaki sayfayı görürsünüz.
- ÃalıÅmakta olan sunucuyu durdurmak için Åu
- komutu verebilirsiniz:
$ ÃNEK/bin/apachectl stop
Sürüm yükseltme iÅleminin ilk adımı, sitenizi etkileyen deÄiÅiklikleri
- öÄrenmek için daÄıtım duyurusunu ve kaynak paketindeki
- CHANGES
dosyasını okumaktır. Ana sürümlerden yükseltme
- yapıyorsanız (1.3âten 2.0âa veya 2.0âdan 2.2âye gibi), derleme anı ve
- çalıÅma anı yapılandırmalarındaki ana farklılıklar elle ayarlamalar
- yapmanızı gerektirecektir. Ayrıca, tüm modüllerin de modül APIâsindeki
- deÄiÅikliklere uyum saÄlaması için yükseltilmesi gerekecektir.
Aynı ana sürüm içinde yükseltme yapmak (2.0.55âten 2.0.57âye
- yükseltmek gibi) daha kolaydır. make install
iÅlemi,
- mevcut yapılandırma ve günlük dosyalarınızın ve belgelerin üzerine
- yazmayacaktır. Ek olarak, geliÅtiriciler alt sürüm deÄiÅikliklerinde
- configure
seçenekleri, çalıÅma anı yapılandırması
- veya modül APIâsinde uyumsuz deÄiÅiklikler yapmamaya özen
- göstereceklerdir. ÃoÄu durumda, aynı configure
komut
- satırını, aynı yapılandırma dosyasını kullanabileceksiniz ve tüm
- modülleriniz de çalıÅmaya devam edebilecektir. (Bu sadece 2.0.41 sürümünden sonrası için geçerlidir; daha önceki sürümler için uyumluluk söz konusu deÄildir.)
Aynı ana sürüm içinde yükseltme iÅlemine, eski kaynak aÄacının kök
- dizininde veya kurulu sunucunuzun build
dizininde
- bulacaÄınız config.nice
dosyasını yeni kaynak aÄacının kök
- dizinine kopyalamak suretiyle baÅlayabilirsiniz. Bu dosya evvelce
- kaynak aÄacını yapılandırmakta kullandıÄınız
- configure
komut satırını içerir.
- config.nice
dosyasında yapmak istediÄiniz deÄiÅiklikler
- varsa yaptıktan sonra Åu komutları veriniz:
- $ ./config.nice
- $ make
- $ make install
- $ ÃNEK/bin/apachectl graceful-stop
- $ ÃNEK/bin/apachectl start
-
--prefix
ile kurabilir ve farklı bir port ile
- (Listen
yönergesini
- ayarlamak suretiyle) çalıÅtırabilirsiniz.Apache HTTP Sunucusu Sürüm 2.0
+Bu belge Apacheânin sadece Unix ve Unix benzeri sistemlerde + derlenmesini ve kurulmasını kapsar. Windows üzerinde derleme ve kurulum + için Apacheânin Microsoft Windows ile + kullanımı bölümüne bakınız. DiÄer platformlar için ise platform belgelerine bakınız.
+ +Apache 2.0âın yapılandırma ve kurulum ortamı Apache 1.3âe göre tamamen deÄiÅmiÅtir. Apache 1.3, kurulumu kolaylaÅtırmak için özel bazı betikler kullanırdı. Apache 2.0 ise artık derleme ortamını oluÅturmak için çoÄu Açık Kaynak Kodlu projenin yaptıÄı gibi libtool
ve autoconf
kullanmaktadır.
EÄer sadece sürüm yükseltiyorsanız (2.0.50âden 2.0.51âe yükseltmek + gibi) lütfen doÄrudan Yükseltme bölümüne + atlayınız.
+ +İndirme | + +$ lynx http://httpd.apache.org/download.cgi
+ |
+
Paketi açma | + +$ gzip -d httpd-2_0_NN.tar.gz |
Yapılandırma | + +$ ./configure --prefix=ÃNEK
+ |
+
Derleme | + +$ make |
+
Kurulum | + +$ make install |
+
KiÅiselleÅtirme | + +$ vi ÃNEK/conf/httpd.conf |
+
Deneme | + +$ ÃNEK/bin/apachectl start
+ |
+
NN yerine kuracaÄınız alt sürümü, ÃNEK
+ yerine de dosya sisteminde sunucunun altına kurulacaÄı dizin yolunu
+ yazınız. ÃNEK
belirtilmezse
+ /usr/local/apache2
öntanımlıdır.
Derleme ve kurulum iÅleminin her aÅaması, Apache httpdânin derlenmesi + ve kurulması için gerekenler baÅta olmak üzere aÅaÄıda ayrıntılı olarak + açıklanmıÅtır.
+Apacheâyi derleyebilmek için Åunlar mevcut olmalıdır:
+ +PATH
ortam deÄiÅkeninizin içerdiÄi
+ yollarda make
gibi temel derleme araçları da
+ bulunmalıdır.ntpdate
veya
+ xntpd
programları kullanılır. NTP yazılımları ve halka
+ açık zaman sunucuları hakkında daha ayrıntılı bilgi için NTP sitesine ve Usenet comp.protocols.time.ntp haber
+ grubuna bakınız.apxs
veya
+ dbmmanage
gibi bazı betikleri desteklemek için
+ Perl 5 yorumlayıcısı gerekir (5.003 veya daha yeni sürümleri
+ yeterlidir). EÄer sisteminizde birden fazla Perl yorumlayıcı
+ kuruluysa (örneÄin, sistem geneli için Perl 4, kendi kullanımızı için
+ Perl 5 kurulu olabilir), doÄru sürümün kullanılacaÄından emin olmak
+ bunu configure
betiÄine --with-perl
+ seçeneÄini kullanarak belirtmeniz önerilir. EÄer
+ configure
betiÄi sisteminizde Perl 5 yorumlayıcısı
+ bulamazsa bu betikleri kullanamazsınız. Ancak, bu durum Apache
+ 2.0âın derlenip kurulmasına engel deÄildir.Apache HTTP Sunucusunu, çeÅitli yansıların da listelendiÄi Apache HTTP Sunucusu
+ indirme sayfasından indirebilirsiniz. Unix benzeri sistemler
+ kullanan Apache kullanıcılarının kaynak paketlerinden birini indirip
+ derlemeleri daha iyi olacaktır. Derleme iÅlemi (aÅaÄıda açıklanmıÅtır)
+ kolaydır ve sunucunuzu ihtiyaçlarınıza uygun olarak kiÅiselleÅtirmenize
+ imkan tanır. Ayrıca, hazır derlenmiÅ paketler çoÄunlukla en son kaynak
+ sürüm kadar güncel deÄildirler. EÄer böyle bir paket indirmiÅseniz,
+ kurarken paketin içinde bulunan INSTALL.bindist
+ dosyasındaki talimatlara uyunuz.
İndirme iÅleminin ardından Apache HTTP Sunucusunun eksiksiz ve + deÄiÅikliÄe uÄramamıŠolduÄunun doÄrulanması önemlidir. Bu indirilen + tar paketinin PGP imzasına göre sınanması ile saÄlanabilir. Bunun nasıl + yapılacaÄı indirme + sayfasında anlatıldıÄı gibi PGP + kullanımının anlatıldıÄı daha geniÅ bir örnek de vardır.
+ +Apache HTTPD tar paketinden sıkıÅtırmayı kaldırdıktan sonra tar + arÅivinden dosyaları çıkarmak basit bir iÅlemdir:
+ +
+$ gzip -d httpd-2_0_NN.tar.gz
+$ tar xvf httpd-2_0_NN.tar
+
Bu iÅlem bulunduÄunuz dizinin içinde daÄıtımın kaynak dosyalarını
+ içeren yeni bir dizin oluÅturacaktır. Sunucuyu derleme iÅlmine
+ baÅlayabilmek için önce cd
ile bu dizine geçmelisiniz.
Sonraki adım, Apache kaynak aÄacının platformunuza ve kiÅisel
+ gereksinimlerinize uygun olarak yapılandırılmasıdır. Bu iÅlem daÄıtımın
+ kök dizininde bulunan configure
betiÄi kullanılarak
+ yapılır. (Apache kaynak aÄacının CVS sürümünü
+ indiren geliÅtiricilerin sistemlerinde autoconf
ve
+ libtool
kurulu olması ve sonraki adıma geçmek için
+ buildconf
çalıÅtırmaları gerekir. Bu iÅlem resmi
+ daÄıtımlar için gerekli deÄildir.)
Kaynak aÄacını tamamen öntanımlı seçenekler kullanılarak derlemek için
+ ./configure
komutunu vermek yeterlidir. Ãntanımlı
+ seçenekleri deÄiÅtirmek için configure
betiÄi
+ çeÅitli deÄiÅkenler ve komut satırı seçenekleri kabul eder.
En önemli seçenek, Apacheânin kurulacaÄı yerin belirlenmesini,
+ dolayısıyla Apacheânin bu konumda doÄru olarak çalıÅması için
+ yapılandırılmasını saÄlayan --prefix
âtir. Kurulacak
+ dosyaların yerleri ile ilgili daha ayrıntılı denetim ek yapılandırma
+ seçenekleri ile mümkün kılınmıÅtır.
Bu noktada ayrıca, Apacheâde hangi özelliklerin bulunmasını
+ istediÄinizi modülleri etkin kılarak veya iptal
+ ederek belirtebilirsiniz. Apache, öntanımlı olarak içerilmiÅ temel modüllerle gelir. DiÄer
+ modüller --enable-modül
seçenekleri
+ kullanılarak etkinleÅtirilir. Buradaki modül
,
+ önünden mod_
dizgesi kaldırılmıŠve içindeki altçizgi
+ imleri tire imleri ile deÄiÅtirilmiÅ modül ismidir. Ayrıca,
+ --enable-modül=shared
seçeneklerini kullanarak
+ modülleri çalıÅma anında gerektiÄinde yüklemek veya kaldırmak üzere paylaÅımlı nesneler (DSOâlar) olarak derlemeniz de
+ mümkündür. Temel modülleri de benzer Åekilde
+ --disable-modül
seçenekleriyle iptal
+ edebilirsiniz. configure
betiÄi mevcut olmayan
+ modüller için sizi uyarmayıp, seçeneÄi yok saymakla yetineceÄinden, bu
+ seçenekleri kullanırken dikkatli olmalısınız.
Ek olarak, bazen kullandıÄınız derleyici, kütüphaneler veya baÅlık
+ dosyalarının yerleri hakkında configure
betiÄine
+ ilave bilgiler saÄlamanız gerekir. Bu iÅlem
+ configure
betiÄine ya ortam deÄiÅkenleriyle ya da
+ komut satırı seçenekleriyle bilgi aktarılarak yapılır. Daha fazla bilgi
+ için configure
kılavuz sayfasına bakınız.
Apacheâyi derlerken ne gibi olasılıklara sahip olduÄunuz hakkında bir
+ izlenim edinmeniz için aÅaÄıda tipik bir örneÄe yer verilmiÅtir. Bu
+ örnekte, Apacheânin /sw/pkg/apache
önekiyle baÅlayan
+ dizinlere kurulması, belli bir derleyici ve derleyici seçenekleriyle
+ derlenmesi ve mod_rewrite
ve
+ mod_speling
modüllerinin de DSO mekanizması üzerinden
+ daha sonra yüklenmek üzere derlenmesi istenmektedir:
+ $ CC="pgcc" CFLAGS="-O2" \
+ ./configure --prefix=/sw/pkg/apache \
+ --enable-rewrite=shared \
+ --enable-speling=shared
+
configure
betiÄi baÅlatıldıÄında sisteminizde
+ mevcut özelliklerin iÅe yararlıÄını sınamak ve sonradan sunucuyu
+ derlemek için kullanılacak Makefile dosyalarını oluÅturmak için bir kaç
+ dakika çalıÅacaktır.
configure
seçeneklerinin tamamı ayrıtılı olarak
+ configure
kılavuz sayfasında açıklanmıÅtır.
Artık, Apache paketini Åekillendiren çeÅitli parçaları derlemek için + basitçe aÅaÄıdaki komutu verebilirsiniz:
+ +$ make
Bu komutu verdikten sonra lütfen sabırlı olunuz. Temel yapılandırmanın + derlenmesi bir Pentium III/Linux 2.2 makinede 3 dakika alsa da + modüllerin derlenmesi donanımınıza ve seçtiÄiniz modüllerin sayısına + baÄlı olarak daha uzun süre gerektirecektir.
+Åimdi sıra ÃNEK
dizini altına kurulmak üzere
+ yapılandırdıÄınız (yukarı --prefix
seçeneÄine bakınız)
+ paketi kurmaya geldi. Basitçe Åu komutu veriniz:
# make install
ÃNEK
dizininde genellikle yazma izinlerinin
+ sınırlı oluÅu nedeniyle bu adım genellikle root yetkilerini
+ gerektirir.
EÄer sürüm yükseltiyorsanız, kurulum sırasında mevcut yapılandırma + dosyalarının ve belgelerin üzerine yazılmayacaktır.
+Bu adımda, Apache HTTP sunucunuzu ÃNEK/conf/
+ dizini altındaki yapılandırma
+ dosyalarını düzenleyerek kiÅiselleÅtirebilirsiniz.
$ vi ÃNEK/conf/httpd.conf
Bu kılavuz ve kullanılabilecek yapılandırma yönergelerinin kılavuzlarını + docs/manual/ altında bulabileceÄiniz gibi en + son sürümünü daima http://httpd.apache.org/docs/2.0/ adresinde + bulabilirsiniz.
+Artık Apache HTTP sunucunuzu baÅlatmaya + hazırsınız. Hemen Åu komutu verin:
+ +$ ÃNEK/bin/apachectl start
http://localhost/
üzerinden ilk belgeniz için bir istek
+ yapmalısınız. Genellikle DocumentRoot
olarak bilinen
+ ÃNEK/htdocs/
altındaki sayfayı görürsünüz.
+ ÃalıÅmakta olan sunucuyu durdurmak için Åu
+ komutu verebilirsiniz:
$ ÃNEK/bin/apachectl stop
Sürüm yükseltme iÅleminin ilk adımı, sitenizi etkileyen deÄiÅiklikleri
+ öÄrenmek için daÄıtım duyurusunu ve kaynak paketindeki
+ CHANGES
dosyasını okumaktır. Ana sürümlerden yükseltme
+ yapıyorsanız (1.3âten 2.0âa veya 2.0âdan 2.2âye gibi), derleme anı ve
+ çalıÅma anı yapılandırmalarındaki ana farklılıklar elle ayarlamalar
+ yapmanızı gerektirecektir. Ayrıca, tüm modüllerin de modül APIâsindeki
+ deÄiÅikliklere uyum saÄlaması için yükseltilmesi gerekecektir.
Aynı ana sürüm içinde yükseltme yapmak (2.0.55âten 2.0.57âye
+ yükseltmek gibi) daha kolaydır. make install
iÅlemi,
+ mevcut yapılandırma ve günlük dosyalarınızın ve belgelerin üzerine
+ yazmayacaktır. Ek olarak, geliÅtiriciler alt sürüm deÄiÅikliklerinde
+ configure
seçenekleri, çalıÅma anı yapılandırması
+ veya modül APIâsinde uyumsuz deÄiÅiklikler yapmamaya özen
+ göstereceklerdir. ÃoÄu durumda, aynı configure
komut
+ satırını, aynı yapılandırma dosyasını kullanabileceksiniz ve tüm
+ modülleriniz de çalıÅmaya devam edebilecektir. (Bu sadece 2.0.41 sürümünden sonrası için geçerlidir; daha önceki sürümler için uyumluluk söz konusu deÄildir.)
Aynı ana sürüm içinde yükseltme iÅlemine, eski kaynak aÄacının kök
+ dizininde veya kurulu sunucunuzun build
dizininde
+ bulacaÄınız config.nice
dosyasını yeni kaynak aÄacının kök
+ dizinine kopyalamak suretiyle baÅlayabilirsiniz. Bu dosya evvelce
+ kaynak aÄacını yapılandırmakta kullandıÄınız
+ configure
komut satırını içerir.
+ config.nice
dosyasında yapmak istediÄiniz deÄiÅiklikler
+ varsa yaptıktan sonra Åu komutları veriniz:
+ $ ./config.nice
+ $ make
+ $ make install
+ $ ÃNEK/bin/apachectl graceful-stop
+ $ ÃNEK/bin/apachectl start
+
--prefix
ile kurabilir ve farklı bir port ile
+ (Listen
yönergesini
+ ayarlamak suretiyle) çalıÅtırabilirsiniz.Unter Windows läuft der Apache üblicherweise als Dienst @@ -149,7 +150,8 @@ es | ja | ko | - ru
+ ru | + tr diff --git a/docs/manual/invoking.html.en b/docs/manual/invoking.html.en index 5b51fb5dedb..a634444222e 100644 --- a/docs/manual/invoking.html.en +++ b/docs/manual/invoking.html.en @@ -23,7 +23,8 @@ es | ja | ko | - ru + ru | + trOn Windows, Apache is normally run as a service on Windows @@ -144,7 +145,8 @@ es | ja | ko | - ru
+ ru | + tr diff --git a/docs/manual/invoking.html.es b/docs/manual/invoking.html.es index 4f911b07753..3c9b1f7c634 100644 --- a/docs/manual/invoking.html.es +++ b/docs/manual/invoking.html.es @@ -23,7 +23,8 @@ es | ja | ko | - ru + ru | + trEn Windows, Apache se ejecuta normalmente como un servicio en @@ -161,7 +162,8 @@ es | ja | ko | - ru
+ ru | + tr diff --git a/docs/manual/invoking.html.ja.utf8 b/docs/manual/invoking.html.ja.utf8 index 946052022a0..7511bd58fb6 100644 --- a/docs/manual/invoking.html.ja.utf8 +++ b/docs/manual/invoking.html.ja.utf8 @@ -23,7 +23,8 @@ es | ja | ko | - ru + ru | + trîÁ Windows ÐÌÁÔÆÏÒÍÁÈ Apache ÏÂÙÞÎÏ ÒÁÂÏÔÁÅÔ ËÁË ÓÅÒ×ÉÓ Windows NT/2000/XP @@ -136,7 +137,8 @@ es | ja | ko | - ru
+ ru | + tr diff --git a/docs/manual/invoking.html.tr.utf8 b/docs/manual/invoking.html.tr.utf8 index 9fc8c6fe029..0fbdabfe56c 100644 --- a/docs/manual/invoking.html.tr.utf8 +++ b/docs/manual/invoking.html.tr.utf8 @@ -1,149 +1,149 @@ - - - -Apache HTTP Sunucusu Sürüm 2.0
-Apache normal olarak, Windows NT, 2000 ve XP'de bir hizmet olarak, - Windows 9x ve MEâde ise bir konsol uygulaması olarak çalıÅır. Ayrıntılı - bilgi için Apache HTTPdânin bir - hizmet olarak çalıÅtırılması ve Apache HTTPdânin bir konsol - uygulaması olarak çalıÅtırılması bölümlerine bakınız.
- -Unixâte ise artalanda isteklere yanıt vermek için sürekli çalıÅan bir
- artalan sürecidir. Bu belgede httpd
ânin nasıl
- çalıÅtırılacaÄı açıklanmaktadır.
Yapılandırma dosyasında Listen
yönergesi ile öntanımlı olan port
- 80 (veya 1024âten küçük herhangi bir port) belirtilmiÅse Apache HTTP
- Sunucusunu baÅlatmak için root yetkileri gerekecektir. Sunucu baÅlatılıp
- günlük dosyalarını açmak gibi bazı ön hazırlık etkinliklerinde
- bulunduktan sonra istemcilerden gelen istekleri dinlemek ve yanıt vermek
- için çeÅitli çocuk süreçler baÅlatır. Ana
- httpd
süreci root kullanıcısının aidiyetinde
- çalıÅmasını sürdürürken çocuk süreçler daha az yetkili bir kullanıcının
- aidiyetinde çalıÅır. Bu iÅlem seçilen Ãok Süreçlilik
- Modülü tarafından denetlenir.
httpd
âyi çalıÅtırmak için önerilen yöntem
- apachectl
betiÄini kullanmaktır. Bu betik,
- httpd
ânin bazı iÅletim sistemlerinde iÅlevini
- gerektiÄi gibi yerine getirebilmesi için gereken belli ortam
- deÄiÅkenlerini ayarlar ve httpd
âyi çalıÅtırır.
- apachectl
, komut satırı argümanlarını
- httpd
âye aktarabildiÄinden gerekli
- httpd
seçenekleri apachectl
- betiÄine komut satırı seçenekleri olarak belirtilebilir. Ayrıca,
- apachectl
betiÄinin içeriÄini doÄrudan düzenlemek
- suretiyle betiÄin baÅlangıç satırlarındaki HTTPD
- deÄiÅkenine httpd
çalıÅtırılabilir dosyasının doÄru
- yerini ve daima mevcut olmasını istediÄiniz komut satırı
- seçeneklerini belirtebilirsiniz.
httpd
çalıÅtırıldıÄında yaptıÄı ilk Åey yapılandırma dosyası
- httpd.conf
âu bulup okumaktır. Bu dosyanın yeri derleme
- sırasında belirtilmekteyse de -f
komut satırı seçeneÄi
- kullanılarak çalıÅtırma sırasında belirtmek de mümkündür:
/usr/local/apache2/bin/apachectl -f
- /usr/local/apache2/conf/httpd.conf
BaÅlatma sırasında herÅey yolunda giderse sunucu kendini uçbirimden
- ayıracak ve hemen ardından uçbirim, komut istemine düÅecektir. Bu,
- sunucunun etkin ve çalıÅmakta olduÄunu gösterir. Artık tarayıcınızı
- kullanarak sunucuya baÄlanabilir, DocumentRoot
dizinindeki deneme sayfasını
- görebilir ve bu sayfadan bir baÄla bu belgelerin makinenizdeki kopyasına
- eriÅebilirsiniz.
Apache baÅlatma sırasında ölümcül bir sorunla karÅılaÅacak olursa
- çıkmadan önce sorunu açıklayan bir iletiyi konsola veya ErrorLog
yönergesi ile belirtilen hata
- günlüÄüne yazacaktır. En çok karÅılaÅılan hata iletilerinden biri
- "Unable to bind to Port ...
" dizgesidir. Bu iletiye
- genellikle Åu iki durumdan biri sebep olur:
Bu ve diÄer sorun çözme talimatları için Apache SSSâsini inceleyiniz.
-Sunucunuzun sistem yeniden baÅlatıldıktan sonra çalıÅmasına devam
- etmesini istiyorsanız sistem baÅlatma betiklerinize (genellikle ya
- rc.local
dosyasıdır ya da bir rc.N
dizininde
- bir dosyadır) apachectl
betiÄi için bir çaÄrı
- eklemelisiniz. Bu, Apache sunucunuzu root yetkileriyle baÅlatacaktır.
- Bunu yapmadan önce sunucunuzun güvenlik ve eriÅim kısıtlamaları
- bakımından gerektiÄi gibi yapılandırıldıÄından emin olunuz.
apachectl
betiÄi, bir standart SysV init betiÄi gibi
- davranacak Åekilde tasarlanmıÅtır. start
,
- restart
ve stop
argümanlarını kabul edebilir
- ve bunları httpd
âye uygun sinyallere dönüÅtürebilir.
- Bu bakımdan, çoÄunlukla uygun init dizinlerinden birine
- apachectl
betiÄi için basitçe bir baÄ
- yerleÅtirebilirsiniz. Fakat bunu yapmadan önce betiÄin sisteminizin
- gereklerini yerine getirdiÄinden emin olunuz.
httpd
, apachectl
ve sunucuyla
- gelen diÄer destek programlarının komut satırı seçenekleri hakkında ek
- bilgi Sunucu ve Destek Programları sayfasında
- bulunabilir. Ayrıca, Apache daÄıtımında bulunan tüm modüller ve bunlarla saÄlanan yönergeler hakkında da belgeler
- vardır.
Apache HTTP Sunucusu Sürüm 2.0
+Apache normal olarak, Windows NT, 2000 ve XP'de bir hizmet olarak, + Windows 9x ve MEâde ise bir konsol uygulaması olarak çalıÅır. Ayrıntılı + bilgi için Apache HTTPdânin bir + hizmet olarak çalıÅtırılması ve Apache HTTPdânin bir konsol + uygulaması olarak çalıÅtırılması bölümlerine bakınız.
+ +Unixâte ise artalanda isteklere yanıt vermek için sürekli çalıÅan bir
+ artalan sürecidir. Bu belgede httpd
ânin nasıl
+ çalıÅtırılacaÄı açıklanmaktadır.
Yapılandırma dosyasında Listen
yönergesi ile öntanımlı olan port
+ 80 (veya 1024âten küçük herhangi bir port) belirtilmiÅse Apache HTTP
+ Sunucusunu baÅlatmak için root yetkileri gerekecektir. Sunucu baÅlatılıp
+ günlük dosyalarını açmak gibi bazı ön hazırlık etkinliklerinde
+ bulunduktan sonra istemcilerden gelen istekleri dinlemek ve yanıt vermek
+ için çeÅitli çocuk süreçler baÅlatır. Ana
+ httpd
süreci root kullanıcısının aidiyetinde
+ çalıÅmasını sürdürürken çocuk süreçler daha az yetkili bir kullanıcının
+ aidiyetinde çalıÅır. Bu iÅlem seçilen Ãok Süreçlilik
+ Modülü tarafından denetlenir.
httpd
âyi çalıÅtırmak için önerilen yöntem
+ apachectl
betiÄini kullanmaktır. Bu betik,
+ httpd
ânin bazı iÅletim sistemlerinde iÅlevini
+ gerektiÄi gibi yerine getirebilmesi için gereken belli ortam
+ deÄiÅkenlerini ayarlar ve httpd
âyi çalıÅtırır.
+ apachectl
, komut satırı argümanlarını
+ httpd
âye aktarabildiÄinden gerekli
+ httpd
seçenekleri apachectl
+ betiÄine komut satırı seçenekleri olarak belirtilebilir. Ayrıca,
+ apachectl
betiÄinin içeriÄini doÄrudan düzenlemek
+ suretiyle betiÄin baÅlangıç satırlarındaki HTTPD
+ deÄiÅkenine httpd
çalıÅtırılabilir dosyasının doÄru
+ yerini ve daima mevcut olmasını istediÄiniz komut satırı
+ seçeneklerini belirtebilirsiniz.
httpd
çalıÅtırıldıÄında yaptıÄı ilk Åey yapılandırma dosyası
+ httpd.conf
âu bulup okumaktır. Bu dosyanın yeri derleme
+ sırasında belirtilmekteyse de -f
komut satırı seçeneÄi
+ kullanılarak çalıÅtırma sırasında belirtmek de mümkündür:
/usr/local/apache2/bin/apachectl -f
+ /usr/local/apache2/conf/httpd.conf
BaÅlatma sırasında herÅey yolunda giderse sunucu kendini uçbirimden
+ ayıracak ve hemen ardından uçbirim, komut istemine düÅecektir. Bu,
+ sunucunun etkin ve çalıÅmakta olduÄunu gösterir. Artık tarayıcınızı
+ kullanarak sunucuya baÄlanabilir, DocumentRoot
dizinindeki deneme sayfasını
+ görebilir ve bu sayfadan bir baÄla bu belgelerin makinenizdeki kopyasına
+ eriÅebilirsiniz.
Apache baÅlatma sırasında ölümcül bir sorunla karÅılaÅacak olursa
+ çıkmadan önce sorunu açıklayan bir iletiyi konsola veya ErrorLog
yönergesi ile belirtilen hata
+ günlüÄüne yazacaktır. En çok karÅılaÅılan hata iletilerinden biri
+ "Unable to bind to Port ...
" dizgesidir. Bu iletiye
+ genellikle Åu iki durumdan biri sebep olur:
Bu ve diÄer sorun çözme talimatları için Apache SSSâsini inceleyiniz.
+Sunucunuzun sistem yeniden baÅlatıldıktan sonra çalıÅmasına devam
+ etmesini istiyorsanız sistem baÅlatma betiklerinize (genellikle ya
+ rc.local
dosyasıdır ya da bir rc.N
dizininde
+ bir dosyadır) apachectl
betiÄi için bir çaÄrı
+ eklemelisiniz. Bu, Apache sunucunuzu root yetkileriyle baÅlatacaktır.
+ Bunu yapmadan önce sunucunuzun güvenlik ve eriÅim kısıtlamaları
+ bakımından gerektiÄi gibi yapılandırıldıÄından emin olunuz.
apachectl
betiÄi, bir standart SysV init betiÄi gibi
+ davranacak Åekilde tasarlanmıÅtır. start
,
+ restart
ve stop
argümanlarını kabul edebilir
+ ve bunları httpd
âye uygun sinyallere dönüÅtürebilir.
+ Bu bakımdan, çoÄunlukla uygun init dizinlerinden birine
+ apachectl
betiÄi için basitçe bir baÄ
+ yerleÅtirebilirsiniz. Fakat bunu yapmadan önce betiÄin sisteminizin
+ gereklerini yerine getirdiÄinden emin olunuz.
httpd
, apachectl
ve sunucuyla
+ gelen diÄer destek programlarının komut satırı seçenekleri hakkında ek
+ bilgi Sunucu ve Destek Programları sayfasında
+ bulunabilir. Ayrıca, Apache daÄıtımında bulunan tüm modüller ve bunlarla saÄlanan yönergeler hakkında da belgeler
+ vardır.
Verfügbare Sprachen: de | en | es | - ja
+ ja | + trBeschreibung: | Eine Sammlung von Direktiven, die in mehr als einem Multi-Processing-Modul (MPM) implementiert sind. |
---|
Description: | A collection of directives that are implemented by more than one multi-processing module (MPM) |
---|
Açıklama: | Birden fazla Ãok Süreçlilik Modülü (MPM) tarafından gerçeklenmiÅ - yönergeler bütünü. |
---|---|
Durum: | MPM |
Açıklama: | Apache HTTPd Sunucusunun aÄ soketlerinden istekleri kabul eden - çok sayıda çocuk süreci sıraya sokmak için kullandıÄı yöntemi - belirler. |
---|---|
Sözdizimi: | AcceptMutex Default|yöntem |
Ãntanımlı: | AcceptMutex Default |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | leader , perchild , prefork , threadpool , worker |
AcceptMutex
yönergesi Apache HTTPd Sunucusunun
- aÄ soketlerinden istekleri kabul eden çok sayıda çocuk süreci sıraya
- sokmak için kullandıÄı yöntemi
- belirler. Apache 2.0âdan önce, yöntem sadece derleme sırasında
- seçilebiliyordu. Kullanılacak en uygun yöntem mimariye ve platforma aÅırı
- derecede baÄımlıdır. Bu konuda daha ayrıntılı bilgi edinmek için BaÅarım Arttırma İpuçları belgesine
- bakabilirsiniz.
Bu yönergeye deÄer olarak Default
belirtilmiÅse derleme
- sırasında seçilen öntanımlı yöntem kullanılacaktır. DiÄer olası yöntemler
- aÅaÄıda listelenmiÅtir. Tüm yöntemlerin tüm platformlarda mevcut
- olmadıÄına dikkat ediniz. EÄer belirtilen yöntem mevcut deÄilse hata
- günlüÄüne mevcut yöntemlerin listesini içeren bir ileti yazılacaktır.
flock
LockFile
yönergesi ile
- belirtilen dosyayı kilitlemek için flock(2)
sistem
- çaÄrısı kullanılır.fcntl
LockFile
yönergesi ile
- belirtilen dosyayı kilitlemek için fcntl(2)
sistem
- çaÄrısı kullanılır.posixsem
pthread
sysvsem
Sisteminiz için derleme sırasında seçilmiŠöntanımlı yöntemi öÄrenmek
- isterseniz LogLevel
yönergesine
- debug
deÄerini atayabilirsiniz. Ãntanımlı AcceptMutex
, ErrorLog
- ile belirtilen günlük dosyasına yazılacaktır.
Açıklama: | BS2000 makinelerde yetkisiz hesap tanımlar. |
---|---|
Sözdizimi: | BS2000Account account |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | perchild , prefork |
Uyumluluk: | Sadece BS2000 makineler içindir. |
BS2000Account
yönergesi sadece BS2000
- konaklar için kullanılabilir. User
yönergesi ile belirtilen yetkisiz apache sunucu
- kullanıcısı için hesap numarası tanımlamakta kullanılmalıdır. Buna,
- CGI betiklerinin sunucu tarafından baÅlatılmıŠyetkili hesabın
- (normal olarak SYSROOT
âun) özkaynaklarına eriÅmesini
- engellemek için BS2000 POSIX alt sistemleri tarafından gerek duyulur.
Sadece bir BS2000Account
yönergesi kullanılabilir.
Açıklama: | core dosyasını dökümlemek üzere Apacheânin geçmeye
- çalıÅacaÄı dizin. |
---|---|
Sözdizimi: | CoreDumpDirectory dizin |
Ãntanımlı: | Ãntanımlı deÄer için aÅaÄıdaki açıklamaya bakınız |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | beos , leader , mpm_winnt , perchild , prefork , threadpool , worker |
Bu yönerge core
dosyasını dökümlemek üzere Apacheânin
- geçmeye çalıÅacaÄı dizini belirler. ServerRoot
dizini öntanımlı dizin olmakla
- birlikte, bu dizin kullanıcılar tarafından yazılabilir bir dizin
- olmadıÄından bir core
dosyası dökümlenmez. Hata ayıklama
- amacıyla bir core
dosyası dökümlemek isterseniz farklı bir
- yer belirtmek için bu yönergeyi kullanabilirsiniz.
core
dökümlemekApache root olarak baÅlatılıp baÅka bir kullanıcıya geçilirse Linux
- çekirdeÄi süreç tarafından yazılabilir olsa bile core
- dökümlemeyi iptal eder. EÄer
- CoreDumpDirectory
yönergesi ile açıkça bir
- dizin belirtirseniz, Apache (2.0.46 ve sonraki sürümleri), Linux 2.4 ve
- sonrasında core
dökümlemeyi yeniden
- etkinleÅtirecektir.
Açıklama: | Bir çöküŠsonrası olaÄandıÅılık eylemcilerini çalıÅtıracak - kancayı etkin kılar. |
---|---|
Sözdizimi: | EnableExceptionHook On|Off |
Ãntanımlı: | EnableExceptionHook Off |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | leader , perchild , prefork , threadpool , worker |
Uyumluluk: | Sürüm 2.0.49 ve sonrasında mevcuttur |
Güvenlik sebebiyle bu yönerge sadece Apache
- --enable-exception-hook
seçeneÄi ile yapılandırılmıÅsa
- kullanılabilir olacaktır. Bu, harici modüllerin eklenmesine ve bir çocuk
- sürecin çöküÅü sonrası bir Åeyler yapmaya izin veren bir kancayı etkin
- kılar.
Bu kancayı kullanan iki modül (mod_whatkilledus
ve
- mod_backtrace
) zaten vardır. bunlar hakkında daha fazla bilgi
- edinmek için Jeff Trawick'in EnableExceptionHook sitesine bakabilirsiniz.
Açıklama: | İsteklere yanıt verecek sunucunun ait olacaÄı grubu belirler. |
---|---|
Sözdizimi: | Group unix-grubu |
Ãntanımlı: | Group #-1 |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | beos , leader , mpmt_os2 , perchild , prefork , threadpool , worker |
Uyumluluk: | Apache 2.0âdan itibaren sadece sunucu geneli için geçerlidir. |
Group
yönergesi, sunucunun hangi grup altında
- isteklere yanıt vereceÄini belirler. Bu yönergenin uygulanabilmesi için
- sunucunun root
olarak çalıÅtırılmıŠolması gerekir.
- Sunucuyu root
dıÅında bir kullanıcı baÅlattıÄı takdirde,
- sunucu belirtilen gruba geçemez ve kullanıcının kendi grubunda
- çalıÅmaya devam eder. unix-grubu Åunlardan biri olabilir:
#
ardından grup numarası
- Group www-group
-
ÃalıÅan sunucu için özellikle yeni bir grup atamanız önerilir. Bazı
- sistem yöneticileri nobody
grubunu kullanırlar fakat
- bu her zaman mümkün olmadıÄı gibi arzulanan da deÄildir.
Ne yaptıÄınızı ve ne tehlikelere yol açacaÄınızı bilmiyorsanız
- Group
(veya User
) yönergesine deÄer olarak
- root
atamayınız.
Ãzel bilgi: Bu yönergenin <VirtualHost>
taÅıyıcısı içinde kullanımı
- artık desteklenmemektedir. Sunucunuzu suexec
için
- yapılandırırken SuexecUserGroup
yönergesini
- kullanınız.
Açıklama: | Sunucunun dinleyeceÄi IP adresini ve portu belirler. |
---|---|
Sözdizimi: | Listen [IP-adresi:]port-numarası |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | beos , leader , mpm_netware , mpm_winnt , mpmt_os2 , perchild , prefork , threadpool , worker , event |
Uyumluluk: | Apache 2.0âdan beri gerekli yönergelerden - biridir. |
Listen
yönergesi Apacheâyi sadece belli IP
- adreslerini ve portlarını dinlemeye sevkeder.
- Listen
artık belirtilmesi zorunlu yönergelerden
- biridir. Yapılandırma dosyasında bulunmadıÄı takdirde sunucu
- baÅlatılırken baÅarısız olacaktır. Bu Apache Sunucusunun önceki
- sürümünde böyle deÄildi.
Listen
yönergesi Apacheâye, sadece belli
- portlardan veya IP adresi ve port çiftlerinden gelen istekleri kabul
- etmesini söyler. EÄer sadece port numarası belirtilmiÅse sunucu
- belirtilen portu bütün aÄ arabirimlerinde dinleyecektir. EÄer portla
- birlikte bir IP adresi de belirtilmiÅse, sunucu belirtilen portu sadece
- belirtilen arabirimden dinleyecektir.
Ãok sayıda IP adresi ve port belirtmek için çok sayıda
- Listen
yönergesi kullanılabilir. Sunucu bu
- durumda belirtilen bütün IP adreslerinden ve portlardan gelecek
- isteklere yanıt verecektir.
ÃrneÄin sunucunun hem port 80 hem de port 8000âden istek kabul etmesini - istiyorsanız bunu Åöyle belirtebilirsiniz:
- -
- Listen 80
- Listen 8000
-
Sunucunun belirtilen iki aÄ arabiriminden ve port numarasından gelen - baÄlantıları kabul etmesi için Åu yapılandırmayı kullanabilirsiniz:
- -
- Listen 192.170.2.1:80
- Listen 192.170.2.5:8000
-
IPv6 adresleri belirtilirken örnekteki gibi köÅeli ayraçlar arasına - alınmalıdır:
- -
- Listen [2001:db8::a00:20ff:fea7:ccea]:80
-
Listen
- yönergesinde belirtilmesi bir "adres kullanımda" (Address already
- in use
) hatasına yol açar.
- Açıklama: | Bekleyen baÄlantılar kuyruÄunun azami uzunluÄunu - belirler |
---|---|
Sözdizimi: | ListenBacklog kuyruk-uzunluÄu |
Ãntanımlı: | ListenBacklog 511 |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | beos , leader , mpm_netware , mpm_winnt , mpmt_os2 , perchild , prefork , threadpool , worker |
Bekleyen baÄlantılar kuyruÄunun azami uzunluÄu. Genellikle bu ayar ne
- gerekir ne de istenir. Ancak bazı sistemlerde TCP SYN yüklenme
- saldırılarına karÅı bu deÄerin arttırılması gerekebilir.
- kuyruk-uzunluÄu parametresi için listen(2)
- iÅlevinin açıklamasına bakınız.
Bu deÄer çoÄunlukla iÅletim sistemi tarafından daha küçük bir sayıyla - sınırlanır. Bu, iÅletim sistemine baÄlı olarak deÄiÅiklik gösterir. - Ayrıca, çoÄu iÅletim sisteminin kuyruk-uzunluÄu parametresi - ile ne belirttiÄinize bakmaksızın kendisi için atanmıŠdeÄeri (fakat - normal olarak daha büyüÄünü) kullanacaÄına dikkat ediniz.
- -Açıklama: | Apache HTTPd Sunucusunun aÄ soketlerinden istekleri kabul eden - çok sayıda çocuk süreci sıraya sokarken kullandıÄı kilit dosyasının yerini - belirler. |
---|---|
Sözdizimi: | LockFile dosya |
Ãntanımlı: | LockFile logs/accept.lock |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | leader , perchild , prefork , threadpool , worker |
LockFile
yönergesi, AcceptMutex
yönergesi fcntl
- veya flock
deÄeri ile belirtildiÄi takdirde kullanılan
- kilit dosyasının yerini belirler. Bu yönerge normalde öntanımlı
- deÄeriyle bırakılır. DeÄiÅmesini gerektiren ana sebep, logs
- dizininin aÄ dosya sisteminde (NFS) yeralması halinde kilit
- dosyasının bir yerel diskte saklanması gereÄidir. Ana sürecin
- süreç kimliÄi dosyaya kendiliÄinden eklenir.
Bu dosyayı herkesin yazabildiÄi /var/tmp
gibi bir dizine
- koymaktan kaçınmak gerekir. Ãünkü, bu takdirde, birileri sunucunun
- hizmet sunmaya baÅlarken oluÅturacaÄı kilit dosyası ile aynı isimde
- bir dosya oluÅturarak hizmet reddi saldırısı (DoS) baÅlatabilir.
AcceptMutex
Açıklama: | İstekleri sunarken oluÅturulacak çocuk süreçlerin azami sayısını - belirler. |
---|---|
Sözdizimi: | MaxClients sayı |
Ãntanımlı: | Ayrıntılar için aÅaÄıdaki açıklamaya bakınız. |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | beos , leader , prefork , threadpool , worker |
MaxClients
yönergesi aynı anda sunulacak istek
- sayısını sınırlamak için kullanılır. MaxClients
- istekten fazlası geldiÄi takdirde bu istekler normal olarak kuyruÄa
- alınıp bekletilir. Kuyrukta bekletilecek isteklerin azami sayısı ise
- ListenBacklog
yönergesi ile
- belirlenir. İstek sunmakta olan çocuk süreçlerden biri serbest
- kaldıÄında bekletilen baÄlantılardan birine hizmet sunulmaya
- baÅlanır.
Evreli olmayan sunucularda (prefork
gibi)
- MaxClients
yönergesi istekleri sunmak için
- baÅlatılacak çocuk süreçlerin azami sayısını belirler. Ãntanımlı deÄer
- 256 olup bu deÄeri arttırmak isterseniz ServerLimit
deÄerini de
- arttırmalısınız.
Ãok evreli ve melez sunucularda (beos
veya
- worker
gibi) MaxClients
- yönergesi istemcilere hizmet verecek evre sayısını sınırlar. Ãntanımlı
- deÄer beos
için 50
iken melez MPMâler için
- ServerLimit
ile ThreadsPerChild
çarpımıdır (16 x
- 25
). Bu bakımdan MaxClients
deÄerini 16
- süreçten fazlasına ayarlamak için ServerLimit
deÄerini de
- arttırmalısınız.
Açıklama: | free() çaÄrılmaksızın ana bellek ayırıcının
- ayırmasına izin verilen azami bellek miktarını belirler. |
---|---|
Sözdizimi: | MaxMemFree kB-sayısı |
Ãntanımlı: | MaxMemFree 0 |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | beos , leader , mpm_netware , prefork , threadpool , worker , mpm_winnt |
MaxMemFree
yönergesi, free()
- çaÄrılmaksızın ana bellek ayırıcının ayırmasına izin verilen azami
- bellek miktarını kB cinsinden belirler. Bir deÄerle belirtilmediÄinde
- veya 0
deÄeriyle belirtildiÄinde eÅik sınırsız
- olacaktır.
Açıklama: | Tek bir çocuk sürecin ömrü boyunca iÅleme sokabileceÄi istek - sayısını sınırlamakta kullanılır. |
---|---|
Sözdizimi: | MaxRequestsPerChild sayı |
Ãntanımlı: | MaxRequestsPerChild 10000 |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | leader , mpm_netware , mpm_winnt , mpmt_os2 , perchild , prefork , threadpool , worker |
MaxRequestsPerChild
yönergesi, tek bir çocuk
- sürecin iÅleme sokabileceÄi istek sayısını sınırlamakta kullanılır.
- MaxRequestsPerChild
istekten sonra çocuk süreç
- ölür. EÄer MaxRequestsPerChild
için
- 0
belirtilmiÅse sürecin ömrü sonsuz olacaktır.
mpm_netware
ve mpm_winnt
için
- öntanımlı deÄer 0
âdır.
MaxRequestsPerChild
için sıfırdan farklı bir
- deÄer belirtmenin iki yararlı etkisi vardır:
KeepAlive
isteklerinde sadece
- ilk istek bu sınıra uygun sayılır. Etkisi ise, davranıÅın çocuk süreç
- baÅına baÄlantı sayısının sınırlanması Åeklinde
- deÄiÅmesidir.
Açıklama: | BoÅtaki azami evre sayısını belirler |
---|---|
Sözdizimi: | MaxSpareThreads number |
Ãntanımlı: | Ayrıntılar için aÅaÄıdaki açıklamaya bakınız. |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | beos , leader , mpm_netware , mpmt_os2 , perchild , threadpool , worker |
BoÅtaki azami evre sayısı. Her MPM bu yönerge karÅısında farklı - davranır.
- -perchild
için MaxSpareThreads 10
- öntanımlıdır. Bu MPM, boÅtaki evrelerin sayısını çocuk süreç baÅına
- boÅtaki evre sayısı olarak izler. Bir çocukta çok fazla boÅta evre
- varsa sunucu sadece o çocuÄun boÅtaki evrelerini öldürür.
worker
, leader
ve
- threadpool
için MaxSpareThreads 250
- öntanımlıdır. Bu MPMâler boÅtaki evreleri sunucu genelinde izler. EÄer
- sunucuda çok fazla boÅta evre varsa, sunucu boÅtaki evrelerin sayısı bu
- sınırın altına inene kadar çocuk süreçleri öldürür.
mpm_netware
için MaxSpareThreads 100
- öntanımlıdır. Bu MPM tek bir süreç olarak çalıÅtıÄından boÅtaki evre
- sayısı aynı zamanda sunucu genelinde boÅtaki evre sayısıdır.
beos
ve mpmt_os2
MPMâleri
- mpm_netware
gibidir. beos
için
- MaxSpareThreads 50
öntanımlıyken mpmt_os2
- için öntanımlı deÄer 10
âdur.
MaxSpareThreads
için deÄer aralıÄı sınırlıdır.
- Apache belirtilen deÄeri aÅaÄıdaki kurallara uygun olarak
- kendiliÄinden düzeltecektir:
perchild
için
- MaxSpareThreads
deÄerinin ThreadLimit
deÄerinden küçük veya
- eÅit olması gerekir.mpm_netware
modülü, deÄerin MinSpareThreads
deÄerinden küçük
- olmasını gerektirir.leader
, threadpool
ve
- worker
için deÄer, MinSpareThreads
- ve ThreadsPerChild
- toplamına eÅit veya büyük olmak zorundadır.Açıklama: | İsteklerin ani artıÅında devreye girecek boÅtaki evrelerin asgari - sayısını belirler. |
---|---|
Sözdizimi: | MinSpareThreads number |
Ãntanımlı: | Ayrıntılar için aÅaÄıdaki açıklamaya bakınız. |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | beos , leader , mpm_netware , mpmt_os2 , perchild , threadpool , worker |
İsteklerin ani artıÅında devreye girecek boÅtaki evrelerin asgari - sayısı. Her MPM bu yönerge karÅısında farklı davranır.
- -perchild
için MinSpareThreads 5
- öntanımlıdır ve çocuk süreç baÅına boÅtaki evre sayısını izler. Bir
- çocuk için yeterince boÅta evre yoksa sunucu bu çocuk için yeni evreler
- oluÅturmaya baÅlar. Nitekim, NumServers
için 10
ve
- MinSpareThreads
için 5
atarsanız
- sisteminizdeki boÅtaki evre sayısı en az 50 olur.
worker
, leader
ve
- threadpool
modülleri için MinSpareThreads
- 75
öntanımlıdır ve bu modüller boÅtaki evreleri sunucu genelinde
- izler. EÄer sunucuda boÅtaki evre sayısı yetersizse, sunucu boÅtaki
- evrelerin sayısı bu sınırın üstüne çıkana kadar çocuk süreç
- oluÅturur.
mpm_netware
için MinSpareThreads 10
- öntanımlıdır ve tek süreç kendisi olduÄundan izleme sunucu genelinde
- yapılır.
beos
ve mpmt_os2
modülleri
- mpm_netware
gibidir. beos
için
- MinSpareThreads 1
öntanımlı iken mpmt_os2
- için öntanımlı deÄer 5
âtir.
Açıklama: | Ana sürecin süreç kimliÄinin (PID) kaydedileceÄi dosyayı belirler. |
---|---|
Sözdizimi: | PidFile dosya |
Ãntanımlı: | PidFile logs/httpd.pid |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | beos , leader , mpm_winnt , mpmt_os2 , perchild , prefork , threadpool , worker |
PidFile
yönergesi, sunucunun artalan sürecinin
- süreç kimliÄinin kaydedileceÄi dosyayı belirler. Dosya ismi mutlak dosya
- yoluyla belirtilmemiÅse dosya yolunun ServerRoot
dizinine göre belirtildiÄi kabul
- edilir.
- PidFile /var/run/apache.pid
-
Sunucuya sinyal gönderebilmek çoÄunlukla iÅe yarar. Böylece ErrorLog
ve TransferLog
dosyaları kapatılıp
- yeniden açılır ve yapılandırma dosyaları yeniden okunur. Bu,
- PidFile
dosyasında belirtilen süreç kimliÄine bir
- SIGHUP (kill -1) sinyali gönderilerek yapılır.
Günlük dosyasının yeri ve güvenlik ile ilgili
- uyarılar PidFile
dosyası içinde sözkonusu
- olabilir.
Apache 2âde sunucuyu (yeniden) baÅlatırken veya durdururken sadece
- apachectl
betiÄini kullanmanız önerilir.
Açıklama: | TCP alım tamponu boyu |
---|---|
Sözdizimi: | ReceiveBufferSize bayt-sayısı |
Ãntanımlı: | ReceiveBufferSize 0 |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | beos , leader , mpm_netware , mpm_winnt , mpmt_os2 , perchild , prefork , threadpool , worker |
Sunucu TCP alım tamponu boyunu bayt-sayısı ile belirtilen - bayta ayarlayacaktır.
- -0
deÄeri atarsanız sunucu iÅletim sistemi öntanımlısını
- kullanacaktır.
Açıklama: | Ãocuk süreçler için eÅgüdüm verisini saklamakta kullanılan - dosyanın yerini belirler. |
---|---|
Sözdizimi: | ScoreBoardFile dosya-yolu |
Ãntanımlı: | ScoreBoardFile logs/apache_status |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | beos , leader , mpm_winnt , perchild , prefork , threadpool , worker |
Apache ana ve çocuk süreçler arasında iletiÅim için bir çetele tutar. - Bazı mimariler bu iletiÅimi kolaylaÅtırmak için bir dosya gerektirir. - EÄer yönerge belirtilmezse Apache çeteleyi önce tamamen bellekte - oluÅturmayı dener (anonim paylaÅımlı bellek kullanarak); bunda baÅarılı - olamazsa dosyayı diskte oluÅturmaya çalıÅacaktır (paylaÅımlı belleÄe - eÅlemli dosya kullanarak). Bu yönergenin belirtilmesi Apache sunucusunun - dosyayı daima diskte oluÅturmasına sebep olur.
- -
- ScoreBoardFile /var/run/apache_status
-
PaylaÅımlı belleÄe eÅlemli dosya, çeteleye doÄrudan eriÅmesi gereken - üçüncü parti uygulamalar için yararlıdır.
- -EÄer ScoreBoardFile
yönergesi ile bir dosya
- belirtecekseniz, dosyayı bir RAM diske yerleÅtirerek hız artıÅı
- saÄlayabilirsiniz. Fakat, günlük dosyası yerleÅtirme ve güvenlik ile ilgili uyarılara
- benzer uyarılara karÅı dikkatli olunuz.
Açıklama: | TCP tamponu boyu |
---|---|
Sözdizimi: | SendBufferSize bayt-sayısı |
Ãntanımlı: | SendBufferSize 0 |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | beos , leader , mpm_netware , mpm_winnt , mpmt_os2 , perchild , prefork , threadpool , worker |
Sunucu TCP gönderim tamponu boyunu bayt-sayısı ile - belirtilen bayta ayarlayacaktır. Yüksek hızlı yüksek yataklık süresi - için standart iÅletim sistemi öntanımlılarını arttırmak çok yararlıdır - (örneÄin, kıtalar arası hızlı borularda olduÄu gibi 100 ms - civarında).
- -0
deÄeri atarsanız sunucu iÅletim sistemi öntanımlısını
- kullanacaktır.
Açıklama: | Ayarlanabilir süreç sayısının üst sınırını belirler. |
---|---|
Sözdizimi: | ServerLimit sayı |
Ãntanımlı: | Ayrıntılar için aÅaÄıdaki açıklamaya bakınız. |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | leader , perchild , prefork , threadpool , worker |
prefork
modülü söz konusu olduÄunda bu yönerge, Apache
- sürecinin ömrü boyunca MaxClients
yönergesine atanabilecek
- azami deÄeri belirler. worker
modülü sözkonusu
- olduÄunda ise, Apache sürecinin ömrü boyunca MaxClients
yönergesine atanabilecek
- azami deÄeri ThreadLimit
ile
- birlikte belirler. Bu yönergeyi bir yeniden baÅlatma sırasında
- deÄiÅtirirseniz bu deÄiÅiklik yok sayılır fakat MaxClients
deÄiÅiklikleri dikkate
- alınır.
Bu yönergenin kullanılması özel bir dikkat gerektirir. EÄer
- ServerLimit
gereÄinden yüksek bir deÄere
- ayarlanırsa, gereksiz yere paylaÅımlı bellek ayrılmıŠolur. EÄer
- ServerLimit
ve MaxClients
deÄerleri sistemin
- iÅleyebileceÄinden daha yüksek deÄerlere ayarlanırsa Apache
- baÅlayamayacaÄı gibi sistemi kararsız hale de getirebilir.
Bu yönergeyi prefork
modülü ile sadece MaxClients
yönergesine 256âdan
- (öntanımlı) daha büyük bir deÄer atayacaksanız kullanınız. Bu yönergeye
- MaxClients
için atamak
- istediÄiniz deÄerden fazlasını atamayınız.
worker
, leader
ve
- threadpool
modülleri söz konusu olduÄunda bu yönergeyi
- MaxClients
ve
- ThreadsPerChild
ayarları 16
- sunucu sürecinden (16 öntanımlıdır) fazlasını gerektiriyorsa
- ayarlayınız. Bu yönergeye MaxClients
-
ve ThreadsPerChild
için gerekli gördüÄünüz
- sunucu süreci sayısından fazlasını atamayınız.
perchild
modülüyle bu yönergeyi eÄer NumServers
yönergesine 8âden (öntanımlı)
- büyük bir deÄer atayacaksanız kullanınız.
Sunucu içinde derlenmiŠolarak ServerLimit 20000
- Åeklinde bir zorlayıcı sınır vardır. Bu önlem, yazım hatalarının
- istenmeyen sonuçlara yol açmasını engellemek için düÅünülmüÅtür.
Açıklama: | Sunucunun baÅlatılması sırasında oluÅturulan çocuk süreçlerin - sayısını belirler. |
---|---|
Sözdizimi: | StartServers sayı |
Ãntanımlı: | Ayrıntılar için aÅaÄıdaki açıklamaya bakınız. |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | leader , mpmt_os2 , prefork , threadpool , worker |
StartServers
yönergesi, sunucunun baÅlatılması
- sırasında oluÅturulan çocuk süreçlerin sayısını belirler. Süreç sayısı
- normal olarak yüke baÄlı olarak deÄiÅse de bu deÄerin ayarlanmasını
- gerektirecek küçük bir sebep vardır.
Ãntanımlı deÄer MPMâden MPMâe fark eder. Ãntanımlı deÄer
- leader
, threadpool
ve
- worker
için 3
iken
- prefork
için 5
ve
- mpmt_os2
için 2
âdir.
Açıklama: | Sunucunun baÅlatılması sırasında oluÅturulan evrelerin sayısını - belirler. |
---|---|
Sözdizimi: | StartThreads sayı |
Ãntanımlı: | Ayrıntılar için aÅaÄıdaki açıklamaya bakınız. |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | beos , mpm_netware , perchild |
StartThreads
yönergesi, sunucunun baÅlatılması
- sırasında oluÅturulan evrelerin sayısını belirler. Evre sayısı normal
- olarak yüke baÄlı olarak deÄiÅse de bu deÄerin ayarlanmasını
- gerektirecek küçük bir sebep vardır.
perchild
için StartThreads 5
öntanımlı
- olup bu yönerge sunucunun baÅlatılması sırasında oluÅturulan süreç
- baÅına evre sayısıyla baÄlantısını sürdürür.
mpm_netware
için StartThreads 50
- öntanımlı olup, sadece tek bir süreç olduÄundan, sunucunun baÅlatılması
- sırasında oluÅturulan evrelerin toplam sayısı 50
âdir.
beos
için StartThreads 10
öntanımlı olup
- sunucunun baÅlatılması sırasında oluÅturulan evrelerin toplam sayısı
- 10
âdur.
Açıklama: | Ãocuk süreç baÅına ayarlanabilir evre sayısının üst sınırını - belirler. |
---|---|
Sözdizimi: | ThreadLimit sayı |
Ãntanımlı: | Ayrıntılar için aÅaÄıdaki açıklamaya bakınız. |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | leader , mpm_winnt , perchild , threadpool , worker |
Uyumluluk: | mpm_winnt için Apache 2.0.41 ve sonrasında mevcuttur. |
Bu yönerge, Apache sürecinin ömrü boyunca ThreadsPerChild
yönergesine
- atanabilecek azami deÄeri belirler. Bu yönergeyi bir yeniden baÅlatma
- sırasında deÄiÅtirirseniz bu deÄiÅiklik yok sayılır fakat ThreadsPerChild
deÄiÅiklikleri dikkate
- alınır.
Bu yönergenin kullanılması özel bir dikkat gerektirir. EÄer
- ThreadLimit
deÄeri ThreadsPerChild
deÄerinden yüksek bir
- deÄere ayarlanırsa, gereksiz yere paylaÅımlı bellek ayrılmıŠolur. EÄer
- ThreadLimit
ve ThreadsPerChild
deÄerleri sistemin
- iÅleyebileceÄinden daha yüksek deÄerlere ayarlanırsa Apache
- baÅlayamayacaÄı gibi sistemi kararsız hale de getirebilir. Bu yönergeye
- Apache sunucusunun çalıÅması için öngörülmüŠen büyük deÄerden daha
- yükseÄini atamayınız.
ThreadLimit
yönergesinin öntanımlı deÄeri
- mpm_winnt
için 1920
, diÄerleri için
- 64
âtür.
Sunucu içinde derlenmiŠolarak ThreadLimit 20000
- Åeklinde bir zorlayıcı sınır vardır (mpm_winnt
için
- 15000âdir). Bu önlem, yazım hatalarının istenmeyen sonuçlara yol
- açmasını engellemek için düÅünülmüÅtür.
Açıklama: | Her çocuk süreç tarafından oluÅturulan evrelerin sayısını - belirler. |
---|---|
Sözdizimi: | ThreadsPerChild sayı |
Ãntanımlı: | Ayrıntılar için aÅaÄıdaki açıklamaya bakınız. |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | leader , mpm_winnt , threadpool , worker |
Bu yönerge, her çocuk süreç tarafından oluÅturulan evrelerin sayısını
- belirler. Ãocuk süreçler bu evreleri baÅlatıldıklarında oluÅtururlar ve
- bundan daha fazlasını asla oluÅturmazlar. mpm_winnt
- gibi sadece bir çocuk sürecin bulunduÄu bir MPM kullanıyorsanız, bu
- sayı sunucunun tüm yükünü kaldırabilecek kadar büyük olmalıdır.
- worker
gibi çok çocuk süreçli bir MPM kullanıyorsanız,
- toplam evre sayısı sunucunun tüm yükünü kaldırabilecek kadar
- büyük olmalıdır.
ThreadsPerChild
için öntanımlı deÄer
- mpm_winnt
kullanıldıÄında 64
diÄerleri
- için 25
âtir.
Açıklama: | İsteklere yanıt verecek sunucunun ait olacaÄı kullanıcıyı - belirler. |
---|---|
Sözdizimi: | User unix-kullanıcısı |
Ãntanımlı: | User #-1 |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | leader , perchild , prefork , threadpool , worker |
Uyumluluk: | Apache 2.0âdan itibaren sadece sunucu geneli için - geçerlidir. |
User
yönergesi, sunucunun hangi kullanıcı olarak
- isteklere yanıt vereceÄini belirler. Bu yönergenin uygulanabilmesi için
- sunucunun root
olarak çalıÅtırılmıŠolması gerekir.
- Sunucuyu root
dıÅında bir kullanıcı baÅlattıÄı takdirde,
- sunucu belirtilen kullanıcıya geçemez ve mevcut kullanıcıyla çalıÅmaya
- devam eder. EÄer sunucuyu root
olarak baÅlatmıÅsanız ana
- süreç root olarak çalıÅmaya devam edecektir. unix-kullanıcısı
- Åunlardan biri olabilir:
#
ardından kullanıcı numarasıBu yönergede belirtilecek kullanıcının, baÅkaları tarafından üzerinde
- deÄiÅiklik yapılabilecek dosyalardan baÅkasına eriÅemeyen bir kullanıcı
- olmaması gerektiÄi gibi, HTTP isteklerini iÅlemek dıÅında iÅlemler de
- yapabilen bir kullanıcı olmamalıdır.
- ÃalıÅan sunucu için özellikle yeni bir grup atamanız önerilir. Bazı
- sistem yöneticileri nobody
kullanıcısını kullanırlar fakat
- nobody
kullanıcısı sistemde baÅka amaçlarla
- kullanılabildiÄinden bu her zaman mümkün olmadıÄı gibi arzulanan da
- deÄildir.
Ne yaptıÄınızı ve ne tehlikelere yol açacaÄınızı bilmiyorsanız
- User
(veya Group
) yönergesine deÄer olarak
- root
atamayınız.
Sanal konakları farklı kullanıcı kimliklerle çalıÅtırmak üzere
- tasarlanan perchild
modülü kullanıldıÄında <VirtualHost>
bölümlerinde
- AssignUserID
yönergesi ile
- farklı bir kullanıcı kimlik tanımlanmadıÄı takdirde
- User
yönergesi ile ana sunucu için tanımlanan
- kullanıcı kimlik sanal konak için de geçerli olur.
Ãzel bilgi: Bu yönergenin <VirtualHost>
taÅıyıcısı içinde kullanımı
- artık desteklenmemektedir. Sunucunuzu suexec
için
- yapılandırırken SuexecUserGroup
yönergesini
- kullanınız.
Apache HTTP Sunucusu Sürüm 2.0
+Açıklama: | Birden fazla Ãok Süreçlilik Modülü (MPM) tarafından gerçeklenmiÅ + yönergeler bütünü. |
---|---|
Durum: | MPM |
Açıklama: | Apache HTTPd Sunucusunun aÄ soketlerinden istekleri kabul eden + çok sayıda çocuk süreci sıraya sokmak için kullandıÄı yöntemi + belirler. |
---|---|
Sözdizimi: | AcceptMutex Default|yöntem |
Ãntanımlı: | AcceptMutex Default |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | leader , perchild , prefork , threadpool , worker |
AcceptMutex
yönergesi Apache HTTPd Sunucusunun
+ aÄ soketlerinden istekleri kabul eden çok sayıda çocuk süreci sıraya
+ sokmak için kullandıÄı yöntemi
+ belirler. Apache 2.0âdan önce, yöntem sadece derleme sırasında
+ seçilebiliyordu. Kullanılacak en uygun yöntem mimariye ve platforma aÅırı
+ derecede baÄımlıdır. Bu konuda daha ayrıntılı bilgi edinmek için BaÅarım Arttırma İpuçları belgesine
+ bakabilirsiniz.
Bu yönergeye deÄer olarak Default
belirtilmiÅse derleme
+ sırasında seçilen öntanımlı yöntem kullanılacaktır. DiÄer olası yöntemler
+ aÅaÄıda listelenmiÅtir. Tüm yöntemlerin tüm platformlarda mevcut
+ olmadıÄına dikkat ediniz. EÄer belirtilen yöntem mevcut deÄilse hata
+ günlüÄüne mevcut yöntemlerin listesini içeren bir ileti yazılacaktır.
flock
LockFile
yönergesi ile
+ belirtilen dosyayı kilitlemek için flock(2)
sistem
+ çaÄrısı kullanılır.fcntl
LockFile
yönergesi ile
+ belirtilen dosyayı kilitlemek için fcntl(2)
sistem
+ çaÄrısı kullanılır.posixsem
pthread
sysvsem
Sisteminiz için derleme sırasında seçilmiŠöntanımlı yöntemi öÄrenmek
+ isterseniz LogLevel
yönergesine
+ debug
deÄerini atayabilirsiniz. Ãntanımlı AcceptMutex
, ErrorLog
+ ile belirtilen günlük dosyasına yazılacaktır.
Açıklama: | BS2000 makinelerde yetkisiz hesap tanımlar. |
---|---|
Sözdizimi: | BS2000Account account |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | perchild , prefork |
Uyumluluk: | Sadece BS2000 makineler içindir. |
BS2000Account
yönergesi sadece BS2000
+ konaklar için kullanılabilir. User
yönergesi ile belirtilen yetkisiz apache sunucu
+ kullanıcısı için hesap numarası tanımlamakta kullanılmalıdır. Buna,
+ CGI betiklerinin sunucu tarafından baÅlatılmıŠyetkili hesabın
+ (normal olarak SYSROOT
âun) özkaynaklarına eriÅmesini
+ engellemek için BS2000 POSIX alt sistemleri tarafından gerek duyulur.
Sadece bir BS2000Account
yönergesi kullanılabilir.
Açıklama: | core dosyasını dökümlemek üzere Apacheânin geçmeye
+ çalıÅacaÄı dizin. |
---|---|
Sözdizimi: | CoreDumpDirectory dizin |
Ãntanımlı: | Ãntanımlı deÄer için aÅaÄıdaki açıklamaya bakınız |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | beos , leader , mpm_winnt , perchild , prefork , threadpool , worker |
Bu yönerge core
dosyasını dökümlemek üzere Apacheânin
+ geçmeye çalıÅacaÄı dizini belirler. ServerRoot
dizini öntanımlı dizin olmakla
+ birlikte, bu dizin kullanıcılar tarafından yazılabilir bir dizin
+ olmadıÄından bir core
dosyası dökümlenmez. Hata ayıklama
+ amacıyla bir core
dosyası dökümlemek isterseniz farklı bir
+ yer belirtmek için bu yönergeyi kullanabilirsiniz.
core
dökümlemekApache root olarak baÅlatılıp baÅka bir kullanıcıya geçilirse Linux
+ çekirdeÄi süreç tarafından yazılabilir olsa bile core
+ dökümlemeyi iptal eder. EÄer
+ CoreDumpDirectory
yönergesi ile açıkça bir
+ dizin belirtirseniz, Apache (2.0.46 ve sonraki sürümleri), Linux 2.4 ve
+ sonrasında core
dökümlemeyi yeniden
+ etkinleÅtirecektir.
Açıklama: | Bir çöküŠsonrası olaÄandıÅılık eylemcilerini çalıÅtıracak + kancayı etkin kılar. |
---|---|
Sözdizimi: | EnableExceptionHook On|Off |
Ãntanımlı: | EnableExceptionHook Off |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | leader , perchild , prefork , threadpool , worker |
Uyumluluk: | Sürüm 2.0.49 ve sonrasında mevcuttur |
Güvenlik sebebiyle bu yönerge sadece Apache
+ --enable-exception-hook
seçeneÄi ile yapılandırılmıÅsa
+ kullanılabilir olacaktır. Bu, harici modüllerin eklenmesine ve bir çocuk
+ sürecin çöküÅü sonrası bir Åeyler yapmaya izin veren bir kancayı etkin
+ kılar.
Bu kancayı kullanan iki modül (mod_whatkilledus
ve
+ mod_backtrace
) zaten vardır. bunlar hakkında daha fazla bilgi
+ edinmek için Jeff Trawick'in EnableExceptionHook sitesine bakabilirsiniz.
Açıklama: | İsteklere yanıt verecek sunucunun ait olacaÄı grubu belirler. |
---|---|
Sözdizimi: | Group unix-grubu |
Ãntanımlı: | Group #-1 |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | beos , leader , mpmt_os2 , perchild , prefork , threadpool , worker |
Uyumluluk: | Apache 2.0âdan itibaren sadece sunucu geneli için geçerlidir. |
Group
yönergesi, sunucunun hangi grup altında
+ isteklere yanıt vereceÄini belirler. Bu yönergenin uygulanabilmesi için
+ sunucunun root
olarak çalıÅtırılmıŠolması gerekir.
+ Sunucuyu root
dıÅında bir kullanıcı baÅlattıÄı takdirde,
+ sunucu belirtilen gruba geçemez ve kullanıcının kendi grubunda
+ çalıÅmaya devam eder. unix-grubu Åunlardan biri olabilir:
#
ardından grup numarası
+ Group www-group
+
ÃalıÅan sunucu için özellikle yeni bir grup atamanız önerilir. Bazı
+ sistem yöneticileri nobody
grubunu kullanırlar fakat
+ bu her zaman mümkün olmadıÄı gibi arzulanan da deÄildir.
Ne yaptıÄınızı ve ne tehlikelere yol açacaÄınızı bilmiyorsanız
+ Group
(veya User
) yönergesine deÄer olarak
+ root
atamayınız.
Ãzel bilgi: Bu yönergenin <VirtualHost>
taÅıyıcısı içinde kullanımı
+ artık desteklenmemektedir. Sunucunuzu suexec
için
+ yapılandırırken SuexecUserGroup
yönergesini
+ kullanınız.
Açıklama: | Sunucunun dinleyeceÄi IP adresini ve portu belirler. |
---|---|
Sözdizimi: | Listen [IP-adresi:]port-numarası |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | beos , leader , mpm_netware , mpm_winnt , mpmt_os2 , perchild , prefork , threadpool , worker , event |
Uyumluluk: | Apache 2.0âdan beri gerekli yönergelerden + biridir. |
Listen
yönergesi Apacheâyi sadece belli IP
+ adreslerini ve portlarını dinlemeye sevkeder.
+ Listen
artık belirtilmesi zorunlu yönergelerden
+ biridir. Yapılandırma dosyasında bulunmadıÄı takdirde sunucu
+ baÅlatılırken baÅarısız olacaktır. Bu Apache Sunucusunun önceki
+ sürümünde böyle deÄildi.
Listen
yönergesi Apacheâye, sadece belli
+ portlardan veya IP adresi ve port çiftlerinden gelen istekleri kabul
+ etmesini söyler. EÄer sadece port numarası belirtilmiÅse sunucu
+ belirtilen portu bütün aÄ arabirimlerinde dinleyecektir. EÄer portla
+ birlikte bir IP adresi de belirtilmiÅse, sunucu belirtilen portu sadece
+ belirtilen arabirimden dinleyecektir.
Ãok sayıda IP adresi ve port belirtmek için çok sayıda
+ Listen
yönergesi kullanılabilir. Sunucu bu
+ durumda belirtilen bütün IP adreslerinden ve portlardan gelecek
+ isteklere yanıt verecektir.
ÃrneÄin sunucunun hem port 80 hem de port 8000âden istek kabul etmesini + istiyorsanız bunu Åöyle belirtebilirsiniz:
+ +
+ Listen 80
+ Listen 8000
+
Sunucunun belirtilen iki aÄ arabiriminden ve port numarasından gelen + baÄlantıları kabul etmesi için Åu yapılandırmayı kullanabilirsiniz:
+ +
+ Listen 192.170.2.1:80
+ Listen 192.170.2.5:8000
+
IPv6 adresleri belirtilirken örnekteki gibi köÅeli ayraçlar arasına + alınmalıdır:
+ +
+ Listen [2001:db8::a00:20ff:fea7:ccea]:80
+
Listen
+ yönergesinde belirtilmesi bir "adres kullanımda" (Address already
+ in use
) hatasına yol açar.
+ Açıklama: | Bekleyen baÄlantılar kuyruÄunun azami uzunluÄunu + belirler |
---|---|
Sözdizimi: | ListenBacklog kuyruk-uzunluÄu |
Ãntanımlı: | ListenBacklog 511 |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | beos , leader , mpm_netware , mpm_winnt , mpmt_os2 , perchild , prefork , threadpool , worker |
Bekleyen baÄlantılar kuyruÄunun azami uzunluÄu. Genellikle bu ayar ne
+ gerekir ne de istenir. Ancak bazı sistemlerde TCP SYN yüklenme
+ saldırılarına karÅı bu deÄerin arttırılması gerekebilir.
+ kuyruk-uzunluÄu parametresi için listen(2)
+ iÅlevinin açıklamasına bakınız.
Bu deÄer çoÄunlukla iÅletim sistemi tarafından daha küçük bir sayıyla + sınırlanır. Bu, iÅletim sistemine baÄlı olarak deÄiÅiklik gösterir. + Ayrıca, çoÄu iÅletim sisteminin kuyruk-uzunluÄu parametresi + ile ne belirttiÄinize bakmaksızın kendisi için atanmıŠdeÄeri (fakat + normal olarak daha büyüÄünü) kullanacaÄına dikkat ediniz.
+ +Açıklama: | Apache HTTPd Sunucusunun aÄ soketlerinden istekleri kabul eden + çok sayıda çocuk süreci sıraya sokarken kullandıÄı kilit dosyasının yerini + belirler. |
---|---|
Sözdizimi: | LockFile dosya |
Ãntanımlı: | LockFile logs/accept.lock |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | leader , perchild , prefork , threadpool , worker |
LockFile
yönergesi, AcceptMutex
yönergesi fcntl
+ veya flock
deÄeri ile belirtildiÄi takdirde kullanılan
+ kilit dosyasının yerini belirler. Bu yönerge normalde öntanımlı
+ deÄeriyle bırakılır. DeÄiÅmesini gerektiren ana sebep, logs
+ dizininin aÄ dosya sisteminde (NFS) yeralması halinde kilit
+ dosyasının bir yerel diskte saklanması gereÄidir. Ana sürecin
+ süreç kimliÄi dosyaya kendiliÄinden eklenir.
Bu dosyayı herkesin yazabildiÄi /var/tmp
gibi bir dizine
+ koymaktan kaçınmak gerekir. Ãünkü, bu takdirde, birileri sunucunun
+ hizmet sunmaya baÅlarken oluÅturacaÄı kilit dosyası ile aynı isimde
+ bir dosya oluÅturarak hizmet reddi saldırısı (DoS) baÅlatabilir.
AcceptMutex
Açıklama: | İstekleri sunarken oluÅturulacak çocuk süreçlerin azami sayısını + belirler. |
---|---|
Sözdizimi: | MaxClients sayı |
Ãntanımlı: | Ayrıntılar için aÅaÄıdaki açıklamaya bakınız. |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | beos , leader , prefork , threadpool , worker |
MaxClients
yönergesi aynı anda sunulacak istek
+ sayısını sınırlamak için kullanılır. MaxClients
+ istekten fazlası geldiÄi takdirde bu istekler normal olarak kuyruÄa
+ alınıp bekletilir. Kuyrukta bekletilecek isteklerin azami sayısı ise
+ ListenBacklog
yönergesi ile
+ belirlenir. İstek sunmakta olan çocuk süreçlerden biri serbest
+ kaldıÄında bekletilen baÄlantılardan birine hizmet sunulmaya
+ baÅlanır.
Evreli olmayan sunucularda (prefork
gibi)
+ MaxClients
yönergesi istekleri sunmak için
+ baÅlatılacak çocuk süreçlerin azami sayısını belirler. Ãntanımlı deÄer
+ 256 olup bu deÄeri arttırmak isterseniz ServerLimit
deÄerini de
+ arttırmalısınız.
Ãok evreli ve melez sunucularda (beos
veya
+ worker
gibi) MaxClients
+ yönergesi istemcilere hizmet verecek evre sayısını sınırlar. Ãntanımlı
+ deÄer beos
için 50
iken melez MPMâler için
+ ServerLimit
ile ThreadsPerChild
çarpımıdır (16 x
+ 25
). Bu bakımdan MaxClients
deÄerini 16
+ süreçten fazlasına ayarlamak için ServerLimit
deÄerini de
+ arttırmalısınız.
Açıklama: | free() çaÄrılmaksızın ana bellek ayırıcının
+ ayırmasına izin verilen azami bellek miktarını belirler. |
---|---|
Sözdizimi: | MaxMemFree kB-sayısı |
Ãntanımlı: | MaxMemFree 0 |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | beos , leader , mpm_netware , prefork , threadpool , worker , mpm_winnt |
MaxMemFree
yönergesi, free()
+ çaÄrılmaksızın ana bellek ayırıcının ayırmasına izin verilen azami
+ bellek miktarını kB cinsinden belirler. Bir deÄerle belirtilmediÄinde
+ veya 0
deÄeriyle belirtildiÄinde eÅik sınırsız
+ olacaktır.
Açıklama: | Tek bir çocuk sürecin ömrü boyunca iÅleme sokabileceÄi istek + sayısını sınırlamakta kullanılır. |
---|---|
Sözdizimi: | MaxRequestsPerChild sayı |
Ãntanımlı: | MaxRequestsPerChild 10000 |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | leader , mpm_netware , mpm_winnt , mpmt_os2 , perchild , prefork , threadpool , worker |
MaxRequestsPerChild
yönergesi, tek bir çocuk
+ sürecin iÅleme sokabileceÄi istek sayısını sınırlamakta kullanılır.
+ MaxRequestsPerChild
istekten sonra çocuk süreç
+ ölür. EÄer MaxRequestsPerChild
için
+ 0
belirtilmiÅse sürecin ömrü sonsuz olacaktır.
mpm_netware
ve mpm_winnt
için
+ öntanımlı deÄer 0
âdır.
MaxRequestsPerChild
için sıfırdan farklı bir
+ deÄer belirtmenin iki yararlı etkisi vardır:
KeepAlive
isteklerinde sadece
+ ilk istek bu sınıra uygun sayılır. Etkisi ise, davranıÅın çocuk süreç
+ baÅına baÄlantı sayısının sınırlanması Åeklinde
+ deÄiÅmesidir.
Açıklama: | BoÅtaki azami evre sayısını belirler |
---|---|
Sözdizimi: | MaxSpareThreads number |
Ãntanımlı: | Ayrıntılar için aÅaÄıdaki açıklamaya bakınız. |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | beos , leader , mpm_netware , mpmt_os2 , perchild , threadpool , worker |
BoÅtaki azami evre sayısı. Her MPM bu yönerge karÅısında farklı + davranır.
+ +perchild
için MaxSpareThreads 10
+ öntanımlıdır. Bu MPM, boÅtaki evrelerin sayısını çocuk süreç baÅına
+ boÅtaki evre sayısı olarak izler. Bir çocukta çok fazla boÅta evre
+ varsa sunucu sadece o çocuÄun boÅtaki evrelerini öldürür.
worker
, leader
ve
+ threadpool
için MaxSpareThreads 250
+ öntanımlıdır. Bu MPMâler boÅtaki evreleri sunucu genelinde izler. EÄer
+ sunucuda çok fazla boÅta evre varsa, sunucu boÅtaki evrelerin sayısı bu
+ sınırın altına inene kadar çocuk süreçleri öldürür.
mpm_netware
için MaxSpareThreads 100
+ öntanımlıdır. Bu MPM tek bir süreç olarak çalıÅtıÄından boÅtaki evre
+ sayısı aynı zamanda sunucu genelinde boÅtaki evre sayısıdır.
beos
ve mpmt_os2
MPMâleri
+ mpm_netware
gibidir. beos
için
+ MaxSpareThreads 50
öntanımlıyken mpmt_os2
+ için öntanımlı deÄer 10
âdur.
MaxSpareThreads
için deÄer aralıÄı sınırlıdır.
+ Apache belirtilen deÄeri aÅaÄıdaki kurallara uygun olarak
+ kendiliÄinden düzeltecektir:
perchild
için
+ MaxSpareThreads
deÄerinin ThreadLimit
deÄerinden küçük veya
+ eÅit olması gerekir.mpm_netware
modülü, deÄerin MinSpareThreads
deÄerinden küçük
+ olmasını gerektirir.leader
, threadpool
ve
+ worker
için deÄer, MinSpareThreads
+ ve ThreadsPerChild
+ toplamına eÅit veya büyük olmak zorundadır.Açıklama: | İsteklerin ani artıÅında devreye girecek boÅtaki evrelerin asgari + sayısını belirler. |
---|---|
Sözdizimi: | MinSpareThreads number |
Ãntanımlı: | Ayrıntılar için aÅaÄıdaki açıklamaya bakınız. |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | beos , leader , mpm_netware , mpmt_os2 , perchild , threadpool , worker |
İsteklerin ani artıÅında devreye girecek boÅtaki evrelerin asgari + sayısı. Her MPM bu yönerge karÅısında farklı davranır.
+ +perchild
için MinSpareThreads 5
+ öntanımlıdır ve çocuk süreç baÅına boÅtaki evre sayısını izler. Bir
+ çocuk için yeterince boÅta evre yoksa sunucu bu çocuk için yeni evreler
+ oluÅturmaya baÅlar. Nitekim, NumServers
için 10
ve
+ MinSpareThreads
için 5
atarsanız
+ sisteminizdeki boÅtaki evre sayısı en az 50 olur.
worker
, leader
ve
+ threadpool
modülleri için MinSpareThreads
+ 75
öntanımlıdır ve bu modüller boÅtaki evreleri sunucu genelinde
+ izler. EÄer sunucuda boÅtaki evre sayısı yetersizse, sunucu boÅtaki
+ evrelerin sayısı bu sınırın üstüne çıkana kadar çocuk süreç
+ oluÅturur.
mpm_netware
için MinSpareThreads 10
+ öntanımlıdır ve tek süreç kendisi olduÄundan izleme sunucu genelinde
+ yapılır.
beos
ve mpmt_os2
modülleri
+ mpm_netware
gibidir. beos
için
+ MinSpareThreads 1
öntanımlı iken mpmt_os2
+ için öntanımlı deÄer 5
âtir.
Açıklama: | Ana sürecin süreç kimliÄinin (PID) kaydedileceÄi dosyayı belirler. |
---|---|
Sözdizimi: | PidFile dosya |
Ãntanımlı: | PidFile logs/httpd.pid |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | beos , leader , mpm_winnt , mpmt_os2 , perchild , prefork , threadpool , worker |
PidFile
yönergesi, sunucunun artalan sürecinin
+ süreç kimliÄinin kaydedileceÄi dosyayı belirler. Dosya ismi mutlak dosya
+ yoluyla belirtilmemiÅse dosya yolunun ServerRoot
dizinine göre belirtildiÄi kabul
+ edilir.
+ PidFile /var/run/apache.pid
+
Sunucuya sinyal gönderebilmek çoÄunlukla iÅe yarar. Böylece ErrorLog
ve TransferLog
dosyaları kapatılıp
+ yeniden açılır ve yapılandırma dosyaları yeniden okunur. Bu,
+ PidFile
dosyasında belirtilen süreç kimliÄine bir
+ SIGHUP (kill -1) sinyali gönderilerek yapılır.
Günlük dosyasının yeri ve güvenlik ile ilgili
+ uyarılar PidFile
dosyası içinde sözkonusu
+ olabilir.
Apache 2âde sunucuyu (yeniden) baÅlatırken veya durdururken sadece
+ apachectl
betiÄini kullanmanız önerilir.
Açıklama: | TCP alım tamponu boyu |
---|---|
Sözdizimi: | ReceiveBufferSize bayt-sayısı |
Ãntanımlı: | ReceiveBufferSize 0 |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | beos , leader , mpm_netware , mpm_winnt , mpmt_os2 , perchild , prefork , threadpool , worker |
Sunucu TCP alım tamponu boyunu bayt-sayısı ile belirtilen + bayta ayarlayacaktır.
+ +0
deÄeri atarsanız sunucu iÅletim sistemi öntanımlısını
+ kullanacaktır.
Açıklama: | Ãocuk süreçler için eÅgüdüm verisini saklamakta kullanılan + dosyanın yerini belirler. |
---|---|
Sözdizimi: | ScoreBoardFile dosya-yolu |
Ãntanımlı: | ScoreBoardFile logs/apache_status |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | beos , leader , mpm_winnt , perchild , prefork , threadpool , worker |
Apache ana ve çocuk süreçler arasında iletiÅim için bir çetele tutar. + Bazı mimariler bu iletiÅimi kolaylaÅtırmak için bir dosya gerektirir. + EÄer yönerge belirtilmezse Apache çeteleyi önce tamamen bellekte + oluÅturmayı dener (anonim paylaÅımlı bellek kullanarak); bunda baÅarılı + olamazsa dosyayı diskte oluÅturmaya çalıÅacaktır (paylaÅımlı belleÄe + eÅlemli dosya kullanarak). Bu yönergenin belirtilmesi Apache sunucusunun + dosyayı daima diskte oluÅturmasına sebep olur.
+ +
+ ScoreBoardFile /var/run/apache_status
+
PaylaÅımlı belleÄe eÅlemli dosya, çeteleye doÄrudan eriÅmesi gereken + üçüncü parti uygulamalar için yararlıdır.
+ +EÄer ScoreBoardFile
yönergesi ile bir dosya
+ belirtecekseniz, dosyayı bir RAM diske yerleÅtirerek hız artıÅı
+ saÄlayabilirsiniz. Fakat, günlük dosyası yerleÅtirme ve güvenlik ile ilgili uyarılara
+ benzer uyarılara karÅı dikkatli olunuz.
Açıklama: | TCP tamponu boyu |
---|---|
Sözdizimi: | SendBufferSize bayt-sayısı |
Ãntanımlı: | SendBufferSize 0 |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | beos , leader , mpm_netware , mpm_winnt , mpmt_os2 , perchild , prefork , threadpool , worker |
Sunucu TCP gönderim tamponu boyunu bayt-sayısı ile + belirtilen bayta ayarlayacaktır. Yüksek hızlı yüksek yataklık süresi + için standart iÅletim sistemi öntanımlılarını arttırmak çok yararlıdır + (örneÄin, kıtalar arası hızlı borularda olduÄu gibi 100 ms + civarında).
+ +0
deÄeri atarsanız sunucu iÅletim sistemi öntanımlısını
+ kullanacaktır.
Açıklama: | Ayarlanabilir süreç sayısının üst sınırını belirler. |
---|---|
Sözdizimi: | ServerLimit sayı |
Ãntanımlı: | Ayrıntılar için aÅaÄıdaki açıklamaya bakınız. |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | leader , perchild , prefork , threadpool , worker |
prefork
modülü söz konusu olduÄunda bu yönerge, Apache
+ sürecinin ömrü boyunca MaxClients
yönergesine atanabilecek
+ azami deÄeri belirler. worker
modülü sözkonusu
+ olduÄunda ise, Apache sürecinin ömrü boyunca MaxClients
yönergesine atanabilecek
+ azami deÄeri ThreadLimit
ile
+ birlikte belirler. Bu yönergeyi bir yeniden baÅlatma sırasında
+ deÄiÅtirirseniz bu deÄiÅiklik yok sayılır fakat MaxClients
deÄiÅiklikleri dikkate
+ alınır.
Bu yönergenin kullanılması özel bir dikkat gerektirir. EÄer
+ ServerLimit
gereÄinden yüksek bir deÄere
+ ayarlanırsa, gereksiz yere paylaÅımlı bellek ayrılmıŠolur. EÄer
+ ServerLimit
ve MaxClients
deÄerleri sistemin
+ iÅleyebileceÄinden daha yüksek deÄerlere ayarlanırsa Apache
+ baÅlayamayacaÄı gibi sistemi kararsız hale de getirebilir.
Bu yönergeyi prefork
modülü ile sadece MaxClients
yönergesine 256âdan
+ (öntanımlı) daha büyük bir deÄer atayacaksanız kullanınız. Bu yönergeye
+ MaxClients
için atamak
+ istediÄiniz deÄerden fazlasını atamayınız.
worker
, leader
ve
+ threadpool
modülleri söz konusu olduÄunda bu yönergeyi
+ MaxClients
ve
+ ThreadsPerChild
ayarları 16
+ sunucu sürecinden (16 öntanımlıdır) fazlasını gerektiriyorsa
+ ayarlayınız. Bu yönergeye MaxClients
+
ve ThreadsPerChild
için gerekli gördüÄünüz
+ sunucu süreci sayısından fazlasını atamayınız.
perchild
modülüyle bu yönergeyi eÄer NumServers
yönergesine 8âden (öntanımlı)
+ büyük bir deÄer atayacaksanız kullanınız.
Sunucu içinde derlenmiŠolarak ServerLimit 20000
+ Åeklinde bir zorlayıcı sınır vardır. Bu önlem, yazım hatalarının
+ istenmeyen sonuçlara yol açmasını engellemek için düÅünülmüÅtür.
Açıklama: | Sunucunun baÅlatılması sırasında oluÅturulan çocuk süreçlerin + sayısını belirler. |
---|---|
Sözdizimi: | StartServers sayı |
Ãntanımlı: | Ayrıntılar için aÅaÄıdaki açıklamaya bakınız. |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | leader , mpmt_os2 , prefork , threadpool , worker |
StartServers
yönergesi, sunucunun baÅlatılması
+ sırasında oluÅturulan çocuk süreçlerin sayısını belirler. Süreç sayısı
+ normal olarak yüke baÄlı olarak deÄiÅse de bu deÄerin ayarlanmasını
+ gerektirecek küçük bir sebep vardır.
Ãntanımlı deÄer MPMâden MPMâe fark eder. Ãntanımlı deÄer
+ leader
, threadpool
ve
+ worker
için 3
iken
+ prefork
için 5
ve
+ mpmt_os2
için 2
âdir.
Açıklama: | Sunucunun baÅlatılması sırasında oluÅturulan evrelerin sayısını + belirler. |
---|---|
Sözdizimi: | StartThreads sayı |
Ãntanımlı: | Ayrıntılar için aÅaÄıdaki açıklamaya bakınız. |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | beos , mpm_netware , perchild |
StartThreads
yönergesi, sunucunun baÅlatılması
+ sırasında oluÅturulan evrelerin sayısını belirler. Evre sayısı normal
+ olarak yüke baÄlı olarak deÄiÅse de bu deÄerin ayarlanmasını
+ gerektirecek küçük bir sebep vardır.
perchild
için StartThreads 5
öntanımlı
+ olup bu yönerge sunucunun baÅlatılması sırasında oluÅturulan süreç
+ baÅına evre sayısıyla baÄlantısını sürdürür.
mpm_netware
için StartThreads 50
+ öntanımlı olup, sadece tek bir süreç olduÄundan, sunucunun baÅlatılması
+ sırasında oluÅturulan evrelerin toplam sayısı 50
âdir.
beos
için StartThreads 10
öntanımlı olup
+ sunucunun baÅlatılması sırasında oluÅturulan evrelerin toplam sayısı
+ 10
âdur.
Açıklama: | Ãocuk süreç baÅına ayarlanabilir evre sayısının üst sınırını + belirler. |
---|---|
Sözdizimi: | ThreadLimit sayı |
Ãntanımlı: | Ayrıntılar için aÅaÄıdaki açıklamaya bakınız. |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | leader , mpm_winnt , perchild , threadpool , worker |
Uyumluluk: | mpm_winnt için Apache 2.0.41 ve sonrasında mevcuttur. |
Bu yönerge, Apache sürecinin ömrü boyunca ThreadsPerChild
yönergesine
+ atanabilecek azami deÄeri belirler. Bu yönergeyi bir yeniden baÅlatma
+ sırasında deÄiÅtirirseniz bu deÄiÅiklik yok sayılır fakat ThreadsPerChild
deÄiÅiklikleri dikkate
+ alınır.
Bu yönergenin kullanılması özel bir dikkat gerektirir. EÄer
+ ThreadLimit
deÄeri ThreadsPerChild
deÄerinden yüksek bir
+ deÄere ayarlanırsa, gereksiz yere paylaÅımlı bellek ayrılmıŠolur. EÄer
+ ThreadLimit
ve ThreadsPerChild
deÄerleri sistemin
+ iÅleyebileceÄinden daha yüksek deÄerlere ayarlanırsa Apache
+ baÅlayamayacaÄı gibi sistemi kararsız hale de getirebilir. Bu yönergeye
+ Apache sunucusunun çalıÅması için öngörülmüŠen büyük deÄerden daha
+ yükseÄini atamayınız.
ThreadLimit
yönergesinin öntanımlı deÄeri
+ mpm_winnt
için 1920
, diÄerleri için
+ 64
âtür.
Sunucu içinde derlenmiŠolarak ThreadLimit 20000
+ Åeklinde bir zorlayıcı sınır vardır (mpm_winnt
için
+ 15000âdir). Bu önlem, yazım hatalarının istenmeyen sonuçlara yol
+ açmasını engellemek için düÅünülmüÅtür.
Açıklama: | Her çocuk süreç tarafından oluÅturulan evrelerin sayısını + belirler. |
---|---|
Sözdizimi: | ThreadsPerChild sayı |
Ãntanımlı: | Ayrıntılar için aÅaÄıdaki açıklamaya bakınız. |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | leader , mpm_winnt , threadpool , worker |
Bu yönerge, her çocuk süreç tarafından oluÅturulan evrelerin sayısını
+ belirler. Ãocuk süreçler bu evreleri baÅlatıldıklarında oluÅtururlar ve
+ bundan daha fazlasını asla oluÅturmazlar. mpm_winnt
+ gibi sadece bir çocuk sürecin bulunduÄu bir MPM kullanıyorsanız, bu
+ sayı sunucunun tüm yükünü kaldırabilecek kadar büyük olmalıdır.
+ worker
gibi çok çocuk süreçli bir MPM kullanıyorsanız,
+ toplam evre sayısı sunucunun tüm yükünü kaldırabilecek kadar
+ büyük olmalıdır.
ThreadsPerChild
için öntanımlı deÄer
+ mpm_winnt
kullanıldıÄında 64
diÄerleri
+ için 25
âtir.
Açıklama: | İsteklere yanıt verecek sunucunun ait olacaÄı kullanıcıyı + belirler. |
---|---|
Sözdizimi: | User unix-kullanıcısı |
Ãntanımlı: | User #-1 |
BaÄlam: | sunucu geneli |
Durum: | MPM |
Modül: | leader , perchild , prefork , threadpool , worker |
Uyumluluk: | Apache 2.0âdan itibaren sadece sunucu geneli için + geçerlidir. |
User
yönergesi, sunucunun hangi kullanıcı olarak
+ isteklere yanıt vereceÄini belirler. Bu yönergenin uygulanabilmesi için
+ sunucunun root
olarak çalıÅtırılmıŠolması gerekir.
+ Sunucuyu root
dıÅında bir kullanıcı baÅlattıÄı takdirde,
+ sunucu belirtilen kullanıcıya geçemez ve mevcut kullanıcıyla çalıÅmaya
+ devam eder. EÄer sunucuyu root
olarak baÅlatmıÅsanız ana
+ süreç root olarak çalıÅmaya devam edecektir. unix-kullanıcısı
+ Åunlardan biri olabilir:
#
ardından kullanıcı numarasıBu yönergede belirtilecek kullanıcının, baÅkaları tarafından üzerinde
+ deÄiÅiklik yapılabilecek dosyalardan baÅkasına eriÅemeyen bir kullanıcı
+ olmaması gerektiÄi gibi, HTTP isteklerini iÅlemek dıÅında iÅlemler de
+ yapabilen bir kullanıcı olmamalıdır.
+ ÃalıÅan sunucu için özellikle yeni bir grup atamanız önerilir. Bazı
+ sistem yöneticileri nobody
kullanıcısını kullanırlar fakat
+ nobody
kullanıcısı sistemde baÅka amaçlarla
+ kullanılabildiÄinden bu her zaman mümkün olmadıÄı gibi arzulanan da
+ deÄildir.
Ne yaptıÄınızı ve ne tehlikelere yol açacaÄınızı bilmiyorsanız
+ User
(veya Group
) yönergesine deÄer olarak
+ root
atamayınız.
Sanal konakları farklı kullanıcı kimliklerle çalıÅtırmak üzere
+ tasarlanan perchild
modülü kullanıldıÄında <VirtualHost>
bölümlerinde
+ AssignUserID
yönergesi ile
+ farklı bir kullanıcı kimlik tanımlanmadıÄı takdirde
+ User
yönergesi ile ana sunucu için tanımlanan
+ kullanıcı kimlik sanal konak için de geçerli olur.
Ãzel bilgi: Bu yönergenin <VirtualHost>
taÅıyıcısı içinde kullanımı
+ artık desteklenmemektedir. Sunucunuzu suexec
için
+ yapılandırırken SuexecUserGroup
yönergesini
+ kullanınız.
Das Dokument beschreibt, was ein Multi-Processing-Modul ist und wie solche @@ -122,7 +123,8 @@ es | ja | ko | - ru
+ ru | + tr diff --git a/docs/manual/mpm.html.en b/docs/manual/mpm.html.en index c584b0d04f6..9c2b063e95c 100644 --- a/docs/manual/mpm.html.en +++ b/docs/manual/mpm.html.en @@ -23,7 +23,8 @@ es | ja | ko | - ru + ru | + trThis document describes what a Multi-Processing Module is and @@ -123,7 +124,8 @@ choice at compile-time.
es | ja | ko | - ru + ru | + tr diff --git a/docs/manual/mpm.html.es b/docs/manual/mpm.html.es index 11f313b698c..c4cf96a2fe3 100644 --- a/docs/manual/mpm.html.es +++ b/docs/manual/mpm.html.es @@ -23,7 +23,8 @@ es | ja | ko | - ru + ru | + trEste documento explica que son los Módulos de @@ -132,7 +133,8 @@ se especifica lo contrario al compilar.
es | ja | ko | - ru + ru | + tr diff --git a/docs/manual/mpm.html.ja.utf8 b/docs/manual/mpm.html.ja.utf8 index e7379ee6e48..cea4e7155ec 100644 --- a/docs/manual/mpm.html.ja.utf8 +++ b/docs/manual/mpm.html.ja.utf8 @@ -23,7 +23,8 @@ es | ja | ko | - ru + ru | + trüÔÏÔ ÄÏËÕÍÅÎÔ ÏÐÉÓÙ×ÁÅÔ, ÞÔÏ ÔÁËÏÅ ÍÕÌØÔÉ-ÐÒÏÃÅÓÓÎÙÅ ÍÏÄÕÌÉ @@ -129,7 +130,8 @@ es | ja | ko | - ru
+ ru | + tr diff --git a/docs/manual/mpm.html.tr.utf8 b/docs/manual/mpm.html.tr.utf8 index 2b74c9fc715..618507aaeea 100644 --- a/docs/manual/mpm.html.tr.utf8 +++ b/docs/manual/mpm.html.tr.utf8 @@ -1,128 +1,128 @@ - - - -Apache HTTP Sunucusu Sürüm 2.0
-Bu belgede Ãok Süreçlilik Modülü denince ne anlaÅıldıÄı ve bunların - Apache HTTP Sunucusu tarafından nasıl kullanıldıkları açıklanmıÅtır.
-Apache HTTP Sunucusu çok çeÅitli platformlar üstünde farklı ortamlarda - çalıÅabilen güçlü ve esnek bir HTTP sunucusu olarak tasarlanmıÅtır. - Farklı platformlar ve farklı ortamlar çoÄunlukla farklı özellikler veya - aynı özelliÄin en yüksek verimlilikle gerçeklenmesi için farklı yöntemler - gerektirir. Apache, geniÅ ortam çeÅitliliÄini daima modüler tasarımı - sayesinde uzlaÅtırmıÅtır. Bu tasarım, site yöneticilerine, sunucularında - bulunmasını istedikleri özellikleri derleme sırasında veya çalıÅma anında - gerekli modülleri yüklemek suretiyle seçebilme imkanı verir.
- -Apache 2.0, bu modüler tasarımı sunucunun en temel iÅlevlerine kadar - indirmiÅtir. Sunucu, Ãok Süreçlilik Modülleri adı verilen ve makine - üzerindeki aÄ portlarının baÄlanmasından, isteklerin kabul edilmesinden - ve bu istekleri yanıtlayacak çocuklara daÄıtmaktan sorumlu olan - modüllerin seçimine imkan verecek bir yapılanma ile gelir.
- -Sunucunun modüler tasarımının bu seviyede geniÅletilmesi iki önemli - yarar saÄlar:
- -mpm_winnt
modülü, Apache 1.3âte kullanılan POSIX
- katmanının yerine iÅletim sistemine özgü özellikleri
- kullanabildiÄinden, Apache HTTP Sunucusunun Windows sürümü artık çok
- daha verimli bir duruma gelmiÅtir. Aynı fayda özelleÅtirilmiÅ MPMâlerle
- diÄer iÅletim sistemlerine de saÄlanmıÅtır.prefork
modülünü
- kullanabilirken, daha geniŠölçeklenebilirlik gerektiren siteler
- worker
gibi evreli bir MPM modülünü
- seçebilmektedir. Ek olarak, farklı konakların farklı kullanıcı
- kimlikleri ile sunulması gibi özel oluÅumlar da
- (perchild
) saÄlanabilmektedir.Kullanıcı açısından MPMâlerin diÄer Apache modüllerinden görünüÅte bir - farkı yoktur. Asıl fark sunucuya yüklenebilecek azami MPM modülü - sayısının bir ve yalnız bir olarak sınırlanmıŠolmasıdır. Mevcut MPM - modülleri modül dizini sayfasında listelenmiÅtir..
- -MPMâler paket yapılandırması sırasında seçilmeli ve sunucu içinde - derlenmelidir. Derleyiciler evrelerin kullanılacaÄını bildikleri - takdirde çoÄu iÅlevi evreleri kullanacak Åekilde - en iyileyebilmektedir.
- -Kullanmak istediÄiniz MPMâyi kendiniz seçmek istediÄiniz takdirde
- configure
betiÄini
- --with-mpm=AD
seçeneÄi ile kullanınız. Burada
- AD istenen MPMânin adıdır.
Sunucu derlendikten sonra hangi MPMânin seçilmiÅ olduÄunu ./httpd
- -l
komutuyla saptamak mümkündür. Bu komut, MPM de dahil omak
- üzere sunucuyla birlikte derlenmiŠtüm modülleri listeleyecektir.
AÅaÄıdaki tabloda çeÅitli iÅletim sistemlerinde öntanımlı olan MPMâler - listelenmiÅtir. Derleme sırasında baÅka bir seçim yapmadıÄınız takdirde - bu iÅletim sistemlerinde bu MPMâler seçilmiÅ olacaktır.
- -BeOS | beos |
Netware | mpm_netware |
OS/2 | mpmt_os2 |
Unix | prefork |
Windows | mpm_winnt |
Apache HTTP Sunucusu Sürüm 2.0
+Bu belgede Ãok Süreçlilik Modülü denince ne anlaÅıldıÄı ve bunların + Apache HTTP Sunucusu tarafından nasıl kullanıldıkları açıklanmıÅtır.
+Apache HTTP Sunucusu çok çeÅitli platformlar üstünde farklı ortamlarda + çalıÅabilen güçlü ve esnek bir HTTP sunucusu olarak tasarlanmıÅtır. + Farklı platformlar ve farklı ortamlar çoÄunlukla farklı özellikler veya + aynı özelliÄin en yüksek verimlilikle gerçeklenmesi için farklı yöntemler + gerektirir. Apache, geniÅ ortam çeÅitliliÄini daima modüler tasarımı + sayesinde uzlaÅtırmıÅtır. Bu tasarım, site yöneticilerine, sunucularında + bulunmasını istedikleri özellikleri derleme sırasında veya çalıÅma anında + gerekli modülleri yüklemek suretiyle seçebilme imkanı verir.
+ +Apache 2.0, bu modüler tasarımı sunucunun en temel iÅlevlerine kadar + indirmiÅtir. Sunucu, Ãok Süreçlilik Modülleri adı verilen ve makine + üzerindeki aÄ portlarının baÄlanmasından, isteklerin kabul edilmesinden + ve bu istekleri yanıtlayacak çocuklara daÄıtmaktan sorumlu olan + modüllerin seçimine imkan verecek bir yapılanma ile gelir.
+ +Sunucunun modüler tasarımının bu seviyede geniÅletilmesi iki önemli + yarar saÄlar:
+ +mpm_winnt
modülü, Apache 1.3âte kullanılan POSIX
+ katmanının yerine iÅletim sistemine özgü özellikleri
+ kullanabildiÄinden, Apache HTTP Sunucusunun Windows sürümü artık çok
+ daha verimli bir duruma gelmiÅtir. Aynı fayda özelleÅtirilmiÅ MPMâlerle
+ diÄer iÅletim sistemlerine de saÄlanmıÅtır.prefork
modülünü
+ kullanabilirken, daha geniŠölçeklenebilirlik gerektiren siteler
+ worker
gibi evreli bir MPM modülünü
+ seçebilmektedir. Ek olarak, farklı konakların farklı kullanıcı
+ kimlikleri ile sunulması gibi özel oluÅumlar da
+ (perchild
) saÄlanabilmektedir.Kullanıcı açısından MPMâlerin diÄer Apache modüllerinden görünüÅte bir + farkı yoktur. Asıl fark sunucuya yüklenebilecek azami MPM modülü + sayısının bir ve yalnız bir olarak sınırlanmıŠolmasıdır. Mevcut MPM + modülleri modül dizini sayfasında listelenmiÅtir..
+ +MPMâler paket yapılandırması sırasında seçilmeli ve sunucu içinde + derlenmelidir. Derleyiciler evrelerin kullanılacaÄını bildikleri + takdirde çoÄu iÅlevi evreleri kullanacak Åekilde + en iyileyebilmektedir.
+ +Kullanmak istediÄiniz MPMâyi kendiniz seçmek istediÄiniz takdirde
+ configure
betiÄini
+ --with-mpm=AD
seçeneÄi ile kullanınız. Burada
+ AD istenen MPMânin adıdır.
Sunucu derlendikten sonra hangi MPMânin seçilmiÅ olduÄunu ./httpd
+ -l
komutuyla saptamak mümkündür. Bu komut, MPM de dahil omak
+ üzere sunucuyla birlikte derlenmiŠtüm modülleri listeleyecektir.
AÅaÄıdaki tabloda çeÅitli iÅletim sistemlerinde öntanımlı olan MPMâler + listelenmiÅtir. Derleme sırasında baÅka bir seçim yapmadıÄınız takdirde + bu iÅletim sistemlerinde bu MPMâler seçilmiÅ olacaktır.
+ +BeOS | beos |
Netware | mpm_netware |
OS/2 | mpmt_os2 |
Unix | prefork |
Windows | mpm_winnt |
Available Languages: en | es | ko | - ru
+ ru | + trThis page documents all the executable programs included @@ -92,7 +93,8 @@
Available Languages: en | es | ko | - ru
+ ru | + tr diff --git a/docs/manual/programs/index.html.es b/docs/manual/programs/index.html.es index a9c81173b0f..d1e9fb2f6cb 100644 --- a/docs/manual/programs/index.html.es +++ b/docs/manual/programs/index.html.es @@ -21,7 +21,8 @@Idiomas disponibles: en | es | ko | - ru
+ ru | + trIdiomas disponibles: en | es | ko | - ru
+ ru | + tr°¡´ÉÇÑ ¾ð¾î: en | es | ko | - ru
+ ru | + tr°¡´ÉÇÑ ¾ð¾î: en | es | ko | - ru
+ ru | + tr diff --git a/docs/manual/programs/index.html.ru.koi8-r b/docs/manual/programs/index.html.ru.koi8-r index 1294b21f817..ef842937a2e 100644 --- a/docs/manual/programs/index.html.ru.koi8-r +++ b/docs/manual/programs/index.html.ru.koi8-r @@ -21,7 +21,8 @@äÏÓÔÕÐÎÙÅ ÑÚÙËÉ: en | es | ko | - ru
+ ru | + trüÔÏÔ ÄÏËÕÍÅÎÔ ÏÐÉÓÙ×ÁÅÔ ÎÁÚÎÁÞÅÎÉÅ É ÉÐÏÌØÚÏ×ÁÎÉÅ @@ -86,7 +87,8 @@
äÏÓÔÕÐÎÙÅ ÑÚÙËÉ: en | es | ko | - ru
+ ru | + tr diff --git a/docs/manual/programs/index.html.tr.utf8 b/docs/manual/programs/index.html.tr.utf8 index d0a11f6520f..a57d457b92a 100644 --- a/docs/manual/programs/index.html.tr.utf8 +++ b/docs/manual/programs/index.html.tr.utf8 @@ -1,90 +1,90 @@ - - - -Apache HTTP Sunucusu Sürüm 2.0
-Bu sayfada Apache HTTP Sunucusuna dahil tüm çalıÅtırılabilir programlar - tanıtılmıÅtır.
-httpd
apachectl
ab
apxs
configure
dbmmanage
htdigest
htdbm
htpasswd
logresolve
rotatelogs
suexec
Apache HTTP Sunucusu Sürüm 2.0
+Bu sayfada Apache HTTP Sunucusuna dahil tüm çalıÅtırılabilir programlar + tanıtılmıÅtır.
+httpd
apachectl
ab
apxs
configure
dbmmanage
htdigest
htdbm
htpasswd
logresolve
rotatelogs
suexec
Apache HTTP Server Version 2.0
mod_rewrite
to solve typical URL-based problems with which webmasters are
- commonony confronted. We give detailed descriptions on how to
+ commonly confronted. We give detailed descriptions on how to
solve each problem by configuring URL rewriting rulesets.
[PT]
flag when
- additionally using mod_alias
and
+ it may be necessary to adjust the examples for your
+ situation, e.g., adding the [PT]
flag if
+ using mod_alias
and
mod_userdir
, etc. Or rewriting a ruleset
- to fit in .htaccess
context instead
+ to work in .htaccess
context instead
of per-server context. Always try to understand what a
- particular ruleset really does before you use it. This
+ particular ruleset really does before you use it; this
avoids many problems.We want to create a homogeneous and consistent URL - layout over all WWW servers on a Intranet webcluster, i.e. - all URLs (per definition server local and thus server - dependent!) become actually server independent! - What we want is to give the WWW namespace a consistent - server-independent layout: no URL should have to include - any physically correct target server. The cluster itself - should drive us automatically to the physical target - host.
+ layout across all WWW servers on an Intranet web cluster, i.e., + all URLs (by definition server-local and thus + server-dependent!) become server independent! + What we want is to give the WWW namespace a single consistent + layout: no URL should refer to + any particular target server. The cluster itself + should connect users automatically to a physical target + host as needed, invisibly.First, the knowledge of the target servers come from - (distributed) external maps which contain information - where our users, groups and entities stay. The have the - form
+First, the knowledge of the target servers comes from + (distributed) external maps which contain information on + where our users, groups, and entities reside. They have the + form:
user1 server_of_user1 @@ -87,7 +87,7 @@ user2 server_of_user2We put them into files
+ of the forms:map.xxx-to-host
. Second we need to instruct all servers to redirect URLs - of the forms-/u/user/anypath @@ -103,8 +103,8 @@ http://physical-host/g/group/anypath http://physical-host/e/entity/anypathwhen the URL is not locally valid to a server. The - following ruleset does this for us by the help of the map +
when any URL path need not be valid on every server. The + following ruleset does this for us with the help of the map files (assuming that server0 is a default server which will be used if a user has no entry in the map):
@@ -135,9 +135,9 @@ RewriteRule ^/([uge])/([^/]+)/([^.]+.+) /$1/$2/.www/$3\
Some sites with thousands of users usually use a - structured homedir layout, i.e. each homedir is in a - subdirectory which begins for instance with the first +
Some sites with thousands of users use a
+ structured homedir layout, i.e. each homedir is in a
+ subdirectory which begins (for instance) with the first
character of the username. So, /~foo/anypath
is /home/f/foo/.www/anypath
while /~bar/anypath
is
@@ -148,7 +148,7 @@ RewriteRule ^/([uge])/([^/]+)/([^.]+.+) /$1/$2/.www/$3\
We use the following ruleset to expand the tilde URLs - into exactly the above layout.
+ into the above layout.RewriteEngine on @@ -174,7 +174,7 @@ RewriteRule ^/~(([a-z])[a-z0-9]+)(.*) /home/$2net.sw is my archive of freely available Unix software packages, which I started to collect in 1992. It is both my hobby - and job to to this, because while I'm studying computer + and job to do this, because while I'm studying computer science I have also worked for many years as a system and network administrator in my spare time. Every week I need some sort of software so I created a deep hierarchy of @@ -203,11 +203,11 @@ drwxrwxr-x 10 netsw users 512 Jul 9 14:08 X11/ the world via a nice Web interface. "Nice" means that I wanted to offer an interface where you can browse directly through the archive hierarchy. And "nice" means - that I didn't wanted to change anything inside this + that I didn't want to change anything inside this hierarchy - not even by putting some CGI scripts at the - top of it. Why? Because the above structure should be - later accessible via FTP as well, and I didn't want any - Web or CGI stuff to be there. + top of it. Why? Because the above structure should later be + accessible via FTP as well, and I didn't want any + Web or CGI stuff mixed in there.
The DATA/
subdirectory holds the above
- directory structure, i.e. the real
- net.sw stuff and gets
+ directory structure, i.e. the real
+ net.sw stuff, and gets
automatically updated via rdist
from time to
time. The second part of the problem remains: how to link
these two structures together into one smooth-looking URL
@@ -245,7 +245,7 @@ drwxr-xr-x 2 netsw users 512 Jul 8 23:47 netsw-img/
for the various URLs. Here is the solution: first I put
the following into the per-directory configuration file
in the DocumentRoot
- of the server to rewrite the announced URL
+ of the server to rewrite the public URL path
/net.sw/
to the internal path
/e/netsw
:
L
(last) flag and no
- substitution field ('-
') in the forth part-
') in the fourth part
!
(not) character and
the C
(chain) flag at the first rule
@@ -308,7 +308,7 @@ RewriteRule (.*) netsw-lsdir.cgi/$1
A typical FAQ about URL rewriting is how to redirect
failing requests on webserver A to webserver B. Usually
- this is done via ErrorDocument
CGI-scripts in Perl, but
+ this is done via ErrorDocument
CGI scripts in Perl, but
there is also a mod_rewrite
solution.
- But notice that this performs more poorly than using an
+ But note that this performs more poorly than using an
ErrorDocument
- CGI-script!
The first solution has the best performance but less - flexibility, and is less error safe:
+ flexibility, and is less safe:RewriteEngine on @@ -340,7 +340,7 @@ RewriteRule ^(.+) http://webserverBThe problem here is that this will only work for pages inside theDocumentRoot
. While you can add more Conditions (for instance to also handle homedirs, etc.) - there is better variant: + there is a better variant:-RewriteEngine on @@ -350,11 +350,11 @@ RewriteRule ^(.+) http://webserverB.dom/$1This uses the URL look-ahead feature of
+ the first approach or better anmod_rewrite
. The result is that this will work for all types of URLs - and is a safe way. But it does a performance impact on - the webserver, because for every request there is one - more internal subrequest. So, if your webserver runs on a + and is safe. But it does have a performance impact on + the web server, because for every request there is one + more internal subrequest. So, if your web server runs on a powerful CPU, use this one. If it is a slow machine, use - the first approach or better aErrorDocument
CGI-script.ErrorDocument
CGI script. @@ -370,18 +370,18 @@ RewriteRule ^(.+) http://webserverB.dom/$1Do you know the great CPAN (Comprehensive Perl Archive Network) under http://www.perl.com/CPAN? - This does a redirect to one of several FTP servers around - the world which carry a CPAN mirror and is approximately - near the location of the requesting client. Actually this - can be called an FTP access multiplexing service. While - CPAN runs via CGI scripts, how can a similar approach - implemented via
+ CPAN automatically redirects browsers to one of many FTP + servers around the world (generally one near the requesting + client); each server carries a full CPAN mirror. This is + effectively an FTP access multiplexing service. + CPAN runs via CGI scripts, but how could a similar approach + be implemented viamod_rewrite
?mod_rewrite
?- Solution:
- -
First we notice that from version 3.0.0 +
First we notice that as of version 3.0.0,
mod_rewrite
can also use the "ftp:
" scheme on redirects. And second, the location approximation can be done by a @@ -427,9 +427,9 @@ com ftp://ftp.cxan.com/CxAN/At least for important top-level pages it is sometimes necessary to provide the optimum of browser dependent - content, i.e. one has to provide a maximum version for the - latest Netscape variants, a minimum version for the Lynx - browsers and a average feature version for all others.
+ content, i.e., one has to provide one version for + current browsers, a different version for the Lynx and text-mode + browsers, and another for other browsers.- Solution:
@@ -437,14 +437,14 @@ com ftp://ftp.cxan.com/CxAN/- @@ -740,8 +742,8 @@ while (<STDIN>) {
We cannot use content negotiation because the browsers do not provide their type in that form. Instead we have to - act on the HTTP header "User-Agent". The following condig + act on the HTTP header "User-Agent". The following config does the following: If the HTTP header "User-Agent" begins with "Mozilla/3", the page
+ This is done with the following ruleset:foo.html
- is rewritten tofoo.NS.html
and and the + is rewritten tofoo.NS.html
and the rewriting stops. If the browser is "Lynx" or "Mozilla" of - version 1 or 2 the URL becomesfoo.20.html
. + version 1 or 2, the URL becomesfoo.20.html
. All other browsers receive pagefoo.32.html
. - This is done by the following ruleset:RewriteCond %{HTTP_USER_AGENT} ^Mozilla/3.* @@ -469,25 +469,25 @@ RewriteRule ^foo\.html$ foo.32.html [L- Description:
- -
Assume there are nice webpages on remote hosts we want +
Assume there are nice web pages on remote hosts we want to bring into our namespace. For FTP servers we would use the
+ mirror with data which gets updated automatically + as needed on the remote host(s).mirror
program which actually maintains an explicit up-to-date copy of the remote data on the local - machine. For a webserver we could use the program -webcopy
which acts similar via HTTP. But both - techniques have one major drawback: The local copy is - always just as up-to-date as often we run the program. It - would be much better if the mirror is not a static one we + machine. For a web server we could use the program +webcopy
which runs via HTTP. But both + techniques have a major drawback: The local copy is + always only as up-to-date as the last time we ran the program. It + would be much better if the mirror was not a static one we have to establish explicitly. Instead we want a dynamic - mirror with data which gets updated automatically when - there is need (updated data on the remote host).- Solution:
- -
To provide this feature we map the remote webpage or even - the complete remote webarea to our namespace by the use +
To provide this feature we map the remote web page or even + the complete remote web area to our namespace by the use of the Proxy Throughput feature (flag
@@ -538,22 +538,22 @@ RewriteRule ^http://www\.remotesite\.com/(.*)$ /mirror/of/remotesite/$1[P]
):This is a tricky way of virtually running a corporate - (external) Internet webserver + (external) Internet web server (
www.quux-corp.dom
), while actually keeping - and maintaining its data on a (internal) Intranet webserver + and maintaining its data on an (internal) Intranet web server (www2.quux-corp.dom
) which is protected by a - firewall. The trick is that on the external webserver we - retrieve the requested data on-the-fly from the internal + firewall. The trick is that the external web server retrieves + the requested data on-the-fly from the internal one.- Solution:
- -
First, we have to make sure that our firewall still - protects the internal webserver and that only the - external webserver is allowed to retrieve data from it. - For a packet-filtering firewall we could for instance +
First, we must make sure that our firewall still + protects the internal web server and only the + external web server is allowed to retrieve data from it. + On a packet-filtering firewall, for instance, we could configure a firewall ruleset like the following:
+ processing is handled done on the other machines. + For a complicated site, this may work well. The biggest + risk here is that www0 is now a single point of failure -- + if it crashes, the other servers are inaccessible.@@ -593,18 +593,18 @@ RewriteRule ^/home/([^/]+)/.www/?(.*) http://www2.quux-corp.dom- Solution:
- -
There are a lot of possible solutions for this problem. - We will discuss first a commonly known DNS-based variant - and then the special one with
+mod_rewrite
:There are many possible solutions for this problem. + We will first discuss a common DNS-based method, + and then one based on
mod_rewrite
:
- DNS Round-Robin
The simplest method for load-balancing is to use - the DNS round-robin feature of
+ as usual in your DNS with A (address) records, e.g.,BIND
. + DNS round-robin. Here you just configurewww[0-9].foo.com
- as usual in your DNS with A(address) records, e.g.-www0 IN A 1.2.3.1 @@ -615,33 +615,31 @@ www4 IN A 1.2.3.5 www5 IN A 1.2.3.6Then you additionally add the following entry:
+Then you additionally add the following entries:
--www IN CNAME www0.foo.com. - IN CNAME www1.foo.com. - IN CNAME www2.foo.com. - IN CNAME www3.foo.com. - IN CNAME www4.foo.com. - IN CNAME www5.foo.com. - IN CNAME www6.foo.com. +www IN A 1.2.3.1 +www IN A 1.2.3.2 +www IN A 1.2.3.3 +www IN A 1.2.3.4 +www IN A 1.2.3.5Notice that this seems wrong, but is actually an - intended feature of
BIND
and can be used - in this way. However, now whenwww.foo.com
gets - resolved,BIND
gives outwww0-www6
- - but in a slightly permutated/rotated order every time. +Now when
+ to a particularwww.foo.com
gets + resolved,BIND
gives outwww0-www5
+ - but in a permutated (rotated) order every time. This way the clients are spread over the various - servers. But notice that this not a perfect load - balancing scheme, because DNS resolve information - gets cached by the other nameservers on the net, so + servers. But notice that this is not a perfect load + balancing scheme, because DNS resolutions are + cached by clients and other nameservers, so once a client has resolvedwww.foo.com
- to a particularwwwN.foo.com
, all - subsequent requests also go to this particular name -wwwN.foo.com
. But the final result is - ok, because the total sum of the requests are really - spread over the various webservers.wwwN.foo.com
, all its + subsequent requests will continue to go to the same + IP (and thus a single server), rather than being + distributed across the other available servers. But the + overall result is + okay because the requests are collectively + spread over the various web servers.- @@ -651,8 +649,8 @@ www IN CNAME www0.foo.com. load-balancing is to use the program
@@ -670,8 +668,8 @@ www IN CNAME www0.foo.com.lbnamed
which can be found at http://www.stanford.edu/~schemers/docs/lbnamed/lbnamed.html. - It is a Perl 5 program in conjunction with auxilliary - tools which provides a real load-balancing for + It is a Perl 5 program which, in conjunction with auxilliary + tools, provides real load-balancing via DNS.entry in the DNS. Then we convert
www0.foo.com
to a proxy-only server, - i.e. we configure this machine so all arriving URLs - are just pushed through the internal proxy to one of + i.e., we configure this machine so all arriving URLs + are simply passed through its internal proxy to one of the 5 other servers (www1-www5
). To accomplish this we first establish a ruleset which contacts a load balancing scriptlb.pl
@@ -712,19 +710,23 @@ while (<STDIN>) {www0.foo.com
still is overloaded? The answer is yes, it is overloaded, but with plain proxy throughput requests, only! All SSI, CGI, ePerl, etc. - processing is completely done on the other machines. - This is the essential point.- - Hardware/TCP Round-Robin - -
There is a hardware solution available, too. Cisco - has a beast called LocalDirector which does a load - balancing at the TCP/IP level. Actually this is some - sort of a circuit level gateway in front of a - webcluster. If you have enough money and really need - a solution with high performance, use this one.
+ Dedicated Load Balancers + +There are more sophisticated solutions, as well. Cisco, + F5, and several other companies sell hardware load + balancers (typically used in pairs for redundancy), which + offer sophisticated load balancing and auto-failover + features. There are software packages which offer similar + features on commodity hardware, as well. If you have + enough money or need, check these out. The lb-l mailing list is a + good place to research.
- Description:
- -
On the net there are a lot of nifty CGI programs. But - their usage is usually boring, so a lot of webmaster +
On the net there are many nifty CGI programs. But + their usage is usually boring, so a lot of webmasters don't use them. Even Apache's Action handler feature for MIME-types is only appropriate when the CGI programs don't need special URLs (actually
@@ -763,12 +765,12 @@ RewriteRule ^/[uge]/([^/]+)/\.www/(.+)\.scgi(.*) ...PATH_INFO
@@ -749,10 +751,10 @@ while (<STDIN>) { let us configure a new file type with extension.scgi
(for secure CGI) which will be processed by the popularcgiwrap
program. The problem - here is that for instance we use a Homogeneous URL Layout - (see above) a file inside the user homedirs has the URL -/u/user/foo/bar.scgi
. But -cgiwrap
needs the URL in the form + here is that for instance if we use a Homogeneous URL Layout + (see above) a file inside the user homedirs might have a URL + like/u/user/foo/bar.scgi
, but +cgiwrap
needs URLs in the form/~user/foo/bar.scgi/
. The following rule solves the problem:Or assume we have some more nifty programs:
@@ -776,10 +778,10 @@ RewriteRule ^/[uge]/([^/]+)/\.www/(.+)\.scgi(.*) ... /internal/cgi/user/swwidx?i=/u/user/foo/wwwlog
(which displays the -access.log
for a URL subtree and +access.log
for a URL subtree) andwwwidx
(which runs Glimpse on a URL subtree). We have to provide the URL area to these - programs so they know on which area they have to act on. - But usually this ugly, because they are all the times - still requested from that areas, i.e. typically we would + programs so they know which area they are really working with. + But usually this is complicated, because they may still be + requested by the alternate URL form, i.e., typically we would run theswwidx
program from within/u/user/foo/
via hyperlink towhich is ugly. Because we have to hard-code +
which is ugly, because we have to hard-code both the location of the area and the location of the CGI inside the - hyperlink. When we have to reorganize the area, we spend a + hyperlink. When we have to reorganize, we spend a lot of time changing the various hyperlinks.
@@ -825,12 +827,12 @@ HREF="*"- @@ -844,16 +846,16 @@ RewriteCond %{REQUEST_FILENAME} !-s RewriteRule ^page\.html$ page.cgi [T=application/x-httpd-cgi,L]
Here comes a really esoteric feature: Dynamically - generated but statically served pages, i.e. pages should be + generated but statically served pages, i.e., pages should be delivered as pure static pages (read from the filesystem and just passed through), but they have to be generated - dynamically by the webserver if missing. This way you can - have CGI-generated pages which are statically served unless - one (or a cronjob) removes the static contents. Then the + dynamically by the web server if missing. This way you can + have CGI-generated pages which are statically served unless an + admin (or a
cron
job) removes the static contents. Then the contents gets refreshed.
Here a request to page.html
leads to a
+
Here a request for page.html
leads to an
internal run of a corresponding page.cgi
if
- page.html
is still missing or has filesize
+ page.html
is missing or has filesize
null. The trick here is that page.cgi
is a
- usual CGI script which (additionally to its STDOUT
)
+ CGI script which (additionally to its STDOUT
)
writes its output to the file page.html
.
- Once it was run, the server sends out the data of
+ Once it has completed, the server sends out
page.html
. When the webmaster wants to force
- a refresh the contents, he just removes
- page.html
(usually done by a cronjob).
page.html
(typically from cron
).
Wouldn't it be nice while creating a complex webpage if - the webbrowser would automatically refresh the page every - time we write a new version from within our editor? +
Wouldn't it be nice, while creating a complex web page, if + the web browser would automatically refresh the page every + time we save a new version from within our editor? Impossible?
No! We just combine the MIME multipart feature, the
- webserver NPH feature and the URL manipulation power of
+ web server NPH feature, and the URL manipulation power of
mod_rewrite
. First, we establish a new
URL feature: Adding just :refresh
to any
- URL causes this to be refreshed every time it gets
+ URL causes the 'page' to be refreshed every time it is
updated on the filesystem.
@@ -1020,18 +1022,17 @@ exit(0);
The <VirtualHost>
feature of Apache is nice
- and works great when you just have a few dozens
+ and works great when you just have a few dozen
virtual hosts. But when you are an ISP and have hundreds of
- virtual hosts to provide this feature is not the best
- choice.
To provide this feature we map the remote webpage or even
- the complete remote webarea to our namespace by the use
- of the Proxy Throughput feature (flag [P]
):
To provide this feature we map the remote web page or even
+ the complete remote web area to our namespace using the
+ Proxy Throughput feature (flag [P]
):
## @@ -1088,7 +1089,7 @@ RewriteCond ${lowercase:%{HTTP_HOST}|NONE} ^(.+)$ RewriteCond ${vhost:%1} ^(/.*)$ # # 5. finally we can map the URL to its docroot location -# and remember the virtual host for logging puposes +# and remember the virtual host for logging purposes RewriteRule ^/(.*)$ %1/$1 [E=VHOST:${lowercase:%{HTTP_HOST}}] :
We first have to make sure mod_rewrite
is below(!) mod_proxy
in the Configuration
- file when compiling the Apache webserver. This way it gets
+ file when compiling the Apache web server. This way it gets
called before mod_proxy
. Then we
configure the following for a host-dependent deny...
Sometimes a very special authentication is needed, for - instance a authentication which checks for a set of +
Sometimes very special authentication is needed, for
+ instance authentication which checks for a set of
explicitly configured users. Only these should receive
access and without explicit prompting (which would occur
- when using the Basic Auth via mod_auth
).
mod_auth
).
Available Languages: en | es | ja | - ko
+ ko | + trDirectives in the configuration files may apply to the
entire server, or they may be restricted to apply only to particular
@@ -448,7 +449,8 @@ Deny from badguy.example.com
Available Languages: en | es | ja | - ko
+ ko | + trIdiomas disponibles: en | es | ja | - ko
+ ko | + tr Las directivas presentes en los ficheros de configuración pueden ser
de aplicación para todo el servidor, o puede que su
@@ -483,7 +484,8 @@ Deny from badguy.example.com
Idiomas disponibles: en | es | ja | - ko
+ ko | + trAvailable Languages: en | es | ja | - ko
+ ko | + trAvailable Languages: en | es | ja | - ko
+ ko | + tr°¡´ÉÇÑ ¾ð¾î: en | es | ja | - ko
+ ko | + tr°¡´ÉÇÑ ¾ð¾î: en | es | ja | - ko
+ ko | + tr diff --git a/docs/manual/sections.html.tr.utf8 b/docs/manual/sections.html.tr.utf8 index c9c8aa71987..774ee700712 100644 --- a/docs/manual/sections.html.tr.utf8 +++ b/docs/manual/sections.html.tr.utf8 @@ -1,472 +1,472 @@ - - - -Apache HTTP Sunucusu Sürüm 2.0
-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.
İlgili Modüller | İlgili Yönergeler |
---|---|
İ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.
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.
<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>
-
<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>
-
<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>
-
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.
<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.
<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>
-
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:
AllowOverride
yönergesi sadece
-<Directory>
bölümlerinde çalıÅır.Options
yönergesinin
-FollowSymLinks
ve SymLinksIfOwnerMatch
seçenekleri
-sadece <Directory>
-bölümlerinde veya .htaccess
dosyalarında çalıÅır.Options
yönergesi
-<Files>
ve
-<FilesMatch>
-bölümlerinde kullanılamaz.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:
- -<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).<DirectoryMatch>
- (ve <Directory ~>
).<Files>
ve <FilesMatch>
aynı anda iÅleme sokulur.<Location>
- ve <LocationMatch>
- aynı anda iÅleme sokulur.<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.
- -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.
-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>
-
Apache HTTP Sunucusu Sürüm 2.0
+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.
İlgili Modüller | İlgili Yönergeler |
---|---|
İ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.
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.
<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>
+
<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>
+
<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>
+
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.
<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.
<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>
+
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:
AllowOverride
yönergesi sadece
+<Directory>
bölümlerinde çalıÅır.Options
yönergesinin
+FollowSymLinks
ve SymLinksIfOwnerMatch
seçenekleri
+sadece <Directory>
+bölümlerinde veya .htaccess
dosyalarında çalıÅır.Options
yönergesi
+<Files>
ve
+<FilesMatch>
+bölümlerinde kullanılamaz.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:
+ +<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).<DirectoryMatch>
+ (ve <Directory ~>
).<Files>
ve <FilesMatch>
aynı anda iÅleme sokulur.<Location>
+ ve <LocationMatch>
+ aynı anda iÅleme sokulur.<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.
+ +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.
+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>
+
This document covers stopping and restarting Apache on @@ -226,7 +227,8 @@ error. See above for a method of avoiding this. es | ja | ko | - ru
+ ru | + tr diff --git a/docs/manual/stopping.html.es b/docs/manual/stopping.html.es index 0e8953c2972..45524f7f83d 100644 --- a/docs/manual/stopping.html.es +++ b/docs/manual/stopping.html.es @@ -23,7 +23,8 @@ es | ja | ko | - ru + ru | + trApache HTTP Sunucusu Sürüm 2.0
-Bu belge Apache HTTPdânin Unix benzeri sistemlerde durdurulması ve - yeniden baÅlatılması konularını kapsar. Windows NT, 2000 ve XP - kullanıcıları Apache HTTPdâyi bu platformlarda nasıl denetimlerine - alacaklarını öÄrenmek için Apache - HTTPdânin Bir Hizmet Olarak ÃalıÅtırılması sayfasına, Windows 9x ve - ME kullanıcıları ise Apache - HTTPdânin Bir Konsol Uygulaması Olarak ÃalıÅtırılması sayfasına - bakabilirler.
-Apache HTTPdâyi durdurmak ve yeniden baÅlatmak için çalıÅan
- httpd
süreçlerine bir sinyal göndermeniz gerekir.
- Sinyal göndermek için iki yol vardır. İlki, süreçlere doÄrudan sinyal
- göndermek için unix kill
komutunun kullanımıdır. Bu
- suretle, sisteminizde çalıÅmakta olan bir çok httpd
- sürecini uyarabilirsiniz ama süreç kimliÄi PidFile
yönergesi ile belirtilen dosyada
- tutulan ana süreç dıÅında hiçbirine sinyal göndermemelisiniz. BaÅka
- bir deyiÅle, ana süreç haricinde hiçbir sürece sinyal göndermeye normal
- olarak ihtiyacınız olmaması gerekir. Ana sürece gönderebileceÄiniz
- üç çeÅit sinyal vardır:
- TERM
,
- HUP
ve
- USR1
. Bunlar yeri geldikçe
- açıklanacaktır.
Ana sürece kill
ile sinyal göndermek için Åöyle bir
- komut verebilirsiniz:
kill -TERM `cat /usr/local/apache2/logs/httpd.pid`
httpd
süreçlerine sinyal göndermenin ikinci yolu
- -k
komut satırı seçeneÄini Åu deÄerlerden biri ile
- kullanmaktır: stop
, restart
ve
- graceful
. Bunlar aÅaÄıda açıklanacaktır.
- -k
komut satırı seçeneÄi
- httpd
âye ait olsa da ana sürece bu sinyalleri
- göndermek için apachectl
betiÄini kullanmanızı
- öneririz. apachectl
, komut satırı seçeneklerini
- httpd
âye aktaracaktır.
httpd
âye sinyal gönderdikten sonra olup biteni Åu
- komutla izleyebilirsiniz:
tail -f /usr/local/apache2/logs/error_log
Bu örnekleri, kendi ServerRoot
ve
- PidFile
yönergelerinizdeki
- ayarlara uygun olarak deÄiÅtirdikten sonra kullanınız.
apachectl -k stop
Ana sürece TERM
veya stop
sinyali
- göndererek tüm çocukların bir an önce öldürülmeye çalıÅılmasını saÄlamıÅ
- olursunuz. Tüm çocukların öldürülmesi bir kaç saniye sürebilir. Son
- olarak ana süreç çıkacaktır. Yanıtlanmakta olan istekler hemen
- sonlandırılacak ve artık isteklere yanıt verilmeyecektir.
apachectl -k graceful
Ana sürece USR1
veya graceful
sinyalinin
- gönderilmesi, çocuklara ellerindeki mevcut iÅleri bitirdikten sonra
- (veya sundukları bir Åey yoksa hemen) çıkmalarının önerilmesi
- demektir. Ana süreç kendi yapılandırma dosyalarını yeniden okur ve
- kendi günlük dosyalarını yeniden açar. Ana sürecin öldürdüÄü her sürecin
- yerine yeni yapılandırma kuÅaÄından bir süreç baÅlatır ve hemen
- yeni isteklere hizmet sunulmaya baÅlanır.
USR1
sinyalinin kullanılmasına izin verilmez. Bu gibi
- durumlarda, WINCH
gibi baÅka bir sinyal kullanılabilir.
- apachectl graceful
komutu platformunuz için doÄru sinyali
- gönderecektir.Bu kod MPMâlerin süreçleri denetleyen yönergelerine daima uyacak
- Åekilde tasarlanmıÅtır. Bu suretle, istemcilere hizmet sunacak çocuk
- süreçler ve evreler, yeniden baÅlatma iÅleminde de uygun sayıda
- saÄlanmıŠolur. Bununla birlikte, StartServers
yönergesinde Åöyle
- davranılır: İlk saniye içinde en azından StartServers
sayıda yeni çocuk
- oluÅturulmamıÅsa iÅ olmayan bir devreyi geçiÅtirecek kadarı oluÅturulur.
- Ardından sunucunun mevcut yükünü karÅılamak için gereken sayıda çocuk
- süreç oluÅturulur. Bu suretle, kod her ikisi için de gereÄini yerine
- getirmeye çalıÅmıŠolur.
mod_status
kullanıcıları USR1
- gönderildiÄi zaman sunucu istatistiklerinin sıfırlanmadıÄı konusunda
- uyarılacaktır. Kod, sunucunun yeni isteklere yanıt veremediÄi zamanı en
- aza indirmenin yanısıra ayar parametrelerinize de uymak üzere
- tasarlanmıÅtır (yeni istekler iÅletim sistemi tarafından kuyruÄa
- alınacaÄından bir istek kaybı olayı yaÅanmaz). Bunu saÄlamak için, her
- iki kuÅaÄın çocuklarının izini sürecek bir çetele tutulur.
mod_status
modülü, nazikçe yeniden baÅlat komutunun
- verilmesinden önce baÅlamıŠve sunulmaya devam eden isteklere bakan
- çocukları imlemek için ayrıca bir G
(Gracefulâun baÅ harfi)
- kullanır.
Günlük dosyası döndürme betiÄine, yeniden baÅlatma öncesi günlüÄe yazan
- tüm çocukların iÅini bitirdiÄini USR1
kullanarak
- bildirmenin bir yolu yoktur. Ãnerimiz, eski günlük kaydı üzerinde bir
- iÅlem yapmaya baÅlamadan önce USR1
sinyali gönderilmesinin
- ardından belli bir süre beklenilmesi olacaktır. ÃrneÄin, düÅük band
- geniÅliÄine sahip istemcilere hizmet sunan çoÄu sürecin iÅinin 10
- dakikadan önce bitmeyeceÄini gözönüne alarak eski günlük üzerinde iÅlem
- yapmaya baÅlamak için 15 dakika beklenebilir.
-t
komut satırı seçeneÄi ile sınayabilirsiniz (bkz,
- httpd
). Ancak, bu hala sunucunuzun düzgünce yeniden
- baÅlatılmasını garanti etmeyecektir. Yapılandırma dosyalarınızı
- sözdizimi denetiminin yanında anlamlandırılması bakımından da sınamak
- için httpd
ânin root olmayan bir kullanıcı tarafından
- çalıÅtırılmasını deneyebilirsiniz. EÄer yapılandırma dosyalarında bir
- hata yoksa soketleri ve günlük dosyalarını açmaya çalıÅırken root
- aidiyetinde çalıÅmadıÄından veya çalıÅmakta olan asıl sunucu bu portları
- zaten dinlediÄinden baÅarısız olacaktır. EÄer baÅka bir sebeple
- baÅarısız olursa olası sebep bir yapılandırma dosyası hatasıdır ve asıl
- sunucuya ânazikçe yeniden baÅlaâ komutunu vermeden önce bu hatayı
- düzeltmeniz gerekir.apachectl -k restart
Ana sürece HUP
veya restart
sinyalinin
- gönderilmesi tüm çocukların TERM
sinyali gönderilmiŠgibi
- öldürülmesine sebep olur fakat ana sürecin çıkmasını saÄlamaz.
- Ana süreç yapılandırma dosyalarını yeniden okur ve günlük kayıt
- dosyalarını yeniden açar. Bunların ardından isteklere yanıt verecek yeni
- kuÅak çocukları oluÅturmaya baÅlar.
mod_status
kullanıcıları bir HUP
sinyali
- gönderildiÄinde sunucu istatistiklerinin sıfırlandıÄı konusunda
- uyarılırlar.
Apache 1.2b9 sürümü öncesinde, yeniden baÅlatma ve ölüm sinyalleri ile - ilgili olarak ortaya çıkan çeÅitli yarıŠkoÅulları vardı. (Basitçe, bir - yarıŠkoÅulu zamanlama ile ilgili bir sorundur; yanlıŠzamanda veya - yanlıŠsırada oluÅan bir Åey istenmeyen sonuçlara yol açarken, aynı Åey - doÄru zaman ve doÄru sırada oluÅtuÄunda herÅey yolunda gider.) Bu tür - mimarilerde elimizden geldiÄi kadar bu sorunları giderecek doÄru - özellikleri kullanmaya gayret etsek de belli mimarilerde hala yarıŠ- koÅullarının ortaya çıkma olasılıÄı bulunduÄunu belirtmek gerekir.
- -Disk üzerinde ScoreBoardFile
dosyası tutan mimarilerde
- çetele bozulması olasılıÄı gündeme gelebilir. Bu durum, "bind:
- Address already in use" (HUP
sonrası) veya "long lost
- child came home!" (USR1
sonrası) iletileriyle
- sonuçlanabilir. İkincisi sadece çetele kaybına sebep olurken birincisi
- ölümcül bir hatadır. Bu bakımdan, normalde nazikçe yeniden baÅlatma
- kullanıp ara sıra normal yeniden baÅlatma yapılması önerilebilir. Bu
- sorunları kitabına uydurmak çok zordur fakat Åans eseri çoÄu mimari bir
- çetele dosyası gerektirmemektedir. Ãetele dosyası kullanan mimariler
- için ScoreBoardFile
belgesine
- bakınız.
Kalıcı HTTP baÄlantısı (KeepAlive) üzerinden ikinci ve sonraki - isteklerle ilgili olarak her çocuk süreçte bir yarıŠkoÅulu oluÅma - olasılıÄı küçük de olsa bütün mimarilerde vardır. İstek satırı - okunduktan sonra hiçbir istek baÅlıÄı okunmadan çıkabilir. Bu durum 1.2 - sürümünde geç de olsa farkedilmiÅ ve düzeltme yoluna gidilmiÅtir. Teorik - olarak, aÄ gecikmeleri ve sunucu zaman aÅımları nedeniyle KeepAlive - istemcisi açısından bu olaylar beklenmediÄinden, bu önemli bir konu - deÄildir. Uygulamada ise, ne sunucuyu ne de istemciyi etkilediÄi - görülmez; bir deneme ortamında sunucu saniyede 20 kere yeniden - baÅlatılmıŠve istemciler boÅ belge veya bozuk resim almadan siteyi - baÅarıyla gezmiÅlerdir.
-Apache HTTP Sunucusu Sürüm 2.0
+Bu belge Apache HTTPdânin Unix benzeri sistemlerde durdurulması ve + yeniden baÅlatılması konularını kapsar. Windows NT, 2000 ve XP + kullanıcıları Apache HTTPdâyi bu platformlarda nasıl denetimlerine + alacaklarını öÄrenmek için Apache + HTTPdânin Bir Hizmet Olarak ÃalıÅtırılması sayfasına, Windows 9x ve + ME kullanıcıları ise Apache + HTTPdânin Bir Konsol Uygulaması Olarak ÃalıÅtırılması sayfasına + bakabilirler.
+Apache HTTPdâyi durdurmak ve yeniden baÅlatmak için çalıÅan
+ httpd
süreçlerine bir sinyal göndermeniz gerekir.
+ Sinyal göndermek için iki yol vardır. İlki, süreçlere doÄrudan sinyal
+ göndermek için unix kill
komutunun kullanımıdır. Bu
+ suretle, sisteminizde çalıÅmakta olan bir çok httpd
+ sürecini uyarabilirsiniz ama süreç kimliÄi PidFile
yönergesi ile belirtilen dosyada
+ tutulan ana süreç dıÅında hiçbirine sinyal göndermemelisiniz. BaÅka
+ bir deyiÅle, ana süreç haricinde hiçbir sürece sinyal göndermeye normal
+ olarak ihtiyacınız olmaması gerekir. Ana sürece gönderebileceÄiniz
+ üç çeÅit sinyal vardır:
+ TERM
,
+ HUP
ve
+ USR1
. Bunlar yeri geldikçe
+ açıklanacaktır.
Ana sürece kill
ile sinyal göndermek için Åöyle bir
+ komut verebilirsiniz:
kill -TERM `cat /usr/local/apache2/logs/httpd.pid`
httpd
süreçlerine sinyal göndermenin ikinci yolu
+ -k
komut satırı seçeneÄini Åu deÄerlerden biri ile
+ kullanmaktır: stop
, restart
ve
+ graceful
. Bunlar aÅaÄıda açıklanacaktır.
+ -k
komut satırı seçeneÄi
+ httpd
âye ait olsa da ana sürece bu sinyalleri
+ göndermek için apachectl
betiÄini kullanmanızı
+ öneririz. apachectl
, komut satırı seçeneklerini
+ httpd
âye aktaracaktır.
httpd
âye sinyal gönderdikten sonra olup biteni Åu
+ komutla izleyebilirsiniz:
tail -f /usr/local/apache2/logs/error_log
Bu örnekleri, kendi ServerRoot
ve
+ PidFile
yönergelerinizdeki
+ ayarlara uygun olarak deÄiÅtirdikten sonra kullanınız.
apachectl -k stop
Ana sürece TERM
veya stop
sinyali
+ göndererek tüm çocukların bir an önce öldürülmeye çalıÅılmasını saÄlamıÅ
+ olursunuz. Tüm çocukların öldürülmesi bir kaç saniye sürebilir. Son
+ olarak ana süreç çıkacaktır. Yanıtlanmakta olan istekler hemen
+ sonlandırılacak ve artık isteklere yanıt verilmeyecektir.
apachectl -k graceful
Ana sürece USR1
veya graceful
sinyalinin
+ gönderilmesi, çocuklara ellerindeki mevcut iÅleri bitirdikten sonra
+ (veya sundukları bir Åey yoksa hemen) çıkmalarının önerilmesi
+ demektir. Ana süreç kendi yapılandırma dosyalarını yeniden okur ve
+ kendi günlük dosyalarını yeniden açar. Ana sürecin öldürdüÄü her sürecin
+ yerine yeni yapılandırma kuÅaÄından bir süreç baÅlatır ve hemen
+ yeni isteklere hizmet sunulmaya baÅlanır.
USR1
sinyalinin kullanılmasına izin verilmez. Bu gibi
+ durumlarda, WINCH
gibi baÅka bir sinyal kullanılabilir.
+ apachectl graceful
komutu platformunuz için doÄru sinyali
+ gönderecektir.Bu kod MPMâlerin süreçleri denetleyen yönergelerine daima uyacak
+ Åekilde tasarlanmıÅtır. Bu suretle, istemcilere hizmet sunacak çocuk
+ süreçler ve evreler, yeniden baÅlatma iÅleminde de uygun sayıda
+ saÄlanmıŠolur. Bununla birlikte, StartServers
yönergesinde Åöyle
+ davranılır: İlk saniye içinde en azından StartServers
sayıda yeni çocuk
+ oluÅturulmamıÅsa iÅ olmayan bir devreyi geçiÅtirecek kadarı oluÅturulur.
+ Ardından sunucunun mevcut yükünü karÅılamak için gereken sayıda çocuk
+ süreç oluÅturulur. Bu suretle, kod her ikisi için de gereÄini yerine
+ getirmeye çalıÅmıŠolur.
mod_status
kullanıcıları USR1
+ gönderildiÄi zaman sunucu istatistiklerinin sıfırlanmadıÄı konusunda
+ uyarılacaktır. Kod, sunucunun yeni isteklere yanıt veremediÄi zamanı en
+ aza indirmenin yanısıra ayar parametrelerinize de uymak üzere
+ tasarlanmıÅtır (yeni istekler iÅletim sistemi tarafından kuyruÄa
+ alınacaÄından bir istek kaybı olayı yaÅanmaz). Bunu saÄlamak için, her
+ iki kuÅaÄın çocuklarının izini sürecek bir çetele tutulur.
mod_status
modülü, nazikçe yeniden baÅlat komutunun
+ verilmesinden önce baÅlamıŠve sunulmaya devam eden isteklere bakan
+ çocukları imlemek için ayrıca bir G
(Gracefulâun baÅ harfi)
+ kullanır.
Günlük dosyası döndürme betiÄine, yeniden baÅlatma öncesi günlüÄe yazan
+ tüm çocukların iÅini bitirdiÄini USR1
kullanarak
+ bildirmenin bir yolu yoktur. Ãnerimiz, eski günlük kaydı üzerinde bir
+ iÅlem yapmaya baÅlamadan önce USR1
sinyali gönderilmesinin
+ ardından belli bir süre beklenilmesi olacaktır. ÃrneÄin, düÅük band
+ geniÅliÄine sahip istemcilere hizmet sunan çoÄu sürecin iÅinin 10
+ dakikadan önce bitmeyeceÄini gözönüne alarak eski günlük üzerinde iÅlem
+ yapmaya baÅlamak için 15 dakika beklenebilir.
-t
komut satırı seçeneÄi ile sınayabilirsiniz (bkz,
+ httpd
). Ancak, bu hala sunucunuzun düzgünce yeniden
+ baÅlatılmasını garanti etmeyecektir. Yapılandırma dosyalarınızı
+ sözdizimi denetiminin yanında anlamlandırılması bakımından da sınamak
+ için httpd
ânin root olmayan bir kullanıcı tarafından
+ çalıÅtırılmasını deneyebilirsiniz. EÄer yapılandırma dosyalarında bir
+ hata yoksa soketleri ve günlük dosyalarını açmaya çalıÅırken root
+ aidiyetinde çalıÅmadıÄından veya çalıÅmakta olan asıl sunucu bu portları
+ zaten dinlediÄinden baÅarısız olacaktır. EÄer baÅka bir sebeple
+ baÅarısız olursa olası sebep bir yapılandırma dosyası hatasıdır ve asıl
+ sunucuya ânazikçe yeniden baÅlaâ komutunu vermeden önce bu hatayı
+ düzeltmeniz gerekir.apachectl -k restart
Ana sürece HUP
veya restart
sinyalinin
+ gönderilmesi tüm çocukların TERM
sinyali gönderilmiŠgibi
+ öldürülmesine sebep olur fakat ana sürecin çıkmasını saÄlamaz.
+ Ana süreç yapılandırma dosyalarını yeniden okur ve günlük kayıt
+ dosyalarını yeniden açar. Bunların ardından isteklere yanıt verecek yeni
+ kuÅak çocukları oluÅturmaya baÅlar.
mod_status
kullanıcıları bir HUP
sinyali
+ gönderildiÄinde sunucu istatistiklerinin sıfırlandıÄı konusunda
+ uyarılırlar.
Apache 1.2b9 sürümü öncesinde, yeniden baÅlatma ve ölüm sinyalleri ile + ilgili olarak ortaya çıkan çeÅitli yarıŠkoÅulları vardı. (Basitçe, bir + yarıŠkoÅulu zamanlama ile ilgili bir sorundur; yanlıŠzamanda veya + yanlıŠsırada oluÅan bir Åey istenmeyen sonuçlara yol açarken, aynı Åey + doÄru zaman ve doÄru sırada oluÅtuÄunda herÅey yolunda gider.) Bu tür + mimarilerde elimizden geldiÄi kadar bu sorunları giderecek doÄru + özellikleri kullanmaya gayret etsek de belli mimarilerde hala yarıŠ+ koÅullarının ortaya çıkma olasılıÄı bulunduÄunu belirtmek gerekir.
+ +Disk üzerinde ScoreBoardFile
dosyası tutan mimarilerde
+ çetele bozulması olasılıÄı gündeme gelebilir. Bu durum, "bind:
+ Address already in use" (HUP
sonrası) veya "long lost
+ child came home!" (USR1
sonrası) iletileriyle
+ sonuçlanabilir. İkincisi sadece çetele kaybına sebep olurken birincisi
+ ölümcül bir hatadır. Bu bakımdan, normalde nazikçe yeniden baÅlatma
+ kullanıp ara sıra normal yeniden baÅlatma yapılması önerilebilir. Bu
+ sorunları kitabına uydurmak çok zordur fakat Åans eseri çoÄu mimari bir
+ çetele dosyası gerektirmemektedir. Ãetele dosyası kullanan mimariler
+ için ScoreBoardFile
belgesine
+ bakınız.
Kalıcı HTTP baÄlantısı (KeepAlive) üzerinden ikinci ve sonraki + isteklerle ilgili olarak her çocuk süreçte bir yarıŠkoÅulu oluÅma + olasılıÄı küçük de olsa bütün mimarilerde vardır. İstek satırı + okunduktan sonra hiçbir istek baÅlıÄı okunmadan çıkabilir. Bu durum 1.2 + sürümünde geç de olsa farkedilmiÅ ve düzeltme yoluna gidilmiÅtir. Teorik + olarak, aÄ gecikmeleri ve sunucu zaman aÅımları nedeniyle KeepAlive + istemcisi açısından bu olaylar beklenmediÄinden, bu önemli bir konu + deÄildir. Uygulamada ise, ne sunucuyu ne de istemciyi etkilediÄi + görülmez; bir deneme ortamında sunucu saniyede 20 kere yeniden + baÅlatılmıŠve istemciler boÅ belge veya bozuk resim almadan siteyi + baÅarıyla gezmiÅlerdir.
+