Ubuntu 24.04 uzerinde LAMP stack kurulumu ve PHP-FPM ayari

Ne inşa ediyorsunuz

LAMP yığını, bir Ubuntu 24.04 sunucusu üzerinde çalışan dört bileşenden oluşur: Temelde Linux, HTTP isteklerini karşılayan Apache, verileri tutan MariaDB ve kodu çalıştıran PHP 8.3. Bu rehberin sonunda, gerçek bir uygulama dizinine hizmet veren isme dayalı bir sanal ana bilgisayara (virtual host), özel ve en düşük yetkili bir kullanıcıya sahip bir veritabanına, PHP-FPM aracılığıyla Apache'ye bağlanmış PHP'ye ve tüm bunların üzerinde ücretsiz bir Let's Encrypt sertifikasına sahip olacaksınız.

Kurulumun kendisi dört adet apt komutundan ibarettir. Bu rehberdeki neredeyse her şey, bileşenler arasındaki bağlantıların kurulması ve yeni kurulmuş bir yığının boş bir sayfa göstermesine, kaynak kodunuzu tarayıcıya bir dosya olarak indirtmesine veya yeni kurduğunuz veritabanına erişiminizi reddetmesine neden olan küçük hataların giderilmesi ile ilgilidir. Bu hataların her birinin tanınabilir bir imzası vardır ve her biri aşağıda karşılaşacağınız tam metinle birlikte belirtilmiştir.

Ön gereksinimler ve dikkat edilmesi gerekenler

Sudo yetkisine sahip bir kullanıcı veya root erişimi olan, temiz bir Ubuntu 24.04 KVM VPS ve genel bir IPv4 adresi varsayılmaktadır. Minimal bir yığın 1 GB RAM ile çalışabilir; ancak veritabanı destekli gerçek bir uygulama barındırmadan önce bunu 2 GB seviyesine çıkarın. Çünkü MariaDB varsayılan tampon bellekleri ve birkaç PHP-FPM işçisi, ilk gigabaytı hızla tüketir.

Süreç sonunda Certbot'un çalışabilmesi için iki koşulun sağlanması gerekir, bunları şimdiden hazırlayın. VPS'in genel IP adresine işaret eden bir A kaydına sahip bir alan adına ihtiyacınız vardır; Let's Encrypt doğrulamayı HTTP üzerinden bu isimle yapar ve çıplak bir IP adresi asla sertifika alamaz. Ayrıca 80 ve 443 numaralı portların internetten erişilebilir olması gerekir. Birçok sağlayıcıda bu, portları hem kontrol panelindeki ağ güvenlik duvarında hem de sunucu üzerindeki ufw içinde açmanız gerektiği anlamına gelir. DNS değişikliklerinin yayılması bir saati bulabilir, bu nedenle A kaydını önceden ayarlayın; böylece ihtiyaç duyduğunuzda aktif olacaktır.

Adım 1 - Apache kurulumu ve varsayılan sayfanın doğrulanması

sudo apt update
sudo apt install -y apache2

apt servisi başlatır ve etkinleştirir. Durumunu kontrol edin:

systemctl status apache2

Çıktıda active (running) ifadesini görmelisiniz. Şimdi tarayıcınızda http://YOUR_SERVER_IP/ adresini açın. Büyük "It works!" başlığına sahip Apache2 Ubuntu Default Page sayfasını görmeniz, Apache'nin çalıştığını kanıtlar; bu bir hata değildir. Söz konusu sayfa /var/www/html/index.html dizininde bulunur ve varsayılan sanal ana bilgisayar 000-default.conf tarafından sunulur. Her ikisini de daha sonra devre dışı bırakacaksınız; ancak şu an için bu sayfanın görünmesi beklenen durumdur.

Sayfa hiç yüklenmiyor ancak systemctl komutu sürecin çalıştığını gösteriyorsa, bir güvenlik duvarı trafiği engelliyor demektir. Bir sonraki adım bu konuyla ilgilidir.

Adım 2 - Güvenlik duvarını HTTP ve HTTPS için açın

apache2 paketi üç adet ufw uygulama profili kaydeder. Bunları listeleyin:

sudo ufw app list

