Paano mag-install ng LAMP stack sa Ubuntu 24.04

Ang iyong bubuuin

Ang LAMP stack ay binubuo ng apat na bahagi sa isang Ubuntu 24.04 server: Linux bilang base, Apache para sa HTTP, MariaDB para sa data, at PHP 8.3 para sa pagtakbo ng code. Pagkatapos ng tutorial na ito, magkakaroon ka ng name-based virtual host na nagse-serve ng application directory, database na may dedicated least-privilege user, PHP na naka-wire sa Apache gamit ang PHP-FPM, at libreng Let's Encrypt certificate.

Ang installation ay binubuo ng apat na apt commands. Halos lahat ng nasa guide na ito ay tungkol sa pag-uugnay ng mga bahagi, at ang mga karaniwang pagkakamali na nagiging sanhi ng blank page, pag-download ng source code sa browser, o pagka-block sa database. Ang bawat error ay may partikular na senyales, at nakalista sa ibaba ang eksaktong text na makikita mo.

Mga Prerequisites at ang mga dapat tandaan

Ipagpalagay na mayroon kang bagong Ubuntu 24.04 KVM VPS na may sudo user o root, at may public IPv4 address. Ang minimal stack ay gumagamit ng 1 GB na RAM; bigyan ito ng 2 GB bago mag-install ng application na may database, dahil mabilis maubos ang unang gigabyte dahil sa default buffers ng MariaDB at sa ilang PHP-FPM workers.

Kailangang maayos ang dalawang bagay bago gumana ang Certbot sa dulo, kaya ihanda na ang mga ito ngayon. Kailangan mo ng domain name na may A record na nakaturo sa public IP ng VPS — nagve-validate ang Let's Encrypt via HTTP sa pangalang iyon, at hindi kailanman makakakuha ng certificate ang isang bare IP address lamang. Dapat ding ma-access ang mga port na 80 at 443 mula sa internet; sa maraming provider, nangangahulugan ito na kailangang buksan ang mga ito sa network firewall sa control panel pati na rin sa ufw sa mismong server. Ang mga pagbabago sa DNS ay maaaring tumagal ng hanggang isang oras bago mag-propagate, kaya i-set muna ang A record para handa na ito pagdating ng oras na kailangan mo na ito.

Step 1 - I-install ang Apache at i-confirm ang default page

sudo apt update
sudo apt install -y apache2

Sinasimulan at ina-enable ng apt ang service para sa iyo. I-check ito:

systemctl status apache2

Dapat ay may makikita kang linya na active (running). Ngayon, i-open ang http://YOUR_SERVER_IP/ sa isang browser. Ang Apache2 Ubuntu Default Page na may malaking "It works!" banner ang tamang resulta — patunay ito na gumagana ang Apache at hindi ito error. Ang page na iyon ay nasa /var/www/html/index.html at sineserbisyo ng default virtual host na 000-default.conf. I-di-disable ang mga ito mamaya; sa ngayon, kailangan mong makita ang mga ito.

Kung hindi naglo-load ang page kahit na sinasabi ng systemctl na running ang process, may firewall na humaharang. Iyan ang susunod na step.

Step 2 - Buksan ang firewall para sa HTTP at HTTPS

Ang apache2 package ay nagrerehistro ng tatlong ufw application profiles. I-list ang mga ito:

sudo ufw app list

Makikita mo ang Apache, Apache Full, at Apache Secure. Ang Apache ay para sa port 80 lamang, ang Apache Secure ay para sa 443 lamang, at ang Apache Full ay para sa dalawa — ito ang kailangan mo dahil magdadagdag ka ng TLS sa huli.

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

I-allow ang OpenSSH bago i-run ang ufw enable. Ang ufw ay naka-default na i-deny ang lahat ng incoming traffic. Kapag na-enable ito nang walang SSH rule, mapuputol ang iyong connection sa sandaling ma-activate ito — mananatili ang kasalukuyang session pero hindi ka na makakapag-reconnect. I-confirm gamit ang sudo ufw status; dapat ang OpenSSH, Apache Full, at ang kanilang mga v6 equivalent ay lahat ay ALLOW.

