LAMP sa Ubuntu 24.04 gamit ang PHP-FPM

Ano ang itinatayo mo

Ang LAMP stack ay binubuo ng apat na bahagi sa isang Ubuntu 24.04 server: Linux sa ilalim, Apache para sa HTTP, MariaDB para sa data, at PHP 8.3 para patakbuhin ang code. Sa pagtatapos, magkakaroon ka ng name-based virtual host na naghahatid ng aktuwal na application directory, database na may nakatalagang user na may pinakamababang kinakailangang pribilehiyo, PHP na nakakonekta sa Apache sa pamamagitan ng PHP-FPM, at libreng Let's Encrypt certificate.

Ang mismong pag-install ay binubuo ng apat na apt command. Halos lahat ng nasa gabay na ito ay tungkol sa pagkonekta sa mga bahaging ito at sa maliit na hanay ng mga pagkakamaling maaaring magdulot na maghatid ang bagong stack ng blangkong page, ibigay sa browser ang source code bilang download, o tumangging papasukin ka sa database na kakainstall mo pa lamang. May makikilalang signature ang bawat isa sa mga ito, at nakalista sa ibaba ang bawat isa kasama ang eksaktong text na makikita mo.

Mga kinakailangan at mahahalagang limitasyon

Ipagpalagay ang isang bagong Ubuntu 24.04 KVM VPS na may sudo user o root at pampublikong IPv4 address. Gumagana ang minimal na stack sa 1 GB ng RAM; maglaan ng 2 GB bago maglagay ng aktuwal na application na gumagamit ng database, dahil mabilis maubos ang unang gigabyte sa default buffers ng MariaDB at ilang PHP-FPM worker.

Dalawang bagay ang dapat matupad bago gumana ang Certbot sa dulo, kaya ayusin ang mga ito ngayon. Kailangan mo ng domain name na may A record na nakaturo sa pampublikong IP ng VPS. Nagva-validate ang Let's Encrypt gamit ang HTTP sa domain na iyon, at hindi kailanman makakakuha ng certificate ang isang payak na IP address. Dapat ding maabot mula sa internet ang ports 80 at 443. Sa maraming provider, nangangahulugan ito ng pagbubukas ng mga ito sa network firewall sa control panel pati na rin sa ufw sa server. Maaaring umabot nang isang oras bago ma-propagate ang mga pagbabago sa DNS, kaya itakda muna ang A record upang aktibo na ito kapag kailangan mo na.

Hakbang 1 - I-install ang Apache at kumpirmahin ang default page

sudo apt update
sudo apt install -y apache2

apt ang nag-start at nag-e-enable ng service para sa iyo. Suriin ito:

systemctl status apache2

Dapat may makitang linyang active (running). Ngayon, buksan ang http://YOUR_SERVER_IP/ sa browser. Ang Apache2 Ubuntu Default Page na may malaking banner na "It works!" ang tamang resulta. Patunay ito na nagsi-serve ang Apache, hindi ito error. Nasa /var/www/html/index.html ang page na iyon at sini-serve ito ng shipped default virtual host na 000-default.conf. Idi-disable mo ang dalawa sa susunod; sa ngayon, eksaktong iyon ang dapat mong makita.

Kung hindi talaga naglo-load ang page ngunit sinasabi ng systemctl na tumatakbo ang process, may firewall na humaharang. Iyon ang susunod na hakbang.

Hakbang 2 - Buksan ang firewall para sa HTTP at HTTPS

Nagrerehistro ang package na apache2 ng tatlong application profile ng ufw. Ilista ang mga ito:

sudo ufw app list

Makikita mo ang Apache, Apache Full, at Apache Secure. Ang Apache ay port 80 lamang, ang Apache Secure ay 443 lamang, at ang Apache Full ay pareho. Iyon ang kailangan mo dahil magdaragdag ka ng TLS sa huli.

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

Payagan ang OpenSSH bago mong patakbuhin ang ufw enable. Bilang default, tinatanggihan ng ufw ang lahat ng papasok na network traffic. Kapag pinagana mo ito nang walang SSH rule, mapuputol ang sarili mong koneksyon sa sandaling maging aktibo ito. Mananatili ang kasalukuyang session, ngunit hindi ka na muling makakakonekta. Kumpirmahin gamit ang sudo ufw status. Dapat ay OpenSSH, Apache Full, at ang katumbas nilang v6 ay pawang may halagang ALLOW.