Apache, Apache Full ve Apache Secure seçeneklerini göreceksiniz. Apache yalnızca 80 numaralı portu, Apache Secure yalnızca 443 numaralı portu, Apache Full ise her ikisini de kapsar. TLS yapılandırmasını sonunda ekleyeceğiniz için ihtiyacınız olan profil budur.

sudo ufw allow OpenSSH
sudo ufw allow "Apache Full"
sudo ufw enable

ufw enable komutunu çalıştırmadan önce OpenSSH profilini izinli hale getirin. ufw varsayılan olarak tüm gelen trafiği reddeder. SSH kuralı eklemeden etkinleştirmek, komutun devreye girdiği anda bağlantınızın kesilmesine neden olur; mevcut oturumunuz açık kalsa bile tekrar bağlanamazsınız. sudo ufw status ile onaylayın; OpenSSH, Apache Full ve bunların v6 karşılıklarının tamamının ALLOW durumunda olduğunu görmelisiniz.

Adım 3 - MariaDB kurulumu ve güvenliğinin sağlanması

sudo apt install -y mariadb-server
systemctl status mariadb

Ubuntu 24.04, uzun süreli destek (LTS) sürümü olan MariaDB 10.11 ile gelir; bu nedenle harici bir depo kullanmanıza gerek yoktur. Servis çalışır durumdayken güvenliğini şu şekilde sıkılaştırın:

sudo mysql_secure_installation

Komut istemlerini doğrudan geçmek yerine okumak faydalıdır. Current root password sorulduğunda Enter tuşuna basın, henüz bir parola tanımlı değildir. "Switch to unix_socket authentication?" sorulduğunda, bu paket üzerinde zaten etkin olduğu için yanıt bir şeyi değiştirmez; bu yüzden n tuşuna basın. Bir sonraki paragrafta açıklanan nedenlerden dolayı "Change the root password?" sorusuna n yanıtını verin, ardından geri kalan sorulara Y yanıtını vererek anonim kullanıcıları kaldırın, uzaktan root girişini engelleyin, test veritabanını silin ve yetki tablolarını yeniden yükleyin.

Herkesin kafasını karıştıran kısım burasıdır. Ubuntu üzerindeki MariaDB'de root veritabanı hesabı, parola yerine unix_socket kimlik doğrulamasını kullanır. Bu, veritabanının halihazırda kimlik doğrulaması yapılmış olan işletim sistemi kullanıcısına güvendiği anlamına gelir. Dolayısıyla, bir root kabuğundan şu komut çalışır:

sudo mysql

...ve sizi parola sormadan bir MariaDB [(none)]> istemine düşürür. Aynı komut yetkisiz bir kullanıcı tarafından çalıştırıldığında reddedilir; tüm amaç da budur: veritabanı root erişimi, sunucudaki sudo yetkisine bağlıdır ve çalınabilecek, oltalama saldırısına uğrayabilecek veya kaba kuvvetle kırılabilecek bir parola yoktur. Bu yöntem paroladan daha güvenlidir, bu yüzden ayarları değiştirmeyin. Buradan çıkan kural şudur: Bir uygulamayı asla root hesabına yönlendirmeyin. Her uygulama için özel bir kullanıcı oluşturun (Adım 7); çünkü TCP üzerinden kullanıcı adı ve parola ile bağlanan bir uygulama zaten socket kimlik doğrulamasını kullanamaz ve her uygulamanın yalnızca kendi veritabanıyla sınırlı kalmasını istersiniz.

Adım 4 - PHP 8.3 ve PHP-FPM Kurulumu

Ubuntu 24.04 üzerinde varsayılan PHP sürümü 8.3'tür. FPM süreç yöneticisini ve tipik bir uygulamanın ihtiyaç duyduğu eklentileri kurun:

sudo apt install -y php8.3-fpm php8.3-mysql php8.3-cli \
  php8.3-curl php8.3-xml php8.3-mbstring php8.3-zip

Bu listede nelerin olmadığına dikkat edin: libapache2-mod-php. Bu eski paket, her Apache süreci içine bir PHP yorumlayıcısı gömer. Basittir ancak her çalışan süreç, bir betik veya statik bir görsel sunsa dahi bir PHP kopyası taşır; ikisi aynı yaşam döngüsünü paylaşır ve yalnızca Apache'nin en verimsiz MPM'i olan prefork ile çalışır. PHP-FPM ise PHP'yi, Apache'nin bir soket üzerinden haberleştiği kendi süreç havuzu olarak çalıştırır. Bu sayede Apache, statik dosyalar için çok iş parçacıklı (threaded) event MPM'i kullanabilir ve yalnızca PHP isteklerini ilgili havuza iletir; havuz, web sunucusundan bağımsız olarak optimize edilebilir ve aynı FPM yapılandırması, ileride önüne nginx koyduğunuzda da çalışmaya devam eder. Bunun güncel varsayılan olmasının geçerli bir nedeni vardır.