Step 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 na kailangan ng external repository. Kapag tumatakbo na ang service, i-harden ito:

sudo mysql_secure_installation

Mas mabuting basahin ang mga prompt kaysa pindutin lang ang Enter. Kapag tinanong ang current root password, pindutin ang Enter — wala pa itong password. Kapag tinanong ang "Switch to unix_socket authentication?", walang mababago dahil naka-enable na ito sa package na ito, kaya pindutin ang n. Sagutin ang n sa "Change the root password?" dahil sa dahilan sa susunod na talata, pagkatapos ay sagutin ang Y sa iba pa: alisin ang mga anonymous user, i-disallow ang remote root login, burahin ang test database, at i-reload ang privilege tables.

Ito ang bahaging nakakalito sa lahat. Sa MariaDB ng Ubuntu, ang root database account ay gumagamit ng unix_socket authentication sa halip na password. Ibig sabihin, pinagkakatiwalaan ng database ang operating-system user na na-authenticate mo na. Kaya gumagana ito mula sa isang root shell:

sudo mysql

...at dadalhin ka nito sa isang MariaDB [(none)]> prompt nang hindi nagtatanong ng password. Ang parehong command na patakbuhin bilang unprivileged user ay tatanggihan, na siyang pangunahing layunin: ang access sa database root ay nakatali sa sudo sa machine, at walang password na maaaring manakaw, ma-phish, o ma-brute-force. Mas secure ito kaysa sa password, kaya huwag itong galawin. Ang rule na nagmumula rito: huwag na huwag ituturo ang isang application sa root account. Gumawa ng dedicated user para sa bawat application (Step 7), dahil ang isang app na kumokonekta via TCP gamit ang username at password ay hindi naman magagamit ang socket auth, at kailangan mong limitahan ang bawat app sa sarili nitong database.

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

Ang default PHP ng Ubuntu 24.04 ay 8.3. I-install ang FPM process manager at ang mga extension na kailangan ng karaniwang 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

Tandaan kung ano ang wala sa listahang iyon: libapache2-mod-php. Ang lumang package na iyon ay naglalagay ng PHP interpreter sa loob ng bawat Apache process. Simple ito, pero bawat worker ay may dalang kopya ng PHP kahit nagse-serve lang ito ng static image. Magkasama ang dalawa sa iisang lifecycle, at gumagana lang ito sa Apache's prefork MPM — ang pinaka-hindi efficient. Sa halip, ang PHP-FPM ay nagpapatakbo ng PHP bilang sariling pool ng mga processes na kinakausap ng Apache sa pamamagitan ng isang socket. Dahil dito, maaaring gamitin ng Apache ang threaded event MPM para sa mga static files at ipapasa na lang ang mga PHP requests. Ang pool ay naka-tune nang hiwalay sa web server, at ang parehong FPM setup ay gagana rin kung gagamit ka ng nginx sa harap. Ito ang kasalukuyang default dahil sa mga rason na ito.

Nararating ng Apache ang FPM sa pamamagitan ng proxy_fcgi module. I-enable ito, i-enable ang config na kasama sa FPM package, at i-restart:

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

I-aactivate ng a2enconf php8.3-fpm ang /etc/apache2/conf-available/php8.3-fpm.conf, na naglalaman ng rule na nag-i-route ng mga PHP file sa FPM socket. Ang pangunahing bahagi nito ay nagma-match sa 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>

Huwag i-edit ang file na iyon; tama na ang default nito. Ngunit ang pag-alam sa socket path ang magbibigay-daan sa iyo para ma-diagnose ang mga error na "PHP downloads instead of running" at "Primary script unknown" sa hinaharap — parehong sanhi ang hindi pagkakasundo ng Apache at FPM tungkol sa socket na ito o sa file sa likod nito.