Hakbang 3 - I-install ang MariaDB at i-secure ito

sudo apt install -y mariadb-server
systemctl status mariadb

Ang Ubuntu 24.04 ay may kasamang MariaDB 10.11, isang long-term-support release, kaya hindi mo kailangan ng external repository. Kapag tumatakbo na ang service, i-harden ito:

sudo mysql_secure_installation

Basahin ang mga prompt sa halip na paulit-ulit na pindutin ang Enter. Kapag humingi ito ng kasalukuyang root password, pindutin ang Enter dahil wala pa itong password. Kapag tinanong ng "Switch to unix_socket authentication?", walang mababago sa sagot dahil naka-enable na ito sa package na ito, kaya pindutin ang n. Sagutin ng n ang "Change the root password?" para sa dahilang ipinaliliwanag sa susunod na talata. Pagkatapos, sagutin ng Y ang iba pang tanong: alisin ang mga anonymous user, huwag payagan ang remote root login, alisin ang test database, at i-reload ang privilege tables.

Ito ang bahaging nakalilito sa karamihan. Sa MariaDB ng Ubuntu, gumagamit ang root database account ng unix_socket authentication, hindi password. Ibig sabihin, pinagkakatiwalaan ng database ang operating-system user kung saan ka na-authenticate. Kaya gumagana ito mula sa root shell:

sudo mysql

...at ilalabas ka nito sa MariaDB [(none)]> prompt nang hindi humihingi ng password. Kapag pinatakbo ang parehong command bilang unprivileged user, tatanggihan ito. Iyan ang layunin: nakatali ang access sa database root sa sudo sa server, at walang password na maaaring nakawin, gamitin sa phishing, o hulaan sa pamamagitan ng brute-force. Mas secure ito kaysa password, kaya huwag itong baguhin. Ang kasunod na tuntunin: huwag kailanman gumamit ng root account para sa application. Gumawa ng dedicated user para sa bawat application (Hakbang 7), dahil hindi magagamit ng application na kumokonekta sa TCP gamit ang username at password ang socket auth. Dapat ding limitado ang bawat application sa sarili nitong database.

Hakbang 4 - I-install ang PHP 8.3 gamit ang PHP-FPM

Ang default na PHP ng Ubuntu 24.04 ay 8.3. I-install ang FPM process manager at ang mga extension na karaniwang kailangan ng isang app:

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

Pansinin kung ano ang wala sa listahang iyon: libapache2-mod-php. Ini-embed ng mas lumang package na ito ang PHP interpreter sa bawat Apache process. Simple ito, pero may dalang kopya ng PHP ang bawat worker, nagse-serve man ito ng script o static image. Magkasama rin ang lifecycle ng mga ito. Gumagana lamang ito sa prefork MPM ng Apache, na siyang hindi gaanong mahusay. Ang PHP-FPM naman ay nagpapatakbo ng PHP bilang sarili nitong pool ng mga process na kinakausap ng Apache gamit ang socket. Dahil dito, magagamit ng Apache ang threaded na event MPM para sa mga static file at ipapasa lamang ang mga PHP request. Hiwalay ding ita-tune ang pool mula sa web server. Magagamit din sa hinaharap ang eksaktong parehong FPM setup kung maglalagay ka ng nginx sa unahan. Ito ang kasalukuyang default dahil may mabuting dahilan.

Nakikipag-ugnayan ang Apache sa FPM gamit ang proxy_fcgi module. I-enable ito, i-enable ang config na inilagay ng FPM package, at mag-restart:

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

Ina-activate ng a2enconf php8.3-fpm ang /etc/apache2/conf-available/php8.3-fpm.conf, na naglalaman ng rule para i-route ang mga PHP file sa FPM socket. Tinutugma nito ang anumang .php file at ipinapasa ito sa socket sa /run/php/php8.3-fpm.sock:

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

Hindi mo kailangang i-edit ang file na iyon; tama na ang configuration nito. Ngunit mahalagang alam mo ang socket path para ma-diagnose ang mga error na “PHP downloads instead of running” at “Primary script unknown” sa susunod. Pareho itong nangyayari kapag hindi nagtutugma ang Apache at FPM tungkol sa socket na ito o sa file na nasa likod nito.