Apache, FPM'e proxy_fcgi modülü üzerinden erişir. Bu modülü etkinleştirin, FPM paketinin eklediği yapılandırmayı devreye alın ve yeniden başlatın:

sudo a2enmod proxy_fcgi setenvif
sudo a2enconf php8.3-fpm
sudo systemctl restart apache2

a2enconf php8.3-fpm, PHP dosyalarını FPM soketine yönlendiren kuralı içeren /etc/apache2/conf-available/php8.3-fpm.conf dosyasını etkinleştirir. Bu yapılandırmanın kalbi, tüm .php dosyalarını eşleştirir ve bunları /run/php/php8.3-fpm.sock adresindeki sokete iletir:

<FilesMatch ".+\.ph(ar|p|tml)$">
    SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost"
</FilesMatch>

Bu dosyayı düzenlemenize gerek yoktur; doğru yapılandırmayla gelir. Ancak soket yolunu bilmek, ileride karşılaşabileceğiniz "PHP çalıştırılmak yerine indiriliyor" veya "Primary script unknown" hatalarını teşhis etmenizi sağlar; her iki hata da Apache ve FPM'in bu soket veya soketin arkasındaki dosya konusunda uyuşmazlık yaşamasından kaynaklanır.

Adım 5 - Uygulamanız için isme dayalı sanal ana bilgisayar (virtual host)

İsme dayalı sanal barındırma, tek bir IP adresinin birden fazla siteye hizmet vermesini sağlar; Apache, siteyi istek içerisindeki Host: başlığına göre seçer. Uygulama için varsayılan /var/www/html dizininden uzak, ayrı bir dizin oluşturun:

sudo mkdir -p /var/www/testapp
sudo chown -R www-data:www-data /var/www/testapp
sudo chmod -R 755 /var/www/testapp

Sahiplik önemlidir. Ubuntu üzerinde hem Apache hem de PHP-FPM, www-data kullanıcısı olarak çalışır; bu nedenle web sunucusunun okuması gereken dosyalar ve uygulamanın yazması gereken yükleme klasörü gibi dizinlerin sahibi www-data olmalıdır. Dosyaları kendi kullanıcı hesabınızla düzenleyecekseniz, dosyaların sahibi olup kendi kullanıcınızı www-data grubuna eklemek yaygın bir yöntemdir; basit bir dağıtım için www-data:www-data en sorunsuz yoldur.

Sanal ana bilgisayarı /etc/apache2/sites-available/testapp.conf konumunda oluşturun:

<VirtualHost *:80>
    ServerName app.example.com
    DocumentRoot /var/www/testapp

    <Directory /var/www/testapp>
        Options -Indexes +FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/testapp-error.log
    CustomLog ${APACHE_LOG_DIR}/testapp-access.log combined
</VirtualHost>

ServerName değerini gerçek alan adınızla değiştirin. Options -Indexes, dizin listeleme özelliğini kapatarak dizin içerisinde bir index dosyası bulunmadığında ziyaretçilerin kaynak ağacınızı görmesini engeller. AllowOverride All, çoğu PHP uygulamasının düzgün URL'ler için ihtiyaç duyduğu .htaccess dosyasının çalışmasını sağlar; uygulamanızın buna ihtiyacı yoksa küçük bir hız kazanımı için bu ayarı None olarak değiştirebilirsiniz. Bu siteyi etkinleştirin, varsayılan siteyi devre dışı bırakın, yapılandırmayı kontrol edin ve yeniden yükleyin:

sudo a2ensite testapp
sudo a2dissite 000-default
sudo apache2ctl configtest
sudo systemctl reload apache2

apache2ctl configtest komutu Syntax OK çıktısını vermelidir. a2dissite 000-default satırı genellikle unutulan kısımdır; varsayılan sayfanın takılı kalmış gibi görünmesinin ve hata bölümünde belirtilen sorunların temel nedeni budur.