Step 5 - Isang name-based virtual host para sa iyong app

Sa name-based virtual hosting, ang isang IP ay maaaring mag-serve ng maraming sites; pinipili ng Apache ang site gamit ang 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. Ang Apache at PHP-FPM ay parehong tumatakbo bilang www-data user sa Ubuntu, kaya ang mga file na dapat basahin ng web server — at mga directory na dapat sulatan ng app, gaya ng uploads folder — ay dapat pagmamay-ari ng www-data. Kung i-eedit mo rin ang mga file gamit ang iyong login user, isang karaniwang pattern ang pagmamay-ari ng files sa iyong sarili at pagdagdag sa iyong user sa www-data group; para sa simpleng deploy, ang www-data:www-data ang pinakaligtas na opsyon.

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

I-set ang ServerName sa iyong totoong domain. Pinipigilan ng Options -Indexes ang pag-list ng Apache sa directory kapag walang index file — kung hindi, mababasa ng mga bisita ang iyong source tree. Pinapagana ng AllowOverride All ang isang .htaccess file, na inaasahan ng karamihan sa mga PHP application para sa pretty URLs; i-drop ito sa None para sa kaunting bilis kung hindi ito kailangan ng iyong app. I-enable ang site na ito, i-disable ang default, i-check 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 a2dissite 000-default line ang madalas makalimutan ng mga tao, at ito ang dahilan kung bakit tila hindi nagbabago ang default page — tatalakayin ito sa failures section.

Step 6 - Patunayan na tumatakbo ang PHP, pagkatapos ay burahin ang proof

Gumawa ng one-line PHP file sa app root:

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

I-visit ang http://app.example.com/info.php. Ang tamang resulta ay ang mahabang purple-and-grey PHP Version 8.3.x table na naglilista ng iyong mga loaded modules, kung saan ang Server API line ay dapat FPM/FastCGI. Kinukumpirma ng huling linyang iyon na ang mga request ay dumadaan sa PHP-FPM, hindi sa mod_php.

Ngayon ay burahin agad ito:

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

Ibinubunyag ng phpinfo() ang eksaktong PHP version mo, lahat ng loaded extension, file paths, at environment details — isang panganib sa sinumang mag-i-scan sa server para sa version na may kilalang vulnerability. Ito ay para sa testing lamang, hindi isang feature. Burahin ito agad pagkatapos makita ang page. Kung sa halip na table ay nag-alok ang browser na i-download ang info.php, hindi naka-wire ang PHP sa Apache; pumunta sa failures section bago gumawa ng kahit ano.

Step 7 - Gumawa ng app database at least-privilege user

Buksan ang database gamit ang socket-authenticated root:

sudo mysql

Pagkatapos, gumawa ng isang database at isang user na limitado lamang 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 mahahalagang desisyon dito. Ang utf8mb4 ay totoong four-byte UTF-8 — ang lumang utf8 alias ay tahimik na nagka-truncate ng mga emoji at ilang CJK characters, kaya laging gamitin ang utf8mb4. Ang grant ay para sa appdb.*, hindi sa *.*: ang user na ito ay maaari lamang mag-access sa sarili nitong database at wala nang iba, kaya ang SQL-injection vulnerability sa app ay hindi makakabasa ng mga table ng ibang site. At ang 'appuser'@'localhost' ay naglilimita sa account sa mga connection na nanggagaling mismo sa machine na ito.

I-test ito gamit ang user na iyon:

mysql -u appuser -p appdb

