Web (HTTP) Servis Yönetimi | LKD #4

Bir önceki yazıda yaptığımız Virtual Host yapılandırmasını bu sefer de Debian Nginx makinesinde tekrarlayacağız.

Debian NGINX Virtual Hosting

Öncelikle ayarları yapacağımız /etc/nginx/sites-available dizinin altına gidip 2 yeni dizin oluşturalım. Ben bir önceki denememdeki isimleri koruyarak yeni dizinleri oluşturuyorum.

kamp.linux.org.tr

linux.org.tr

Sonraki aşamada available dizininde kurduğumuz ayarların uygulanabilir olması için enable’a taşımamız gerekecek. Bunun için dosyalara sembolik linkleme yapıyoruz.

bash

user@linux:~$ sudo ln -s /etc/nginx/sites-available/kamp.linux.org.tr /etc/nginx/sites-enabled/

bash

user@linux:~$ sudo ln -s /etc/nginx/sites-available/linux.org.tr /etc/nginx/sites-enabled/

Bu komutları girdikten sonra yapmamız gereken tek işlem /etc/hosts dosyasını düzenlemek olacak.

/etc/hosts

127.0.0.1 localhost

::1 localhost

ip_adresiniz linux.org.tr kamp.linux.org.tr

Bu işlemi yaptıktan ve sistemi restart ettikten sonra curl ile denemelerimizi yapıyoruz.

Başarılı bir şekilde tamamladık.

Debian NGINX WordPress Ayaklandırma

Şimdi bir NGINX sunucunda sıfırdan bir WordPress sitesi kuracağız. Siteyi kurarken PHP-FPM ve MariaDB kullanacağız. MariaDB kurmamız, wordpress MySQL kullanıyor olsa bile, MariaDB ve MySQL’in tamamen uyumlu olarak çalışmasından geliyor.

İlk olarak paketleri indirerek başlayalım.

bash

user@linux:~$ sudo apt install nginx mariadb-server php-fpm php-mysql php-curl php-gd php-intl php-mbstring php-soap php-xml php-xmlrpc php-zip -y

Paketler indikten sonra MariaDB’ye gidip root olarak oturum açalım.

Ardından veritabanında sırasıyla aşağıdaki ayarları yapıp veritabanından çıkış yapalım.

bash — MariaDB

user@linux:~$ sudo mysql -u root -p

MariaDB [(none)]> CREATE DATABASE wordpress_db DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;

MariaDB [(none)]> CREATE USER ‘wp_admin’@’localhost’ IDENTIFIED BY ‘SeninSifren123!’;

MariaDB [(none)]> GRANT ALL PRIVILEGES ON wordpress_db.* TO ‘wp_admin’@’localhost’;

MariaDB [(none)]> FLUSH PRIVILEGES;

MariaDB [(none)]> EXIT;

Bir sonraki aşamada wordpress’i sunucumuza kurmak için wordpress’ten latest.zip dosyasını indirelim.

bash — wget

user@linux:~$ wget https://wordpress.org/latest.zip

Dosyayı tmp dizinine çekip orada zip’ten çıkartalım.

bash — unzip

user@linux:~$ unzip latest.zip

Elde ettiğimiz wordpress dizinini /var/www altına taşıyalım.

bash — cp

user@linux:~$ sudo cp -a /tmp/wordpress/. /var/www/wordpress/

WordPress kullanıcı ve grubumuzu düzenleyelim.

bash — chown

user@linux:~$ sudo chown -R www-data:www-data /var/www/wordpress

Bunu yaptıktan sonra WordPress, varsayılan olarak wp-config-sample.php adında bir örnek dosya ile gelir. Biz bunu asıl ayar dosyamıza kopyalıyoruz: wp-config.php

bash — cp

user@linux:~$ sudo cp wp-config-sample.php wp-config.php

Dosya içerisindeki bilgileri kendi veritabanımıza göre düzenleyip kaydedip çıkalım.

Bu işlemi de tamamladıktan sonra sistemimizi yeniden başlatıp tarayıcıdan adresimize (localhost) gidelim.

Başarılı bir şekilde wordpress sitemizi ayaklandırdık. Karşılaşabileceğimiz sorunlara karşı daima İngilizce kurulum yapmamız öneriliyor.

Bu noktada Doruk Hoca belli noktalardaki problemlere değindi, wordpress sitemize nasıl dosya yükleyeceğimiz, dosya boyutunu nasıl arttıracağımız gibi…

Bu problemi çözmek için yaptığımız araştırmalardan sonra sunucuda kullanılan PHP-FPM uygulama sunusunda yer alan bir kısıtlama sonucu oluştuğunu belirledik.

Bu durumu çözmek için ilgili uygulama sunucusunun nasıl çalıştığını ve hangi kaynakta konfig edilebildiğini belirledik, bu adres /etc/php/8.1/fpm/php.in .

Düzenlememiz gereken iki yer olduğunu keşfettik.

İlki , post_max_size değişkeniydi. Tek seferde ne kadar veri göndereceğimizi belirleyen bir değişken. Bunu 64M olarak güncelledim.

Diğeri ise, yüklenecek maksimum dosya boyutunu belirleyen upload_max_filesize değişkeniydi, bunu da 64m olarak güncelledim.

İkisi de güncelleyip php servisini yeniden başlattığımda problemin çözüldüğünü, yeni boyutun 64M olduğunu gördük ve sorunu çözdük.

Burada farklı kurulumlarda farklı problemler çıktığını, bu problemlerin de ilk gün anlatılan istemci-sunucu modelinin bir parçası olduğunu anlıyoruz. Örneğin web sunucusu tarafında dosya boyutu için 16M belirlenmiş olsun. Biz php uygulama sunucusunda boyutu kaç yaparsak yapalım aktarılabilecek maksimum veri 16M olacaktır.

Reverse Proxy

İnternet ağlarının filtrelenmesi, bazı sitelerin kısıtlanması, yük dengelenmesi vb. birçok noktada kullandığımız ters proxy aslında istemci ve sunucu mimarisinin bir nevi yer değiştirmesidir.

İstemciler bir sunucuya gitmek istediklerinde onları doğrudan o siteye götürmek yerine araya bir “aracı sunucu” koyarak istemcinin muhattabını aracı sunucu olarak belirleriz.

Bunu güvenlik,

Saldırganlara karşı IP adresini doğrudan göstermeme
Rate limit (Olası ddos saldırılarına karşı IP başına bir deneme hakkı koyma işi)
Firewall katmanı

cache (önbellek) alma ,çok sık tıklanan sayfaları hafızaya atmak, SSL sertifikası doğrulama yükünü ara sunucuya verip sunucuları bu yükten kurtarmak gibi amaçlarla kullanabiliriz.

Normal proxy sunucularından farkı görünüşte istemciyi değil sunucuyu korumasıdır.

Forward Proxy yani bizim normal bildiğimiz proxy de istemci tarafın ip adresi gizlenir, yasaklı siteler filtrelenir… gibi işler yapılır.

Özellik	Forward Proxy	Reverse Proxy
Gizlenen Taraf	İstemci	Sunucu
İşlev	İnternete çıkar	İnterneti filtreler
Ayarlama	Kullanıcı kendi yapar	Kullanıcının durumdan haberi olmaz
Örnek kullanım	Filtreleme	Load balancing (yükdengeleyici)

Başta Doruk ve Gökhan hocalarım olmak üzere kampta emeği geçen herkese teşekkür ederim.