Adım 6 - PHP'nin çalıştığını doğrulayın ve kanıtı silin

Uygulama kök dizinine tek satırlık bir PHP dosyası ekleyin:

echo "<?php phpinfo();" | sudo tee /var/www/testapp/info.php

http://app.example.com/info.php adresini ziyaret edin. Doğru sonuç, yüklü modüllerinizi listeleyen uzun, mor ve gri renkli PHP Version 8.3.x tablosudur; burada Server API satırı FPM/FastCGI değerini göstermelidir. Bu son satır, isteklerin mod_php üzerinden değil, PHP-FPM üzerinden iletildiğini doğrular.

Şimdi dosyayı derhal silin:

sudo rm /var/www/testapp/info.php

phpinfo() dosyanız; tam PHP sürümünüzü, yüklü tüm eklentileri, dosya yollarını ve ortam detaylarını açığa çıkarır. Bu, sunucuda bilinen bir açığı olan bir sürüm arayan herkes için bir hediyedir. Bu bir özellik değil, bir test dosyasıdır. Sayfayı gördüğünüz anda dosyayı silin. Eğer tarayıcınız tabloyu göstermek yerine info.php dosyasını indirmeyi teklif ederse, PHP Apache ile düzgün yapılandırılmamış demektir; başka bir işlem yapmadan önce hata giderme bölümüne geçin.

Adım 7 - Uygulama veritabanını ve en düşük yetkili kullanıcıyı oluşturma

Veritabanını, socket ile kimlik doğrulaması yapan root kullanıcısı olarak açın:

sudo mysql

Ardından bir veritabanı ve yalnızca bu veritabanı üzerinde yetkili bir kullanıcı oluşturun:

CREATE DATABASE appdb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'a-long-random-password';
GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Burada üç bilinçli tercih yapılmıştır. utf8mb4 gerçek dört baytlık UTF-8 kodlamasıdır; eski utf8 takma adı emoji ve bazı CJK karakterlerini sessizce kırpar, bu yüzden her zaman utf8mb4 kullanın. Yetkilendirme appdb.* üzerinde yapılmıştır, *.* üzerinde değildir: bu kullanıcı yalnızca kendi veritabanına erişebilir, başka hiçbir şeye dokunamaz. Böylece uygulamadaki bir SQL-injection açığı, diğer tüm sitelerin tablolarını okuyamaz. Ayrıca 'appuser'@'localhost', hesabı yalnızca sunucunun kendisinden gelen bağlantılarla kısıtlar.

Kullanıcıyı test edin:

mysql -u appuser -p appdb

Sistem parola soracak ve sizi bir MariaDB [appdb]> istemine düşürecektir. -h bayrağının kullanılmadığına dikkat edin; bu bayrağı kullanmayın, böylece istemci yerel Unix socket üzerinden bağlanır ve MariaDB bunu tam olarak localhost olarak kabul eder. Bilinmesi gereken önemli bir nokta: MySQL ve MariaDB için localhost Unix socket, 127.0.0.1 ise TCP bağlantısı anlamına gelir. Standart bir Ubuntu 24.04 MariaDB kurulumunda sunucu, 127.0.0.1 üzerinden gelen TCP bağlantısını yine localhost olarak çözer, dolayısıyla her ikisi de hesapla eşleşir. Ancak skip-name-resolve etkinleştirilmiş sunucularda (yaygın bir performans ayarıdır ve birçok container imajında standarttır), bu ikisi farklı ana bilgisayarlar olarak değerlendirilir. Bu durumda 127.0.0.1 adresine bağlanan bir uygulama, parola doğru olsa bile ERROR 1045 (28000): Access denied for user 'appuser'@'127.0.0.1' (using password: YES) hatasıyla reddedilir.

Bu nedenle uygulamanızı localhost ana bilgisayarına, appuser kullanıcısına ve appdb veritabanına yönlendirin; asla root adresini kullanmayın. PHP'nin mysqli ve PDO sürücüleri, ana bilgisayar ismi tam olarak localhost olduğunda Unix socket bağlantısına geçer ve az önce oluşturduğunuz hesapla eşleşir. Eğer bir framework sayısal bir TCP ana bilgisayarı kullanmakta ısrar ediyorsa, kullanıcıyı bağlantı şekline göre 'appuser'@'127.0.0.1' olarak oluşturun. Yalnızca veritabanına başka bir makineden erişilmesi gerekiyorsa @'%' kullanın (bunu bir güvenlik duvarı kuralı ile destekleyin).

