New Turkish translation

<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">

<?xml-stylesheet type="text/xsl" href="./style/manual.tr.xsl"?>

<!-- English Revision: 558686 -->

<!-- =====================================================

 Translated by: Nilgün Belma Bugüner <nilgun belgeler.org>

   Reviewed by: Orhan Berent <berent belgeler.org>

========================================================== -->

<!--

 Licensed to the Apache Software Foundation (ASF) under one or more

 contributor license agreements.  See the NOTICE file distributed with

 this work for additional information regarding copyright ownership.

 The ASF licenses this file to You under the Apache License, Version 2.0

 (the "License"); you may not use this file except in compliance with

 the License.  You may obtain a copy of the License at

     http://www.apache.org/licenses/LICENSE-2.0

 Unless required by applicable law or agreed to in writing, software

 distributed under the License is distributed on an "AS IS" BASIS,

 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

 See the License for the specific language governing permissions and

 limitations under the License.

-->

<manualpage metafile="custom-error.xml.meta">

  <title>Hata Yanıtlarının Kişiselleştirilmesi</title>

  <summary>

    <p>Apache, bazı sorunlara ve hatalara karşılık vereceği yanıtların

      yapılandırabilmesini mümkün kılan ek bir işlevselliğe sahiptir.</p>

    <p>Site yöneticisi tarafından kişiselleştirilebilen bu tür yanıtlar,

      sunucu belli hatalar veya sorunlarla karşılaştığında etkin kılınmak

      üzere tanımlanabilir.</p>

    <p>Bir betik bir hata nedeniyle bir "500 Server Error" yanıtının

      verilmesine sebep olursa bu yanıt yerine başka bir adrese

      yönlendirilerek (dahili veya harici) veya doğrudan daha dostça bir

      metin sunulabilir.</p>

  </summary>

  <section id="behavior">

    <title>Davranış</title>

    <section>

      <title>Eski Davranış</title>

      <p>NCSA httpd 1.3, çoğunlukla kullanıcıya anlamsız gelen ve sebebiyle

        kavramsal bir bağ kurulamayan günlük kayıtları üreten, can sıkıcı

        bazı hata/sorun yanıtları döndürürdü.</p>

    </section>

    <section>

      <title>Yeni Davranış</title>

      <p>Sunucudan NCSA kodlu iletiler yerine</p>

      <ul>

        <li>başka bir metin göstermesi,</li>

        <li>istemciyi başka bir yerel adrese yönlendirmesi veya</li>

        <li>istemciyi bir harici adrese yönlendirmesi</li>

      </ul>

      <p>istenebilir. Başka bir adrese yönlendirme, hata veya sorunu daha iyi

        açıklamakta kullanılabilecek bazı bilgilerin aktarılması şartıyla

        oldukça kullanışlı olabilir.</p>

      <p>Apache, buna olanak vermek için CGI benzeri yeni ortam değişkenleri

        tanımlamıştır:</p>

      <example>

        REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/x-xbitmap,

            image/jpeg<br />

        REDIRECT_HTTP_USER_AGENT=Mozilla/1.1b2 (X11; I; HP-UX A.09.05

            9000/712)<br />

        REDIRECT_PATH=.:/bin:/usr/local/bin:/etc<br />

        REDIRECT_QUERY_STRING=<br />

        REDIRECT_REMOTE_ADDR=121.345.78.123<br />

        REDIRECT_REMOTE_HOST=ooh.ahhh.dom<br />

        REDIRECT_SERVER_NAME=batti.balik.yan.gider.edu<br />

        REDIRECT_SERVER_PORT=80<br />

        REDIRECT_SERVER_SOFTWARE=Apache/0.8.15<br />

        REDIRECT_URL=/cgi-bin/hatalar.pl

      </example>

      <p><code>REDIRECT_</code> önekine dikkat edin.</p>

      <p>Yeni adrese (hedefin bir CGI betiği veya SSI sayfası olduğu

        kabulüyle) en azından <code>REDIRECT_URL</code> ve

        <code>REDIRECT_QUERY_STRING</code> değişkenleri aktarılır. Diğer

        değişkenler ise sadece hata veya sorunun öncesinde mevcut oldukları

        takdirde aktarılacaklardır. Eğer <em>harici</em> yönlendirmeyi

        <directive module="core">ErrorDocument</directive> yönergesi

        üzerinden yapıyorsanız bunlara <strong>None</strong> değeri

        atanacaktır. (Yönlendirme adresi <code>http:</code> ile başlıyorsa

        adres aynı sunucuya ait olsa bile bu bir harici yönlendirme olarak

        ele alınır.)</p>

    </section>

  </section>

  <section id="configuration">

    <title>Yapılandırma</title>

    <p><directive module="core">ErrorDocument</directive> yönergesinin

      <code>.htaccess</code> dosyalarında kullanılması sadece <directive

      module="core">AllowOverride</directive> yönergesine uygun bir değer

      atanmışsa mümkündür.</p>

    <p>Bazı örnekler:</p>

    <example>

      ErrorDocument 500 /cgi-bin/hata-kurtarma <br />

      ErrorDocument 500 "Pardon, galiba bizim betik hata verdi." <br />

      ErrorDocument 500 http://xxx/ <br />

      ErrorDocument 404 /ozuru_kabahatinden_buyuk/yok.html <br />

      ErrorDocument 401 /Uyeler/NASIL_uye_olunur.html

    </example>

    <p>Burada sözdizimi şöyledir:</p>

    <example>

      ErrorDocument <3-rakamlı-kod> <eylem>

    </example>

    <p><code><em>eylem</em></code> şunlardan biri olabilir:</p>

    <ul>

      <li>Gösterilecek metin. Metin tırnak (") içine alınmalıdır.</li>

      <li>Yönlendirmenin yapılacağı harici adres.</li>

      <li>Yönlendirmenin yapılacağı dahili adres.</li>

    </ul>

  </section>

  <section id="custom">

    <title>Özel Hata Yanıtları ve Yönlendirme</title>

    <p>Apache’nin yönlendirme ile ilgili davranışı bir CGI betiği veya SSI

      sayfası sözkonusu olduğunda bazı ek ortam değişkenleri ile

      yapılandırılabilir.</p>

    <section>

      <title>Eski Davranış</title>

      <p>Yönlendirme yapılan betikte standart CGI değişkenleri kullanılırdı.

        Yönlendirmenin kaynağı ile ilgili bir belirtiye rastlanmazdı.</p>

    </section>

    <section>

      <title>Yeni Davranış</title>

      <p>Yönlendirme yapılan betikte kullanılmak üzere özel olarak

        tanımlanmış ortam değişkenleri vardır. Her değişkenin ismi

        <code>REDIRECT_</code> ile başlar. <code>REDIRECT_</code> ortam

        değişkenleri, yönlendirme öncesinde tanımlanmış CGI ortam

        değişkenlerinin isimlerinin başına <code>REDIRECT_</code> öneki

        getirilerek oluşturulur. Yani, <code>HTTP_USER_AGENT</code> değişkeni

        <code>REDIRECT_HTTP_USER_AGENT</code> haline gelir. Bunlara ek

        olarak, betiğe olayın izini sürmekte yardımcı olması için

        <code>REDIRECT_URL</code> ve <code>REDIRECT_STATUS</code>

        değişkenleri tanımlanmıştır. Erişim günlüğüne özgün adresle birlikte

        yönlendirme adresi de kaydedilir.</p>

      <p>Eğer <directive module="core">ErrorDocument</directive> yönergesi

        bir yerel CGI betiğine yönlendirme belirtiyorsa, hatanın kaynağı

        hakkında istemciye bilgi vermek amacıyla betiğin çıktısında bir

        "<code>Status:</code>" başlık alanına yer verilmesi önerilir.

        Örneğin, bir Perl betiği şunları içerebilirdi:</p>

      <example>

        ... <br />

        print  "Content-type: text/html; charset=UTF-8\n"; <br />

        printf "Status: %s durumu saptandı.\n", $ENV{"REDIRECT_STATUS"}; <br />

        ...

      </example>

      <p>Eğer betik,  <code>404&nbsp;Not&nbsp;Found</code> gibi, belli bir

        hata durumunu ele almaya adanmışsa duruma özel kod ve hata metni

        kullanılabilir.</p>

      <p>Eğer yanıt, (istemci taraflı yönlendirme yapılırken) bir

        <code>Location:</code> başlığı da içeriyorsa betiğin çıktıya uygun

        bir <code>Status:</code> başlığı (<code>302&nbsp;Found</code> gibi)

        eklemesinin <em>gerekli</em> oluşuna dikkat ediniz. Aksi takdirde,

        <code>Location:</code> başlığı etkisiz olabilir.</p>

    </section>

  </section>

</manualpage>

<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">

<?xml-stylesheet type="text/xsl" href="./style/manual.tr.xsl"?>

<!-- English Revision: 507346 -->

<!-- =====================================================

 Translated by: Nilgün Belma Bugüner <nilgun belgeler.org>

   Reviewed by: Orhan Berent <berent belgeler.org>

========================================================== -->

<!--

 Licensed to the Apache Software Foundation (ASF) under one or more

 contributor license agreements.  See the NOTICE file distributed with

 this work for additional information regarding copyright ownership.

 The ASF licenses this file to You under the Apache License, Version 2.0

 (the "License"); you may not use this file except in compliance with

 the License.  You may obtain a copy of the License at

     http://www.apache.org/licenses/LICENSE-2.0

 Unless required by applicable law or agreed to in writing, software

 distributed under the License is distributed on an "AS IS" BASIS,

 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

 See the License for the specific language governing permissions and

 limitations under the License.

-->

<manualpage metafile="dns-caveats.xml.meta">

  <title>Apache ve DNS ile ilgili Konular</title>

  <summary>

    <p>Bu sayfanın konusu şöyle özetlenebilirdi: Yapılandırma dosyalarınızda

      DNS sorguları yapılmasını gerektirecek ayarlamalardan kaçınınız. Eğer

      yapılandırma dosyalarınızda DNS sorgusu yapılarak çözümlenebilecek

      adresler bulunursa sunucunuz beklenmedik davranışlar (hiç

      başlamayabilir) gösterebileceği gibi hizmet reddi veya hizmet

      hırsızlığı (bazı kullanıcıların diğerlerine giden sayfaları çalma

      olasılığı dahil) saldırılarına açık hale gelebilir.</p>

  </summary>

  <section id="example">

    <title>Basit Bir Örnek</title>

    <example>

      <VirtualHost falan.fesmekan.dom>

      <indent>

        ServerAdmin filanca@fesmekan.dom <br />

        DocumentRoot /siteler/fesmekan

      </indent>

      </VirtualHost>

    </example>

    <p>Apache’nin beklendiği gibi işlemesi için her sanal konak için iki

      veriye mutlaka ihtiyacı vardır: <directive module="core"

      >ServerName</directive> ve sunucunun bağlantı kabul edip hizmet

      sunacağı en az bir IP adresi. Yukarıdaki örnekte IP adresi

      bulunmamaktadır, dolayısıyla Apache, <code>falan.fesmekan.dom</code>

      adresi için bir DNS sorgusu yapmak zorundadır. Eğer sunucu,

      yapılandırma dosyasını çözümlediği sırada bir sebeple DNS sunucusuna

      erişemezse bu sanal konak <em>yapılandırılmayacak</em> (hApache 1.2

      öncesinde sunucu hiç başlatılmazdı) ve bu sanal konağa yapılan

      isteklere yanıt verilemeyecektir.</p>

    <p><code>falan.fesmekan.dom</code>’un 192.168.2.1 IP adresine sahip

      olduğunu varsayarsak yapılandırma şöyle olurdu:</p>

    <example>

      &lt;VirtualHost 192.168.2.1&gt; <br />

      <indent>

        ServerAdmin filanca@fesmekan.dom <br />

        DocumentRoot /siteler/fesmekan

      </indent>

      </VirtualHost>

    </example>

    <p>Ancak, bu sefer de bu sanal konağın sunucu ismini öğrenmek için

      Apache’nin bir ters DNS sorgusu yapması gerekecektir. Eğer bu sorgu

      başarısız olursa kısmi bir yapılandırmaya gidilir (Apache 1.2 öncesinde

      sunucu hiç başlatılmazdı). Eğer sanal konak isme dayalı ise sanal konak

      kısmen bile yapılandırılmaz. IP’ye dayalı sanal konaklar büyük oranda

      çalışır, fakat sunucu ismini içeren tam bir adres üretilmesini

      gerektiren bir durumda, sunucu geçerli bir adres üretemez.</p>

    <p>Her iki sorunu da çözen yapılandırma şöyle olurdu:</p>

    <example>

      &lt;VirtualHost 192.168.2.1&gt; <br />

      <indent>

        ServerName falan.fesmekan.dom <br />

        ServerAdmin filanca@fesmekan.dom <br />

        DocumentRoot /siteler/fesmekan

      </indent>

      </VirtualHost>

    </example>

  </section>

  <section id="denial">

    <title>Hizmet Reddi</title>

    <p>Hizmet reddinin meydana gelebilecek (en az) iki türü vardır.

      Apache’nin 1.2 öncesi bir sürümünü kullanıyorsanız sanal

      konaklarınızdan herhangi biri için yukarıdaki iki sorgudan biri

      başarısız olursa sunucunuzu asla başlatamazsınız. Bazı durumlarda, DNS

      sorgularından alınacak yanıtlar sizin denetiminizde olmayabilir;

      örneğin <code>fesmekan.dom</code> müşterilerinizden birine aitse ve

      kendi DNS sunucuları varsa <code>falan.fesmekan.dom</code> kaydını

      silerek sunucunuzun hiç başlatılamamasına (1.2 öncesi) sebep

      olabilirler.</p>

    <p>Diğer türü biraz daha sinsidir. Şöyle bir yapılandırmanız olsun:</p>

    <example>

      &lt;VirtualHost falan.fesmekan.dom&gt;<br />

      <indent>

        ServerAdmin filanca@fesmekan.dom <br />

        DocumentRoot /siteler/fesmekan

      </indent>

      &lt;/VirtualHost&gt;<br />

      <br />

      &lt;VirtualHost misal.mesela.dom&gt;<br />

      <indent>

        ServerAdmin falanca@mesela.dom<br />

        DocumentRoot /siteler/mesela<br />

      </indent>

      </VirtualHost>

    </example>

    <p><code>falan.fesmekan.dom</code>’a 192.168.2.1,

      <code>misal.mesela.dom</code>’a 192.168.2.2 atadığınızı fakat,

      <code>mesela.dom</code>’un DNS kaydının sizin denetiminizde olmadığını

      varsayalım. Bu yapılandırmayla, <code>mesela.dom</code>’u

      <code>fesmekan.dom</code>’a giden tüm trafiği çalabilecek duruma

      getirirsiniz. Bunu gerçekleştirmek için DNS kaydında

      <code>misal.mesela.dom</code>’a 192.168.2.1 adresinin atanması

      yeterlidir. Kendi DNS’lerine sahip olduklarından dolayı

      <code>misal.mesela.dom</code>’a istedikleri IP adresini atamaktan

      onları alıkoyamazsınız.</p>

    <p>192.168.2.1’e gelen isteklerin hepsine

      (<code>http://falan.fesmekan.dom/biryer</code> şeklinde yazılan

      adresler dahil) <code>mesela.dom</code> sanal konağınca hizmet

      sunulacaktır. Apache’nin gelen istekleri sunduğu sanal konaklarla nasıl

      eşleştirdiğini bilirseniz bunun sebebini kolayca anlarsınız. Bunu

      kabataslak açıklayan  <a href="vhosts/details.html">bir belgemiz

      mevcuttur</a>.</p>

  </section>

  <section id="main">

    <title>"Ana Sunucu" Adresi</title>

    <p>Apache 1.1’de <a href="vhosts/name-based.html">isme dayalı sanal konak

      desteği</a>ne ek olarak, Apache’nin, <program>httpd</program>’nin

      çalıştığı makinenin IP adres(ler)ini de bilmeye ihtiyacı vardır. Bu

      adresi elde etmek için sunucu, ya sunucu genelinde geçerli <directive

      module="core">ServerName</directive> yönergesine bakar ya da bir C

      işlevi olan <code>gethostname</code>’i kullanır (işlev, komut

      isteminden <code>hostname</code> komutuna dönen yanıtın aynısını

      döndürür) ve ardından bu adresle ilgili olarak bir DNS sorgusu yapar.

      Bu sorgudan kaçınmanın henüz bir yolu yoktur.</p>

    <p>Eğer bu sorgunun (DNS sunucusunun çökmüş olması gibi bir nedenle)

      başarısız olabileceğinden korkuyorsanız, makine ismini ve IP adresini

      <code>/etc/hosts</code> dosyanıza yazabilirsiniz (Makinenizin düzgün

      olarak açılabilmesi için zaten bu kaydı yapmış olmanız gerekir).

      Kullandığınız işletim sistemine bağlı olarak bu kaydın

      <code>/etc/resolv.conf</code> veya <code>/etc/nsswitch.conf</code>

      dosyasında bulunması gerekebilir.</p>

    <p>Herhangi bir nedenle sunucunuz bir DNS sorgusu yapmıyorsa veya

      yapmamalıysa, Apache’yi <code>HOSTRESORDER</code> ortam değişkenine

      "<code>local</code>" değerini atadıktan sonra çalıştırabilirsiniz. Bu

      tamamen işletim sistemine ve kullandığınız çözümleyici kütüphanelere

      bağlıdır. Ayrıca, ortamı denetlemek için <module>mod_env</module>

      kullanmıyorsanız, CGI’ler de bundan etkilenir. En iyisi işletim

      sisteminizin SSS belgelerini ve kılavuz sayfalarını okumaktır.</p>

  </section>

  <section id="tips">

    <title>Bu Sorunlardan Kaçınmak için İpuçları</title>

    <ul>

      <li><directive module="core">VirtualHost</directive> yönergelerinizde

        IP adresleri kullanınız.</li>

      <li><directive module="mpm_common">Listen</directive> yönergelerinizde

        IP adresleri kullanınız.</li>

      <li>Tüm sanal konakların ayrı birer <directive module="core"

        >ServerName</directive> yönergesi olsun.</li>

      <li>Hiçbir sayfa sunulmayan bir <code>&lt;VirtualHost

        _default_:*&gt;</code> sanal konağınız olsun.</li>

    </ul>

  </section>

  <section id="appendix">

    <title>Ek: Ufuk Turu</title>

    <p>DNS ile ilgili durum hiç de arzu edildiği gibi değildir. Apache 1.2

      için, DNS sorguları başarısız olsa bile sunucunun başlatılabilmesini

      sağlamaya çalıştık, fakat belki yapabildiğimizden daha da iyisi

      mümkündür. Günümüz Genel Ağ’ında IP adresleri sık sık değiştiğinden

      yapılandırma dosyasına doğrudan IP adresini yazma gerekliliği asla arzu

      edilen davranış değildir.</p>

    <p>Yukarıda nasıl yapıldığı açıklanan hizmet hırsızlığı saldırısına karşı

      önlem olarak, normal sorgudan dönen IP adresine bir ters DNS sorgusu

      yapıp bu iki sonucu karşılaştırmak ve eşleşmeme durumunda sanal konağı

      iptal etmek bir çözüm olabilir. Fakat bunun mümkün olabilmesi için

      uygun bir ters DNS kaydına ihtiyaç vardır. (FTP sunucuları ve TCP

      sarmalayıcılar tarafından yapılan çifte ters DNS sorgusu kullanımından

      dolayı çoğu ağ yöneticisi bu konuda zaten bilgi sahibidir.)</p>

    <p>Her halükarda, IP adreslerinin kullanılmaması nedeniyle yapılan DNS

      sorgularının başarısız olması durumunda sanal konaklı bir sunucuyu

      düzgün bir şekilde başlatmak olası görünmektedir. Yapılandırmayı kısmen

      iptal etmek gibi kısmi çözümler, sunucudan beklentinizin ne olduğuna

      bağlı olarak sunucuyu hiç başlatmamaktan daha iyi olabilir.</p>

    <p>HTTP/1.1’de belirtildiği gibi <code>Host</code> başlığını göndererek

      işlem yapabilen tarayıcılar ve vekiller IP’ye dayalı sanal konak

      kullanımını tamamen ortadan kaldırmanın mümkün olabileceğini

      göstermektedir. Bu durumda yapılandırmanın çözümlenmesi aşamasında DNS

      sorgusu yapma gereği kalmayacaktır. Fakat 1997 Mart’ından beri önemli

      sunucular üzerinde bunların yeterince geniş bir uygulama alanı

      bulmadığı görülmektedir.</p>

  </section>

</manualpage>