Hakbang 5 - Isang virtual host na nakabatay sa pangalan para sa iyong app

Hinahayaan ng name-based virtual hosting na maghatid ang isang IP ng maraming site; pinipili ng Apache ang site batay sa Host: header sa request. Gumawa ng directory para sa app, malayo sa default na /var/www/html:

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

Mahalaga ang ownership. Parehong tumatakbo ang Apache at PHP-FPM bilang user na www-data sa Ubuntu, kaya ang mga file na kailangang basahin ng web server at ang mga directory na kailangang sulatan ng app, gaya ng uploads folder, ay dapat pag-aari ng www-data. Kung mag-e-edit ka rin ng mga file gamit ang iyong login user, karaniwang pattern na ikaw ang magmay-ari ng mga file at idagdag ang iyong user sa www-data group; para sa plain deploy, ang www-data:www-data ang pinakaangkop.

Gawin ang virtual host sa /etc/apache2/sites-available/testapp.conf:

<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>

Itakda ang ServerName sa aktuwal mong domain. Pinipigilan ng Options -Indexes ang Apache na ilista ang directory kapag walang index file; kung hindi, maba-browse ng mga bisita ang iyong source tree. Hinahayaan ng AllowOverride All na gumana ang .htaccess file, na inaasahan ng karamihan sa PHP application para sa pretty URLs; gawin itong None para sa maliit na dagdag sa bilis kung hindi ito kailangan ng iyong app. I-enable ang site na ito, i-disable ang default, suriin ang config, at i-reload:

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

Dapat mag-print ang apache2ctl configtest ng Syntax OK. Ang linyang a2dissite 000-default ang madalas makalimutan, at ito ang dahilan kung bakit tila hindi nawawala ang default page sa susunod, gaya ng ipinaliwanag sa failures section.

Hakbang 6 - Patunayang gumagana ang PHP, pagkatapos ay tanggalin ang patunay

Maglagay ng isang-linyang PHP file sa root ng app:

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

Bisitahin ang http://app.example.com/info.php. Ang tamang resulta ay ang mahabang purple-at-gray na table na PHP Version 8.3.x, na naglilista ng mga naka-load na module, at ang linyang Server API ay may value na FPM/FastCGI. Kinukumpirma ng huling linyang iyon na dumadaan ang mga request sa PHP-FPM, hindi sa mod_php.

Tanggalin ito agad:

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

Inilalantad ng phpinfo() ang eksaktong bersyon ng PHP, lahat ng naka-load na extension, mga path ng file, at mga detalye ng environment. Impormasyon ito para sa sinumang sumusuri sa server upang makahanap ng bersyong may kilalang kahinaan. Pagsubok lamang ito, hindi feature. Tanggalin ito sa sandaling makita mo ang page. Kung sa halip na table ay inaalok ng browser na i-download ang info.php, hindi nakakonekta ang PHP sa Apache; pumunta muna sa seksyon ng mga failure bago gumawa ng iba pa.

Hakbang 7 - Gumawa ng database ng app at user na may pinakamababang pribilehiyo

Buksan ang database bilang root na authenticated sa pamamagitan ng socket:

sudo mysql

Pagkatapos, gumawa ng isang database at isang user na eksaktong nakatalaga sa database na iyon:

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;

May tatlong sinadyang pagpili rito. Ang utf8mb4 ay totoong four-byte UTF-8. Tahimik na pinuputol ng lumang utf8 alias ang emoji at ilang CJK character, kaya laging gamitin ang utf8mb4. Ang grant ay nasa appdb.*, hindi *.*: maa-access lamang ng user na ito ang sarili nitong database at wala nang iba, kaya hindi mababasa ng SQL-injection hole sa app ang mga table ng iba pang site. Nililimitahan naman ng 'appuser'@'localhost' ang account sa mga connection na nagmumula mismo sa server.

Subukan ito bilang user na iyon:

mysql -u appuser -p appdb