Adım 8 - Certbot ile HTTPS Ekleme

Giriş formunu düz HTTP üzerinden sunmak, parolaların açık metin olarak gönderilmesine neden olur ve tüm modern tarayıcılar sayfayı "Güvenli değil" şeklinde işaretler. Certbot, bu sorunu tek bir komutla çözer. Apache eklentisi ile birlikte yükleyin:

sudo apt install -y certbot python3-certbot-apache
sudo certbot --apache

Certbot burada iki eklenti kullanır. apache authenticator, çalışan Apache üzerinden kısa süreliğine bir doğrulama dosyası sunarak alan adının kontrolünün sizde olduğunu kanıtlar; apache installer ise 443 bloğunu eklemek için sanal ana makine (virtual host) yapılandırmanızı yeniden yazar, yeni sertifikayı işaret eder ve tüm HTTP trafiğini varsayılan olarak HTTPS'e yönlendirir. Certbot 2.0 sürümünden itibaren yönlendirme sorusu sorulmamaktadır; düz HTTP üzerinden sunum yapmaya devam etmeniz gerekiyorsa --no-redirect bayrağını kullanın. Adım 5'te gerçek bir ServerName belirlediğiniz için Certbot alan adını otomatik olarak algılar. Sertifikalar 90 gün geçerlidir ve paket, bunları yenileyen bir systemd zamanlayıcısı kurar; zamanlayıcıyı, Congratulations, all simulated renewals succeeded ile bitmesi gereken sudo certbot renew --dry-run komutu ile doğrulayın.

Doğrulama süreci, yenileme zamanlayıcısı ile DNS ve güvenlik duvarı gereksinimlerine dair tam kılavuz için Apache üzerinde Certbot ile ücretsiz Let's Encrypt TLS sertifikaları düzenleme başlıklı yardımcı rehbere bakın.

Yedeklemeler, yükseltmeler ve sıkılaştırma

Durumunuzu koruyan iki öğeyi yedekleyin: veritabanları ve web kök dizini. Her gece alınan mantıksal bir döküm, en basit ve güvenilir yaklaşımdır, sudo sh -c 'mysqldump --all-databases --single-transaction | gzip > /root/db-$(date +%F).sql.gz', ardından sunucu dışına kopyalanır. Tüm süreci sudo sh -c ile sarmalamak önemlidir: bu olmadan kabuk, > /root/... yönlendirmesini kendi kullanıcınız olarak çalıştırır ve mysqldump yalnızca sudo değerini devraldığı için Permission denied hatasıyla başarısız olur. --single-transaction, InnoDB tablolarını kilitlemeden tutarlı bir anlık görüntü sağlar. Bunu /var/www ve /etc/apache2/sites-available dosyalarının bir tar yedeği ile eşleştirin; böylece tüm yığını bu dosyalardan yeni bir VPS üzerinde yeniden oluşturabilirsiniz.

Yükseltmeler olağan bir sudo apt update && sudo apt upgrade işlemidir. Sorun yaratan durum ise PHP sürüm yükseltmesidir; gelecekteki bir Ubuntu sürümü varsayılanı PHP 8.4'e taşıdığında, apt, 8.3'ün yanına php8.4-fpm paketini kurabilir, soket /run/php/php8.4-fpm.sock haline gelir ve Apache yapılandırmanız hala 8.3 soketini işaret eder. Yeni yapılandırmayı etkinleştirin (sudo a2enconf php8.4-fpm) ve eskisini devre dışı bırakın; aksi takdirde siteniz rutin bir yükseltme sonrasında Primary script unknown hatası döndürmeye başlar. PHP sürümleri bir LTS dağıtımından daha hızlı güncellendiğinden, yama sürümünü sabitlemek yerine güncel PHP sürüm notlarını kontrol edin.