Hihingin nito ang password at dadalhin ka sa isang MariaDB [appdb]> prompt. Pansinin na walang -h flag — huwag itong isama para kumonekta ang client sa pamamagitan ng local Unix socket, na siyang itinuturing ng MariaDB bilang localhost. Isang mahalagang detalye: para sa MySQL at MariaDB, ang localhost ay nangangahulugang Unix socket at ang 127.0.0.1 ay isang TCP connection. Sa stock Ubuntu 24.04 MariaDB, ang server ay nagre-resolve pa rin ng TCP connection mula sa 127.0.0.1 pabalik sa localhost, kaya parehong tugma sa account — ngunit sa mga server na may enabled na skip-name-resolve (isang karaniwang performance tweak, at standard sa maraming container images), ang dalawa ay itinuturing na magkaibang hosts, at ang app na kumokonekta sa 127.0.0.1 ay tatanggihan sa pamamagitan ng ERROR 1045 (28000): Access denied for user 'appuser'@'127.0.0.1' (using password: YES) kahit tama ang password.

Kaya i-set ang iyong application sa host na localhost, user na appuser, at database na appdb — huwag kailanman sa root. Ang mysqli ng PHP at ang PDO ay parehong lumilipat sa Unix socket kapag ang host ay ang literal na string na localhost, na tugma sa account na ginawa mo. Kung ang isang framework ay nangangailangan ng numeric TCP host, gumawa ng user na tugma sa paraan kung paano ito kumokonekta — 'appuser'@'127.0.0.1', o @'%' (kasama ang isang firewall rule) kung kailangan lang nitong maabot ang database mula sa ibang machine.

Step 8 - Magdagdag ng HTTPS gamit ang Certbot

Ang paggamit ng plain HTTP para sa login form ay nagpapadala ng mga password sa clear text. Dahil dito, lalabas ang warning na "Not secure" sa mga modernong browser. Maaaring ayusin ito ng Certbot gamit ang isang command. I-install ito gamit ang Apache plugin:

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

Gumagamit ang Certbot ng dalawang plugin dito. Ang apache authenticator ay nagpapatunay na kontrolado mo ang domain sa pamamagitan ng pag-serve ng challenge file gamit ang tumatakbong Apache. Ang apache installer naman ay magre-rewrite ng iyong virtual host para idagdag ang 443 block, ituro ito sa bagong certificate, at i-redirect ang lahat ng HTTP traffic sa HTTPS by default. Simula sa Certbot 2.0, wala nang tanong tungkol sa redirect; gamitin ang flag na --no-redirect kung kailangang manatili ang plain HTTP. Dahil nag-set ka ng totoong ServerName sa Step 5, awtomatikong makikita ng Certbot ang domain. Ang mga certificate ay tumatagal ng 90 araw at ang package ay nag-i-install ng systemd timer para sa renewal; i-verify ang timer gamit ang sudo certbot renew --dry-run, na dapat magtapos sa Congratulations, all simulated renewals succeeded.

Para sa buong walkthrough tungkol sa challenge, renewal timer, at mga DNS at firewall requirements, tingnan ang companion guide sa pag-issue ng libreng Let's Encrypt TLS certificates gamit ang Certbot sa Apache.

Backups, upgrades, and hardening

I-back up ang dalawang bagay na naglalaman ng iyong state: ang mga database at ang web root. Ang nightly logical dump ang pinakasimpleng paraan — sudo sh -c 'mysqldump --all-databases --single-transaction | gzip > /root/db-$(date +%F).sql.gz', pagkatapos ay i-copy palabas ng box. Mahalaga ang paggamit ng sudo sh -c sa buong pipeline: kung wala ito, tatakbo ang shell gamit ang > /root/... redirect bilang iyong user at mag-eerror sa Permission denied, dahil ang mysqldump lang ang may hawak ng sudo. Nagbibigay ang --single-transaction ng consistent na snapshot ng mga InnoDB tables nang hindi sila nino-lock. Ipares ito sa isang tar ng /var/www at /etc/apache2/sites-available, at maaari mong i-rebuild ang buong stack sa isang bagong VPS gamit ang mga file na ito.