Hihingi ito ng password at dadalhin ka sa MariaDB [appdb]> prompt. Pansinin na walang -h flag. Huwag itong idagdag; kumokonekta ang client sa pamamagitan ng lokal na Unix socket, na itinuturing mismo ng MariaDB bilang localhost. Mahalagang tandaan: para sa MySQL at MariaDB, ang localhost ay nangangahulugang Unix socket at ang 127.0.0.1 ay nangangahulugang TCP connection. Sa karaniwang Ubuntu 24.04 MariaDB, nire-resolve pa rin ng server ang TCP connection mula sa 127.0.0.1 pabalik sa localhost, kaya parehong tumutugma ang mga ito sa account. Ngunit sa mga server na may naka-enable na skip-name-resolve, isang karaniwang performance tweak at karaniwan sa maraming container image, itinuturing ang dalawang ito bilang magkaibang host. Kapag kumonekta ang app sa 127.0.0.1, tatanggihan ito gamit ang ERROR 1045 (28000): Access denied for user 'appuser'@'127.0.0.1' (using password: YES) kahit tama ang password.

Ituro ang application sa host na localhost, user na appuser, at database na appdb, at huwag kailanman sa root. Parehong lumilipat ang PHP's mysqli at PDO sa Unix socket kapag ang host ay literal na string na localhost, kaya tumutugma ito sa account na ginawa mo. Kung iginiit ng framework ang numeric TCP host, gawin ang user ayon sa aktuwal na paraan ng pagkonekta nito: 'appuser'@'127.0.0.1', o @'%' na sinamahan ng firewall rule kung kailangan nitong maabot ang database mula sa ibang machine.

Hakbang 8 - Magdagdag ng HTTPS gamit ang Certbot

Ang paghahatid ng login form sa plain HTTP ay nagpapadala ng mga password bilang clear text, at minamarkahan ng bawat modernong browser ang page bilang "Not secure". Inaayos ito ng Certbot gamit ang isang command. I-install ito kasama ang Apache plugin:

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

Dalawang plugin ang ginagamit dito ng Certbot. Pinatutunayan ng apache authenticator na kontrolado mo ang domain sa pamamagitan ng pansamantalang paghahatid ng challenge file gamit ang tumatakbong Apache. Pagkatapos, nire-rewrite ng apache installer ang iyong virtual host upang idagdag ang 443 block, ituro ito sa bagong certificate, at i-redirect bilang default ang lahat ng HTTP traffic sa HTTPS. Mula sa Certbot 2.0, wala nang redirect question; ipasa ang --no-redirect kung kailangan mong patuloy na maghatid ng plain HTTP. Dahil nagtakda ka ng aktuwal na ServerName sa Hakbang 5, awtomatikong nade-detect ng Certbot ang domain. Tumatagal nang 90 days ang mga certificate, at nag-i-install ang package ng systemd timer para i-renew ang mga ito. I-verify ang timer gamit ang sudo certbot renew --dry-run; dapat magtapos ito sa Congratulations, all simulated renewals succeeded.

Para sa buong walkthrough ng challenge, renewal timer, at mga kinakailangan sa DNS at firewall, tingnan ang kaugnay na gabay tungkol sa pag-isyu ng libreng Let's Encrypt TLS certificates gamit ang Certbot sa Apache.

Mga backup, upgrade, at hardening

I-back up ang dalawang naglalaman ng state: ang mga database at ang web root. Ang nightly logical dump ang pinakasimple at maaasahang paraan, sudo sh -c 'mysqldump --all-databases --single-transaction | gzip > /root/db-$(date +%F).sql.gz', pagkatapos ay kopyahin ito palabas ng server. Mahalaga ang pagbalot sa buong pipeline sa sudo sh -c: kung wala ito, pinapatakbo ng shell ang > /root/... redirect bilang sarili mong user at nabibigo sa Permission denied, dahil mysqldump lamang ang nagmana ng sudo. Nagbibigay ang --single-transaction ng consistent na snapshot ng mga InnoDB table nang hindi nilo-lock ang mga ito. Isama rito ang tar ng /var/www at /etc/apache2/sites-available, at maaari mong buuin muli ang buong stack sa bagong VPS mula sa mga file na iyon.