İlk gün yapılması gereken iki sıkılaştırma adımı vardır. Birincisi, sunucuya SSH izleyen Fail2Ban kurun; halka açık bir VPS dakikalar içinde otomatik giriş denemelerine maruz kalır ve küçük bir jail yapılandırması, binlerce denemeyi yasaklama öncesinde birkaç taneye indirir. İkincisi, Apache sanal ana bilgisayarlarını, MariaDB veritabanlarını ve kullanıcıları dosyaları elle düzenlemek yerine bir tarayıcı üzerinden yönetmeyi tercih ederseniz, Web tabanlı Webmin kontrol paneli tam olarak bu yığının üzerinde çalışır ve az önce yazdığınız aynı yapılandırma dosyalarını yönetir. Bunların hiçbiri parçaları anlamanın yerini tutmaz ancak her ikisi de günlük operasyonel yükü azaltır.

Hata modları ve karşılaşacağınız dizgeler

Varsayılan sayfa gitmiyor. Sanal ana bilgisayarınızı (virtual host) düzenleyip yeniden yüklemenize rağmen tarayıcı hâlâ "Apache2 Ubuntu Default Page" ve "It works!" başlığını gösteriyor. Apache, eşleşen ilk sanal ana bilgisayarı sunar; herhangi bir ServerName istekle eşleşmediğinde alfabetik olarak ilk sırada yer alan yapılandırma geçerli olur, 000-default.conf, testapp.conf dosyasından önce sıralanır. İsteğin ana bilgisayar adı ServerName değerinizle eşleşmiyor olabilir veya sudo a2dissite 000-default komutunu hiç çalıştırmamış olabilirsiniz. Varsayılan yapılandırmayı sudo systemctl reload apache2 ile devre dışı bırakın ve sanal ana bilgisayar haritasını yazdırarak hangi yapılandırmanın varsayılanı yönettiğini gösteren apache2ctl -S ile doğrulayın. Ayrıca tarayıcı önbelleğini temizleyin; eski sayfadan kalan 200 yanıtı önbellekte kalmaya devam edebilir.

.php dosyası çalışmak yerine indiriliyor. info.php dosyasını açtığınızda tarayıcı, <?php kaynak kodunu içeren bir dosyayı indiriyor veya kodu düz metin olarak gösteriyorsa, PHP işleyicisi (handler) bağlı değil demektir. sudo a2enmod proxy_fcgi veya sudo a2enconf php8.3-fpm adımlarını atlamış ya da sonrasında Apache'yi yeniden başlatmamış olabilirsiniz. Her üç adımı da (Adım 4) çalıştırın ve yeniden yükleyin. Modülün yüklü olduğunu, proxy_fcgi_module listesini içermesi gereken apache2ctl -M | grep fcgi komutuyla doğrulayın. Bu durum kozmetik bir hata değil, bir kaynak kodu sızıntısıdır; bu nedenle sunucuya gerçek veriler yüklemeden önce sorunu giderin.

ERROR 1698 (28000): Access denied for user 'root'@'localhost'. sudo kullanmadan mysql -u root veya mariadb -u root komutunu çalıştırdınız. Root hesabı unix_socket kimlik doğrulamasını kullanır, bu nedenle yalnızca işletim sistemi kullanıcınız root olduğunda erişime izin verir. Çözüm, parola olmadan sudo mysql veya -u root kullanmaktır. Bu mesaj, soket kimlik doğrulamasının düzgün çalıştığının bir göstergesidir; kurulumun bozuk olduğu anlamına gelmez.

Uygulamadan gelen ERROR 1045 (28000): Access denied for user 'appuser'@'127.0.0.1' hatası (doğru parola ile). Hesap 'appuser'@'localhost' olarak mevcut ancak uygulamanız, ana bilgisayar adı çözümlemesinin devre dışı olduğu (skip-name-resolve) bir sunucuda 127.0.0.1 üzerinden TCP ile bağlanmaya çalışıyor. Bu durumda MariaDB, localhost (Unix soketi) ve 127.0.0.1 (TCP) adreslerini farklı ana bilgisayarlar olarak algılar. Uygulamayı soket kullanacak şekilde localhost ana bilgisayarına yönlendirin veya çerçeveniz yalnızca TCP destekliyorsa 'appuser'@'127.0.0.1' şeklinde ikinci bir hesap oluşturun.