Ang mga upgrade ay karaniwang sudo apt update && sudo apt upgrade. Ang mahirap ay ang PHP version bump — kapag ginawang default ng susunod na Ubuntu ang PHP 8.4, maaaring i-install ng apt ang php8.4-fpm kasabay ng 8.3, magiging /run/php/php8.4-fpm.sock ang socket, at ang Apache config mo ay nakaturo pa rin sa 8.3 socket. I-enable ang bagong conf (sudo a2enconf php8.4-fpm) at i-disable ang luma, kung hindi ay magbabalik ang site mo ng Primary script unknown pagkatapos ng upgrade. Dahil mas mabilis ang release ng PHP kaysa sa LTS distro, mas mabuting i-check ang current PHP release notes kaysa mag-pin ng patch version.

May dalawang hardening steps na dapat gawin agad. Una, mag-install ng Fail2Ban para sa pag-monitor ng SSH sa box — ang mga public VPS ay nakakatanggap ng automated login attempts sa loob ng ilang minuto, at ang isang maliit na jail ay gagawing iilang attempts na lang ang libo-libong subok bago ang ban. Pangalawa, kung mas gusto mong i-manage ang Apache virtual hosts, MariaDB databases, at users gamit ang browser kaysa sa manual na pag-edit ng files, ang Webmin web-based control panel ay gumagana sa mismong stack na ito at gumagamit ng parehong config files na isinulat mo. Hindi nito pinapalitan ang pag-unawa sa bawat bahagi, pero binabawasan nito ang day-to-day friction.

Failure modes, with the strings you will see

Hindi mawala ang default page. Nag-edit ka ng virtual host at nag-reload, pero ang nakikita pa rin sa browser ay ang "Apache2 Ubuntu Default Page" at ang "It works!" banner nito. Ise-serve ng Apache ang unang matching virtual host. Kapag walang ServerName na tumutugma sa request, ang unang config sa alphabetical order ang gagamitin — ang 000-default.conf ay nauuna sa testapp.conf. Maaaring hindi tugma ang host name ng request sa iyong ServerName, o hindi mo pinatakbo ang sudo a2dissite 000-default. I-disable ang default, sudo systemctl reload apache2, at i-verify gamit ang apache2ctl -S, na magpi-print ng vhost map at magpapakita kung aling config ang may-ari ng default. I-clear din ang browser cache; ang cached 200 mula sa lumang page ay maaaring manatili.

Nagda-download ang .php file sa halip na mag-run. Binuksan mo ang info.php pero ang dina-download ng browser ay file na naglalaman ng raw <?php source, o ipinapakita ito bilang plain text sa halip na i-execute. Ise-serve ng Apache ang file bilang static asset dahil hindi naka-attach ang PHP handler — nalaktawan mo ang sudo a2enmod proxy_fcgi, o ang sudo a2enconf php8.3-fpm, o hindi mo ni-restart ang Apache pagkatapos. Patakbuhin ang tatlong ito (Step 4) at mag-reload. I-verify kung loaded ang module gamit ang apache2ctl -M | grep fcgi, kung saan dapat nakalista ang proxy_fcgi_module. Ito ay isang source-code leak at hindi lamang cosmetic bug, kaya ayusin ito bago maglagay ng totoong data sa server.

ERROR 1698 (28000): Access denied for user 'root'@'localhost'. Nagpatakbo ka ng mysql -u root o mariadb -u root nang walang sudo. Gumagamit ang root account ng unix_socket auth, kaya tatanggapin ka lang nito kung ang OS user mo ay root talaga. Ang solusyon ay sudo mysql — walang -u root, walang password. Ang mensaheng ito ay inaasahang behavior ng socket auth na gumagana nang tama, hindi ito broken install.

ERROR 1045 (28000): Access denied for user 'appuser'@'127.0.0.1' mula sa application, gamit ang tamang password. Ang account ay umiiral bilang 'appuser'@'localhost', pero ang app mo ay kumokonekta via TCP sa 127.0.0.1 sa isang server kung saan naka-disable ang host-name resolution (skip-name-resolve). Dahil dito, ituturing ng MariaDB na magkaibang hosts ang dalawa — ang localhost ay ang Unix socket, ang 127.0.0.1 ay TCP. Ituro ang app sa host na localhost para gumamit ito ng socket at magtugma sa account, o gumawa ng pangalawang account na 'appuser'@'127.0.0.1' kung TCP lang ang suportado ng framework.