Ang mga upgrade ay karaniwang sudo apt update && sudo apt upgrade. Ang problemang dapat bantayan ay ang PHP version bump, kapag inilipat ng susunod na Ubuntu ang default sa PHP 8.4. Maaaring i-install ng apt ang php8.4-fpm kasabay ng 8.3, maging /run/php/php8.4-fpm.sock ang socket, at manatiling nakaturo ang Apache config sa socket ng 8.3. I-enable ang bagong conf (sudo a2enconf php8.4-fpm) at i-disable ang luma; kung hindi, magsisimulang magbalik ang site ng Primary script unknown pagkatapos ng karaniwang upgrade. Dahil mas mabilis maglabas ng bagong bersyon ang PHP kaysa sa isang LTS distro, tingnan ang kasalukuyang PHP release notes sa halip na mag-pin ng patch version.

Dalawang hakbang sa hardening ang dapat gawin sa unang araw. Una, ilagay ang Fail2Ban para mag-monitor ng SSH sa server. Ang isang public VPS ay nakakatanggap ng mga automated login attempt sa loob ng ilang minuto, at ginagawang iilang pagtatangka lamang ng isang maliit na jail ang libo-libong attempt bago magpatupad ng ban. Ikalawa, kung mas gusto mong pamahalaan ang Apache virtual host, MariaDB database, at user sa browser kaysa manu-manong mag-edit ng mga file, nasa ibabaw ng eksaktong stack na ito ang Webmin web-based control panel at ginagamit nito ang parehong config file na isinulat mo. Hindi nito pinapalitan ang pag-unawa sa mga bahagi, ngunit kapwa binabawasan ng mga ito ang abala sa pang-araw-araw na pamamahala.

Mga failure mode, kasama ang mga string na makikita mo

Hindi nawawala ang default page. Inedit mo ang virtual host at nag-reload, ngunit ipinapakita pa rin ng browser ang "Apache2 Ubuntu Default Page" at ang banner nitong "It works!". Ise-serve ng Apache ang unang tumutugmang virtual host. Kapag walang ServerName na tumutugma sa request, ang unang config ayon sa alphabetical order ang ginagamit; nauuna ang 000-default.conf sa testapp.conf. Maaaring hindi tumutugma ang host name ng request sa iyong ServerName, o hindi mo kailanman pinatakbo ang sudo a2dissite 000-default. I-disable ang default gamit ang sudo systemctl reload apache2, at kumpirmahin gamit ang apache2ctl -S. Ipi-print nito ang vhost map at ipapakita kung aling config ang nagmamay-ari ng default. I-clear din ang browser cache. Maaaring patuloy nitong ipakita ang naka-cache na 200 response mula sa lumang page.

Dina-download sa halip na pinapatakbo ang .php file. Binubuksan mo ang info.php, ngunit nagda-download ang browser ng file na naglalaman ng raw <?php source, o ipinapakita ito bilang plain text, sa halip na patakbuhin ito. Ise-serve ng Apache ang file bilang static asset dahil hindi naka-attach ang PHP handler, nilaktawan mo ang sudo a2enmod proxy_fcgi, o sudo a2enconf php8.3-fpm, o hindi mo na-restart ang Apache pagkatapos. Patakbuhin ang tatlo (Step 4) at mag-reload. Kumpirmahing naka-load ang module gamit ang apache2ctl -M | grep fcgi. Dapat nitong ilista ang proxy_fcgi_module. Source-code leak ito, hindi simpleng cosmetic bug, kaya ayusin ito bago maglagay ng aktuwal na application sa server.

ERROR 1698 (28000): Access denied for user 'root'@'localhost'. Pinatakbo mo ang mysql -u root o mariadb -u root nang walang sudo. Gumagamit ang root account ng unix_socket authentication. Tumatanggap lamang ito sa iyo kapag ang OS user mo ay aktuwal na root. Ang solusyon ay sudo mysql, walang -u root at walang password. Inaasahang behavior ito ng gumaganang socket authentication, hindi senyales ng sirang installation.

ERROR 1045 (28000): Access denied for user 'appuser'@'127.0.0.1' mula sa application, kahit tama ang password. Umiiral ang account bilang 'appuser'@'localhost', ngunit kumokonekta ang app sa pamamagitan ng TCP sa 127.0.0.1 sa server na naka-disable ang host-name resolution (skip-name-resolve). Dahil dito, itinuturing ng MariaDB na magkaibang host ang dalawa: ang localhost ay Unix socket, samantalang ang 127.0.0.1 ay TCP. Ituro ang app sa host na localhost upang gamitin nito ang socket at tumugma sa account, o gumawa ng ikalawang account na 'appuser'@'127.0.0.1' kung TCP lamang ang sinusuportahan ng framework.