/var/log/apache2/testapp-error.log içinde AH01071: Got error 'Primary script unknown' hatası ve tarayıcıda File not found. görünümü. Apache isteği PHP-FPM'e iletti ancak FPM, Apache'nin belirttiği yolda betiği bulamadı. Bunun iki yaygın nedeni vardır: yapılandırmanızdaki FPM soketi yüklü olmayan bir PHP sürümüne işaret ediyor olabilir (yükseltme sonrası sadece 8.3 çalışırken php8.4 soketi kalması gibi) veya DocumentRoot ile gerçek dizin yolu uyuşmadığı için dosya gerçekten orada olmayabilir. Soketin varlığını ls -l /run/php/ ile kontrol edin, DocumentRoot değerinin dosyanın bulunduğu yerle eşleştiğini doğrulayın ve hem php8.3-fpm hem de apache2 servislerini yeniden başlatın.

Her yeniden başlatmada AH00558: apache2: Could not reliably determine the server's fully qualified domain name. Bu bir hata değil, zararsız bir uyarıdır; Apache, küresel bir ServerName değerinin ayarlanmadığını bildirmektedir. Bu uyarıyı susturmak için /etc/apache2/conf-available/servername.conf dosyasına ServerName your.domain satırını ekleyin ve sudo a2enconf servername komutunu çalıştırın.

Apache başlarken (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80. Başka bir web sunucusu 80 numaralı portu halihazırda kullanıyor olabilir; bu genellikle önceki denemelerden kalan bir nginx servisidir. sudo ss -ltnp | grep :80 ile bu servisi bulun, ardından Apache'yi başlatmadan önce diğer servisi durdurun ve devre dışı bırakın.

FAQ

mod_php mi yoksa PHP-FPM mi kullanmalıyım?

PHP-FPM kullanın. mod_php, her Apache süreci içine bir yorumlayıcı gömer ve yavaş olan prefork MPM kullanımını zorunlu kılar; bu nedenle Apache, statik bir görsel sunarken bile PHP yükünü taşır. PHP-FPM, PHP'yi Apache'nin bir soket üzerinden eriştiği, bağımsız olarak ayarlanabilen ayrı bir havuz olarak çalıştırır, daha hızlı olan çok iş parçacıklı event MPM ile uyumludur ve ileride nginx'e geçişi kolaylaştırır. Modern standart budur; mod_php yalnızca süreç içi davranışlara bağımlı eski uygulamalar için anlamlıdır.

Tarayıcım neden PHP dosyasını çalıştırmak yerine indiriyor?

Apache, herhangi bir PHP işleyicisi atanmadığı için .php dosyasını statik bir indirme dosyası olarak işlemektedir. FPM kullanılan Ubuntu 24.04 üzerinde bu durum, sudo a2enmod proxy_fcgi, sudo a2enconf php8.3-fpm komutlarından birini veya sonrasındaki Apache yeniden başlatma işlemini atladığınız anlamına gelir. Üçünü de çalıştırıp yeniden yükleyin, ardından apache2ctl -M | grep fcgi ile proxy_fcgi_module öğesinin listelendiğini doğrulayın. Sorunu çözene kadar sunucu kaynak kod sızdırıyor demektir, bu nedenle durumu acil olarak değerlendirin.

Doğru şifreyi girmeme rağmen MariaDB'de root erişimi neden reddediliyor?

Şifre olmadığı için Ubuntu'nun MariaDB kurulumu, root hesabını unix_socket ile doğrular ve bu hesabı işletim sistemi root kullanıcısına bağlar. Normal bir kabuktan mysql -u root komutu, tasarım gereği ERROR 1698 (28000): Access denied for user 'root'@'localhost' hatası döndürür. Bunun yerine sudo mysql ile bağlanın ve root hesabını yeniden kullanmak yerine herhangi bir uygulama için şifre ile doğrulanan ayrı bir kullanıcı oluşturun.

LAMP siteme nasıl HTTPS eklerim?

certbot ve python3-certbot-apache paketlerini kurun, alan adınızın A kaydını sunucuya yönlendirin ve ardından sudo certbot --apache komutunu çalıştırın. Apache doğrulayıcısı, çalışan Apache üzerinden alan adı kontrolünü kanıtlar; yükleyici, 443 numaralı port için sanal ana bilgisayar yapılandırmasını yeniden yazar ve otomatik yenilemeyi ayarlar. Kapsamlı Certbot ve Apache rehberi, doğrulama sürecini, yenileme zamanlayıcısını ve sık karşılaşılan hata türlerini açıklamaktadır.