AH01071: Got error 'Primary script unknown' sa /var/log/apache2/testapp-error.log, kung saan ang browser ay nagpapakita ng File not found.. Ipinasa ng Apache ang request sa PHP-FPM, pero hindi mahanap ng FPM ang script sa path na ibinigay ng Apache. Dalawang karaniwang sanhi: ang FPM socket sa iyong config ay nakaturo sa PHP version na hindi naka-install (isang php8.4 socket pagkatapos ng upgrade kung 8.3 lang ang tumatakbo), o wala talaga ang file dahil hindi tugma ang DocumentRoot at ang totoong directory. I-check kung existing ang socket gamit ang ls -l /run/php/, i-confirm kung tugma 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. Ito ay isang harmless warning, hindi error — sinasabi ng Apache na walang global ServerName na naka-set. I-silence ito sa pamamagitan ng pagsulat ng ServerName your.domain sa /etc/apache2/conf-available/servername.conf at pagtakbo ng sudo a2enconf servername.

(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80 kapag nag-start ang Apache. May isa pang web server na gumagamit ng port 80 — madalas ay isang stray nginx mula sa nakaraang experiment. Hanapin ito gamit ang sudo ss -ltnp | grep :80, pagkatapos ay i-stop at i-disable ang kabilang service bago i-start ang Apache.

FAQ

mod_php o PHP-FPM - alin ang dapat gamitin?

Gamitin ang PHP-FPM. Isinasama ng mod_php ang interpreter sa bawat Apache process at pinipilit ang mabagal na prefork MPM, kaya may PHP overhead ang Apache kahit nagse-serve lang ito ng static image. Ang PHP-FPM ay nagpapatakbo ng PHP bilang isang hiwalay at independently tuned na pool na ina-access ng Apache via socket, gumagana kasama ang mas mabilis na threaded event MPM, at madaling maililipat sa nginx sa hinaharap. Ito ang modernong default; ang mod_php ay para lamang sa mga legacy app na nangangailangan ng in-process behaviour.

Bakit dinidownload ng browser ko ang PHP file sa halip na i-run ito?

Itinuturing ng Apache ang .php file bilang isang static download dahil walang PHP handler na naka-attach dito. Sa Ubuntu 24.04 na may FPM, ibig sabihin nito ay nakalimutan mo ang isa sa sudo a2enmod proxy_fcgi, sudo a2enconf php8.3-fpm, o ang Apache restart pagkatapos. I-run ang tatlong ito at i-reload, pagkatapos ay i-verify gamit ang apache2ctl -M | grep fcgi kung naka-list ang proxy_fcgi_module. Hangga't hindi ito naaayos, naglalabas ang server ng source code, kaya ituring itong urgent.

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

Dahil walang password — ginagamit ng MariaDB sa Ubuntu ang unix_socket para i-authenticate ang root account, na nakakabit sa root user ng operating system. Ang mysql -u root mula sa normal na shell ay magbabalik ng ERROR 1698 (28000): Access denied for user 'root'@'localhost' ayon sa disenyo nito. Kumonekta gamit ang sudo mysql sa halip, at gumawa ng hiwalay na user na may password authentication para sa anumang application sa halip na gamitin ang root.

Paano magdagdag ng HTTPS sa aking LAMP site?

I-install ang certbot at python3-certbot-apache, ituro ang A record ng domain sa server, at i-run ang sudo certbot --apache. Pinapatunayan ng apache authenticator ang domain control sa pamamagitan ng iyong running Apache at binabago ng installer ang virtual host para sa port 443 at inaayos ang automatic renewal. Ang full Certbot at Apache walk-through ay sumasaklaw sa challenge, sa renewal timer, at sa mga karaniwang failure modes.