AH01071: Got error 'Primary script unknown' sa /var/log/apache2/testapp-error.log, habang ipinapakita ng browser ang File not found.. Ipinasa ng Apache ang request sa PHP-FPM, ngunit hindi mahanap ng FPM ang script sa path na ibinigay ng Apache. Dalawa ang karaniwang sanhi: nakaturo ang FPM socket sa iyong config sa PHP version na hindi naka-install (isang php8.4 socket pagkatapos ng upgrade habang 8.3 lamang ang tumatakbo), o tunay na wala ang file dahil hindi nagtutugma ang DocumentRoot at ang aktuwal na directory. Suriing umiiral ang socket gamit ang ls -l /run/php/, kumpirmahing tumutugma ang DocumentRoot sa lokasyon ng file, at i-restart ang php8.3-fpm at apache2.

AH00558: apache2: Could not reliably determine the server's fully qualified domain name sa bawat restart. Harmless warning ito, hindi error. Sinasabi ng Apache na walang nakatakdang global ServerName. Patahimikin ito sa pamamagitan ng pagsulat ng ServerName your.domain sa /etc/apache2/conf-available/servername.conf at pagpapatakbo ng sudo a2enconf servername.

(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80 kapag nagsisimula ang Apache. May isa pang web server na gumagamit na ng port 80, kadalasan ay naiwan na nginx mula sa dating experiment. Hanapin ito gamit ang sudo ss -ltnp | grep :80, pagkatapos ay ihinto at i-disable ang ibang service bago simulan ang Apache.

FAQ

mod_php o PHP-FPM — alin ang dapat kong gamitin?

Gamitin ang PHP-FPM. mod_php ay nag-i-embed ng interpreter sa bawat Apache process at nagpipilit ng mabagal na prefork MPM, kaya may PHP overhead ang Apache kahit static image ang sine-serve. Pinapatakbo ng PHP-FPM ang PHP bilang hiwalay at maaaring i-tune na pool na ina-access ng Apache sa pamamagitan ng socket. Gumagana ito sa mas mabilis na threaded event MPM at madali itong ilipat sa nginx sa hinaharap. Ito ang modern default. Ang mod_php ay angkop lamang sa legacy app na umaasa sa ilang in-process behavior.

Bakit dina-download ng browser ko ang PHP file sa halip na patakbuhin ito?

Itinuturing ng Apache ang .php file bilang static download dahil walang PHP handler na nakakabit dito. Sa Ubuntu 24.04 na gumagamit ng FPM, nangangahulugan itong nakaligtaan mo ang isa sa sudo a2enmod proxy_fcgi, sudo a2enconf php8.3-fpm, o ang pag-restart ng Apache pagkatapos nito. Patakbuhin ang tatlo at mag-reload. Pagkatapos, i-verify gamit ang apache2ctl -M | grep fcgi na nakalista ang proxy_fcgi_module. Hangga't hindi ito naaayos, inilalantad ng server ang source code, kaya ituring itong urgent.

Bakit tinatanggihan ang root access sa MariaDB kahit tama ang password?

Dahil walang password, ina-authenticate ng MariaDB sa Ubuntu ang root account gamit ang unix_socket. Iniuugnay nito ang account sa root user ng operating system. Ang mysql -u root mula sa normal shell ay nagbabalik ng ERROR 1698 (28000): Access denied for user 'root'@'localhost' ayon sa disenyo. Sa halip, kumonekta gamit ang sudo mysql. Gumawa ng hiwalay na user na gumagamit ng password authentication para sa anumang application sa halip na gamitin muli ang root.

Paano ako magdaragdag ng HTTPS sa aking LAMP site?

I-install ang certbot at python3-certbot-apache. Ituro ang A record ng domain sa server, pagkatapos ay patakbuhin ang sudo certbot --apache. Pinatutunayan ng apache authenticator ang pagmamay-ari sa domain sa pamamagitan ng tumatakbo mong Apache. Pagkatapos, ina-update ng installer ang virtual host para sa port 443 at nagse-set up ng automatic renewal. Sinasaklaw ng kumpletong Certbot at Apache walkthrough ang challenge, renewal timer, at mga karaniwang failure mode.