Jinsi ya Kusakinisha LAMP kwenye Ubuntu 24.04

Unachojenga

LAMP stack ina vipengele vinne vinavyofanya kazi kwenye server moja ya Ubuntu 24.04: Linux iliyo chini, Apache inayojibu HTTP, MariaDB inayohifadhi data, na PHP 8.3 inayoendesha code. Mwishoni utakuwa na virtual host inayotumia jina na kuhudumia directory halisi ya application, database yenye user maalum mwenye privileges chache zinazohitajika, PHP iliyounganishwa na Apache kupitia PHP-FPM, pamoja na certificate ya bure ya Let's Encrypt.

Usakinishaji wenyewe unahitaji commands nne za apt. Karibu kila kitu katika mwongozo huu kinahusu kuunganisha vipengele hivyo na makosa machache yanayoweza kufanya stack mpya ihudumie ukurasa tupu, ikamkabidhi browser source code kama download, au ikukatalie kuingia kwenye database uliyosakinisha. Kila tatizo lina dalili unayoweza kuitambua, na kila moja limeelezwa hapa chini pamoja na maandishi halisi utakayoona.

Masharti ya awali na mambo muhimu ya kuzingatia

Chukulia kuwa una Ubuntu 24.04 mpya kwenye KVM VPS, ukiwa na mtumiaji mwenye sudo au root, pamoja na anwani ya umma ya IPv4. Stack ndogo inaweza kufanya kazi kwa RAM ya 1 GB; ipe 2 GB kabla ya kuweka programu halisi inayotumia database, kwa sababu buffers za chaguo-msingi za MariaDB pamoja na PHP-FPM workers kadhaa hutumia gigabyte ya kwanza haraka.

Mambo mawili lazima yawe sahihi kabla Certbot kufanya kazi mwishoni, kwa hiyo yaweke tayari sasa. Unahitaji jina la domain lenye A record inayoelekeza kwenye IP ya umma ya VPS. Let's Encrypt huthibitisha kupitia HTTP kwa kutumia jina hilo, na anwani tupu ya IP haiwezi kamwe kupata certificate. Pia port 80 na 443 lazima zifikike kutoka Internet. Kwa providers wengi, hii inamaanisha kuzifungua kwenye network firewall ya control panel na pia kwenye ufw iliyo kwenye seva. Mabadiliko ya DNS yanaweza kuchukua hadi saa moja kuenea, kwa hiyo weka A record kwanza ili iwe tayari wakati utakapohitaji.

Hatua ya 1 - Sakinisha Apache na uthibitishe ukurasa wa msingi

sudo apt update
sudo apt install -y apache2

apt huanzisha na kuwezesha huduma yenyewe. Ikague:

systemctl status apache2

Unapaswa kuona mstari wenye maandishi active (running). Sasa fungua http://YOUR_SERVER_IP/ kwenye kivinjari. Apache2 Ubuntu Default Page yenye bango kubwa la "It works!" ndiyo matokeo sahihi. Huu ni uthibitisho kwamba Apache inatoa huduma, si kosa. Ukurasa huo unapatikana kwenye /var/www/html/index.html na hutolewa na virtual host ya msingi iliyokuja na mfumo, 000-default.conf. Utazima vyote viwili baadaye. Kwa sasa, kuwepo kwao ndiko hasa unakotaka kuthibitisha.

Ikiwa ukurasa haufunguki kabisa lakini systemctl inaonyesha kwamba mchakato unaendelea, firewall inazuia muunganisho. Hiyo ndiyo hatua inayofuata.

Hatua ya 2 - Fungua firewall kwa HTTP na HTTPS

Kifurushi cha apache2 husajili profiles tatu za programu za ufw. Ziorodheshe:

sudo ufw app list

Utaona Apache, Apache Full na Apache Secure. Apache ni port 80 pekee, Apache Secure ni port 443 pekee, na Apache Full ni zote mbili. Hiyo ndiyo unayotaka kwa sababu unaongeza TLS mwishoni.

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

Ruhusu OpenSSH kabla ya kuendesha ufw enable. Kwa chaguo-msingi, ufw hukataa traffic yote inayoingia. Ukiiwasha bila rule ya SSH, muunganisho wako mwenyewe hukatika mara tu inapoanza kufanya kazi. Utaendelea na session ya sasa, lakini hutaweza kuunganisha tena. Thibitisha kwa sudo ufw status. Unataka OpenSSH, Apache Full na equivalents zake za v6 zote zionyeshe ALLOW.

Hatua ya 3 - Sakinisha MariaDB na uilinde

sudo apt install -y mariadb-server
systemctl status mariadb

Ubuntu 24.04 inasambaza MariaDB 10.11, ambayo ni toleo lenye msaada wa muda mrefu, kwa hiyo huhitaji repository ya nje. Huduma ikiwa inaendelea kufanya kazi, iimarisha usalama wake:

sudo mysql_secure_installation

Soma maulizo hayo badala ya kubonyeza Enter bila kufikiri. Inapokuuliza current root password, bonyeza Enter kwa sababu bado hakuna nenosiri. Inapouliza "Switch to unix_socket authentication?", jibu hilo halibadilishi chochote kwa sababu tayari limewezeshwa kwenye package hii, kwa hiyo bonyeza n. Jibu n kwa "Change the root password?" kwa sababu iliyoelezwa katika aya inayofuata. Kisha jibu Y kwa maulizo yaliyosalia: ondoa watumiaji wasiotambuliwa, kataza root login ya mbali, futa test database, na pakia upya privilege tables.

Hii ndiyo sehemu inayowachanganya watu wengi. Kwenye MariaDB ya Ubuntu, database account ya root hutumia uthibitishaji wa unix_socket, si nenosiri. Hii inamaanisha database huiamini user wa mfumo wa uendeshaji ambaye tayari umejithibitisha kuwa yeye. Kwa hiyo, amri hii hufanya kazi kutoka kwenye root shell:

sudo mysql

...na hukupeleka kwenye prompt ya MariaDB [(none)]> bila kuomba nenosiri. Amri hiyo hiyo ikiendeshwa na user asiye na privileged access hukataliwa. Hilo ndilo kusudi lake: access ya database root inahusishwa na sudo kwenye seva, na hakuna nenosiri la kuibwa, kulaghaiwa au kuvunjwa kwa brute-force. Hii ni salama zaidi kuliko nenosiri, kwa hiyo iache hivyo. Kanuni inayotokana na hilo ni hii: usiwahi kuelekeza programu kwenye account ya root. Unda user maalum kwa kila programu (Hatua ya 7), kwa sababu programu inayounganisha kupitia TCP kwa kutumia username na password haiwezi kutumia socket auth, na unataka kila programu iwe na access kwa database yake pekee.

Hatua ya 4 - Sakinisha PHP 8.3 pamoja na PHP-FPM

PHP ya msingi katika Ubuntu 24.04 ni 8.3. Sakinisha msimamizi wa michakato wa FPM pamoja na viendelezi ambavyo programu ya kawaida huhitaji:

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

Tambua kisichokuwapo kwenye orodha hiyo: libapache2-mod-php. Kifurushi hicho cha zamani hujumuisha mkalimani wa PHP ndani ya kila mchakato wa Apache. Ni rahisi, lakini kila worker hubeba nakala ya PHP iwe inatoa script au picha tuli, michakato hiyo miwili huwa na lifecycle moja, na hufanya kazi tu pamoja na MPM ya prefork ya Apache, ambayo ndiyo yenye ufanisi mdogo zaidi. PHP-FPM badala yake huendesha PHP kama pool yake ya michakato ambayo Apache huwasiliana nayo kupitia socket. Apache inaweza kutumia MPM yenye threads ya event kwa faili tuli na kupeleka maombi ya PHP pekee kwenye pool hiyo. Pool inaweza kusanidiwa bila kutegemea web server, na usanidi huohuo wa FPM utafanya kazi baadaye ukimweka nginx mbele. Hii ndiyo default ya sasa kwa sababu nzuri.

Apache huifikia FPM kupitia module ya proxy_fcgi. Iwashe, washa configuration ambayo kifurushi cha FPM kiliweka, kisha anzisha upya:

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

a2enconf php8.3-fpm huwasha /etc/apache2/conf-available/php8.3-fpm.conf, ambayo ina rule inayopitisha faili za PHP kwenye FPM socket. Sehemu kuu ya rule hiyo hulinganisha faili yoyote ya .php na kuipeleka kwenye socket iliyo katika /run/php/php8.3-fpm.sock:

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

Usihariri faili hiyo; husafirishwa ikiwa sahihi. Hata hivyo, kujua njia ya socket hukuwezesha kuchunguza hitilafu za "PHP downloads instead of running" na "Primary script unknown" baadaye. Hitilafu zote mbili hutokana na Apache na FPM kutokubaliana kuhusu socket hiyo au faili iliyo nyuma yake.

Hatua ya 5 - Virtual host ya programu yako inayotumia jina

Virtual hosting inayotumia jina huruhusu IP moja kuhudumia tovuti nyingi; Apache huchagua tovuti kwa kutumia kichwa cha Host: kwenye ombi. Tengeneza saraka ya programu, mbali kabisa na /var/www/html ya kawaida:

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

Umiliki ni muhimu. Apache na PHP-FPM zote huendesha kama mtumiaji wa www-data kwenye Ubuntu. Kwa hiyo, faili ambazo web server lazima isome, pamoja na saraka ambazo programu lazima iandikie, kama saraka ya uploads, zinapaswa kumilikiwa na www-data. Ikiwa pia utahariri faili ukitumia mtumiaji wako wa kuingia, muundo unaotumika mara nyingi ni kumiliki faili hizo mwenyewe na kumuongeza mtumiaji wako kwenye group ya www-data; kwa deployment ya kawaida, www-data:www-data ndiyo chaguo linaloleta mshangao mdogo.

Tengeneza virtual host kwenye /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>

Weka ServerName iwe domain yako halisi. Options -Indexes huzuia Apache kuorodhesha saraka wakati hakuna index file; bila hivyo, wageni wanaweza kuvinjari source tree yako. AllowOverride All huruhusu .htaccess file kufanya kazi, jambo ambalo programu nyingi za PHP hutegemea kwa pretty URLs; ibadilishe iwe None ili kupata ongezeko dogo la kasi ikiwa programu yako haihitaji kipengele hicho. Wezesha site hii, zima default, kagua configuration, kisha fanya reload:

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

apache2ctl configtest inapaswa kuchapisha Syntax OK. Mstari wa a2dissite 000-default ndio ambao watu huusahau. Ndiyo sababu ukurasa wa default huonekana baadaye kana kwamba umekwama, kama ilivyoelezwa katika sehemu ya failures.

Hatua ya 6 - Thibitisha PHP inaendesha, kisha futa uthibitisho

Weka faili la PHP lenye mstari mmoja kwenye mzizi wa app:

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

Tembelea http://app.example.com/info.php. Matokeo sahihi ni jedwali refu la zambarau na kijivu lenye kichwa PHP Version 8.3.x, linaloorodhesha modules zilizopakiwa, huku mstari wa Server API ukisomeka FPM/FastCGI. Mstari huo wa mwisho unathibitisha kuwa maombi yanapitia PHP-FPM, si mod_php.

Sasa lifute mara moja:

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

phpinfo() huonyesha toleo lako kamili la PHP, extension zote zilizopakiwa, njia za mafaili na maelezo ya mazingira. Hii humpa mtu anayechunguza server kwa toleo lenye udhaifu unaojulikana taarifa muhimu. Ni jaribio, si feature. Lifute mara tu unapoona ukurasa. Ikiwa badala ya jedwali browser yako ilitoa chaguo la kupakua info.php, PHP haijaunganishwa na Apache; nenda kwenye sehemu ya failures kabla ya kufanya jambo lingine.

Hatua ya 7 - Unda database ya programu na mtumiaji mwenye ruhusa chache

Fungua database kama root anayethibitishwa kupitia socket:

sudo mysql

Kisha unda database moja na mtumiaji mmoja anayehusishwa na database hiyo pekee:

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;

Hapa kuna machaguo matatu yaliyofanywa kwa makusudi. utf8mb4 ni UTF-8 halisi ya baiti nne. Alias ya zamani utf8 hukata emoji na baadhi ya herufi za CJK bila kutoa taarifa, kwa hiyo tumia utf8mb4 kila wakati. Ruhusa imetolewa kwenye appdb.*, si *.*: mtumiaji huyu anaweza kufikia database yake pekee na hakuna nyingine, kwa hiyo mwanya wa SQL injection kwenye programu hauwezi kusoma majedwali ya tovuti nyingine. Pia, 'appuser'@'localhost' inaweka kikomo cha akaunti kwenye miunganisho inayoanzishwa kwenye mashine yenyewe.

Ijaribu ukiwa mtumiaji huyo:

mysql -u appuser -p appdb

Itakuomba nenosiri kisha ikupe kidokezo cha MariaDB [appdb]>. Kumbuka kwamba hakuna alama ya -h. Iache bila kuwekwa, na client itaunganisha kupitia Unix socket ya ndani, ambayo MariaDB huhesabu kama localhost. Kuna jambo moja muhimu la kujua: kwa MySQL na MariaDB, localhost humaanisha Unix socket na 127.0.0.1 humaanisha muunganisho wa TCP. Kwenye MariaDB ya kawaida ya Ubuntu 24.04, seva bado hutatua muunganisho wa TCP kutoka 127.0.0.1 kuwa localhost, kwa hiyo yote mawili yanaendana na akaunti hiyo. Lakini kwenye seva ambazo skip-name-resolve imewezeshwa, jambo ambalo ni uboreshaji wa utendaji unaotumika sana na ni la kawaida kwenye container images nyingi, thamani hizo mbili huchukuliwa kama hosts tofauti. Programu inayounganisha kwa 127.0.0.1 itakataliwa kwa ERROR 1045 (28000): Access denied for user 'appuser'@'127.0.0.1' (using password: YES) hata nenosiri likiwa sahihi.

Kwa hiyo, elekeza programu yako kwenye host localhost, mtumiaji appuser, na database appdb, wala si root. mysqli ya PHP na PDO zote hubadilika kutumia Unix socket wakati host ni string halisi localhost, inayolingana na akaunti uliyounda. Ikiwa framework inasisitiza kutumia host ya TCP yenye namba, unda mtumiaji kulingana na namna inavyounganisha, 'appuser'@'127.0.0.1', au @'%' (ikiambatana na sheria ya firewall) iwapo lazima ifikie database kutoka kwenye mashine nyingine.

Hatua ya 8 - Ongeza HTTPS kwa Certbot

Kuhudumia fomu ya kuingia kupitia HTTP isiyosimbwa hutuma manenosiri yakiwa katika maandishi wazi, na kila kivinjari cha kisasa huonyesha ukurasa huo kuwa “Si salama”. Certbot hutatua hilo kwa amri moja. Isakinishe pamoja na plugin ya Apache:

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

Certbot hutumia plugin mbili hapa. apache authenticator huthibitisha kuwa unadhibiti domain kwa kuhudumia kwa muda mfupi faili ya challenge kupitia Apache inayofanya kazi. Kisha apache installer hubadilisha virtual host yako ili kuongeza block ya 443, iielekeze kwenye certificate mpya, na ielekeze traffic yote ya HTTP kwenda HTTPS kwa chaguo-msingi. Kuanzia Certbot 2.0, hakuna swali la redirect; pitisha --no-redirect ikiwa unahitaji kuendelea kuhudumia HTTP isiyosimbwa. Kwa kuwa uliweka ServerName halisi katika Hatua ya 5, Certbot hutambua domain kiotomatiki. Certificates hudumu kwa siku 90, na package husakinisha systemd timer ya kuzifanya renewal. Thibitisha timer kwa sudo certbot renew --dry-run; matokeo yanapaswa kuishia na Congratulations, all simulated renewals succeeded.

Kwa mwongozo kamili wa challenge, renewal timer, pamoja na mahitaji ya DNS na firewall, soma mwongozo unaoandamana kwenye kutoa TLS certificates za bure za Let's Encrypt kwa Certbot kwenye Apache.

Nakala rudufu, masasisho na uimarishaji wa usalama

Hifadhi nakala ya vitu viwili vinavyobeba hali ya mfumo wako: hifadhidata na mzizi wa wavuti. Nakala rudufu ya kimantiki ya kila usiku ndiyo njia rahisi na ya kuaminika zaidi, sudo sh -c 'mysqldump --all-databases --single-transaction | gzip > /root/db-$(date +%F).sql.gz', kisha inakiliwa nje ya seva. Kuweka mchakato mzima ndani ya sudo sh -c ni muhimu: bila hivyo, shell huendesha uelekezaji wa > /root/... kwa mtumiaji wako mwenyewe na hushindwa kwa Permission denied, kwa sababu ni mysqldump pekee iliyorithi sudo. --single-transaction hutoa snapshot thabiti ya jedwali za InnoDB bila kuzifungia. Iambatanishe na tar ya /var/www na /etc/apache2/sites-available, nawe unaweza kujenga upya stack nzima kwenye VPS mpya kwa kutumia faili hizo.

Masasisho ni sudo apt update && sudo apt upgrade ya kawaida. Linaloweza kusababisha tatizo ni kuongeza toleo la PHP, wakati Ubuntu ya baadaye inapohamisha toleo-msingi hadi PHP 8.4, apt inaweza kusakinisha php8.4-fpm sambamba na 8.3, socket ikawa /run/php/php8.4-fpm.sock, huku usanidi wako wa Apache ukiendelea kuelekeza kwenye socket ya 8.3. Wezesha conf mpya (sudo a2enconf php8.4-fpm) na uzime ya zamani; la sivyo tovuti yako itaanza kurudisha Primary script unknown baada ya sasisho la kawaida lisilo na matatizo mengine. Kwa sababu matoleo ya PHP hubadilika haraka kuliko distro ya LTS, soma maelezo ya sasa ya matoleo ya PHP badala ya kubandika toleo dogo maalumu.

Hatua mbili za uimarishaji wa usalama zinafaa kufanywa siku ya kwanza. Kwanza, weka Fail2Ban inayofuatilia SSH kwenye seva. VPS ya umma hupokea majaribio ya kiotomatiki ya kuingia ndani ya dakika chache, na jail ndogo hupunguza maelfu ya majaribio hayo hadi machache kabla ya kuzuia anwani. Pili, ikiwa ungependa kusimamia virtual hosts za Apache, hifadhidata za MariaDB na watumiaji kupitia browser badala ya kuhariri faili kwa mkono, paneli ya udhibiti ya Webmin inayotumia wavuti hukaa juu ya stack hii hii na hutumia faili zilezile za usanidi ulizoandika. Hakuna kati ya hizi inayochukua nafasi ya kuelewa vipengele vya mfumo, lakini zote hupunguza usumbufu wa kila siku.

Hali za hitilafu, pamoja na maandishi utakayoona

Ukurasa chaguomsingi hauondoki. Umehariri virtual host yako, uka-reload, lakini kivinjari bado kinaonyesha "Apache2 Ubuntu Default Page" na bango lake la "It works!". Apache hutumikia virtual host ya kwanza inayolingana, na wakati hakuna ServerName inayolingana na ombi, configuration ya kwanza kwa mpangilio wa alfabeti hushinda; 000-default.conf hupangwa kabla ya testapp.conf. Huenda jina la host kwenye ombi halilingani na ServerName yako, au hukuwahi kuendesha sudo a2dissite 000-default. Zima chaguo-msingi, sudo systemctl reload apache2, kisha thibitisha kwa apache2ctl -S, ambayo huchapisha ramani ya vhost na kuonyesha configuration inayomiliki chaguo-msingi. Pia futa cache ya kivinjari; 200 iliyohifadhiwa kutoka ukurasa wa zamani inaweza kuendelea kuonyeshwa.

Faili ya .php inapakuliwa badala ya kuendeshwa. Ukifungua info.php, kivinjari hupakua faili yenye msimbo ghafi wa <?php, au huionyesha kama maandishi ya kawaida, badala ya kuiendesha. Apache inahudumia faili hiyo kama static asset kwa sababu PHP handler haijaunganishwa, uliruka sudo a2enmod proxy_fcgi, au sudo a2enconf php8.3-fpm, au hukuiwasha upya Apache baadaye. Endesha zote tatu (Hatua ya 4) kisha ufanye reload. Thibitisha kuwa module imepakiwa kwa apache2ctl -M | grep fcgi, ambayo inapaswa kuorodhesha proxy_fcgi_module. Hii ni uvujaji wa msimbo wa chanzo, si hitilafu ya mwonekano, kwa hiyo irekebishe kabla ya kuweka kitu halisi kwenye seva.

ERROR 1698 (28000): Access denied for user 'root'@'localhost'. Uliendesha mysql -u root au mariadb -u root bila sudo. Akaunti ya root hutumia uthibitishaji wa unix_socket, kwa hiyo inakukubali tu wakati mtumiaji wako wa OS ni root. Suluhisho ni sudo mysql, bila -u root na bila password. Ujumbe huu unaonyesha tabia inayotarajiwa ya uthibitishaji wa socket unaofanya kazi vizuri, si usakinishaji ulioharibika.

ERROR 1045 (28000): Access denied for user 'appuser'@'127.0.0.1' kutoka kwenye application, ukitumia password sahihi. Akaunti ipo kama 'appuser'@'localhost', lakini app yako inaunganisha kupitia TCP kwenye 127.0.0.1 kwenye seva ambayo name resolution imezimwa (skip-name-resolve). Kwa hiyo, MariaDB huzitambua kama hosts mbili tofauti: localhost ni Unix socket, na 127.0.0.1 ni TCP. Elekeza app kwenye host localhost ili itumie socket na ilingane na akaunti, au unda akaunti ya pili 'appuser'@'127.0.0.1' ikiwa framework itatumia TCP pekee.

AH01071: Got error 'Primary script unknown' katika /var/log/apache2/testapp-error.log, huku kivinjari kikionyesha File not found.. Apache ilipeleka ombi kwa PHP-FPM, lakini FPM haikuweza kupata script kwenye path ambayo Apache iliipa. Sababu mbili za kawaida ni hizi: FPM socket katika configuration yako inaelekeza kwenye PHP version ambayo haijasakinishwa (socket ya php8.4 baada ya upgrade ilhali ni 8.3 pekee inayotumika), au faili haipo kweli kwa sababu DocumentRoot na directory halisi haviendani. Kagua kuwa socket ipo kwa ls -l /run/php/, thibitisha kuwa DocumentRoot inaendana na mahali faili ilipo, kisha uwashe upya php8.3-fpm na apache2.

AH00558: apache2: Could not reliably determine the server's fully qualified domain name kila mara Apache inapowashwa upya. Hili ni onyo lisilo na madhara, si hitilafu. Apache inakuambia kuwa hakuna ServerName ya kimataifa iliyowekwa. Nyamazisha onyo hilo kwa kuandika ServerName your.domain kwenye /etc/apache2/conf-available/servername.conf na kuendesha sudo a2enconf servername.

(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80 Apache inapoanza. Web server nyingine tayari inatumia port 80, mara nyingi ikiwa ni nginx iliyobaki kutoka jaribio la awali. Itafute kwa sudo ss -ltnp | grep :80, kisha simamisha na uzime service hiyo nyingine kabla ya kuanzisha Apache.

FAQ

mod_php au PHP-FPM - nitumie ipi?

Tumia PHP-FPM. mod_php huweka interpreter ndani ya kila mchakato wa Apache na kulazimisha MPM ya polepole ya prefork, hivyo Apache hubeba mzigo wa PHP hata inapotoa picha tuli. PHP-FPM huendesha PHP kama pool tofauti inayoweza kurekebishwa kwa kujitegemea, ambayo Apache huifikia kupitia socket. Pia hufanya kazi na MPM ya haraka yenye threads ya event, na inaweza kuhamishwa bila mabadiliko kwenda nginx baadaye. Hii ndiyo chaguo la kisasa kwa kawaida; mod_php ina maana tu kwa app ya zamani inayotegemea tabia fulani ya ndani ya mchakato.

Kwa nini browser yangu inapakua faili ya PHP badala ya kuiendesha?

Apache inachukulia faili ya .php kama upakuaji tuli kwa sababu hakuna PHP handler iliyounganishwa nayo. Kwenye Ubuntu 24.04 inayotumia FPM, hii inamaanisha ulikosa mojawapo ya sudo a2enmod proxy_fcgi, sudo a2enconf php8.3-fpm, au kuwasha upya Apache baada ya hapo. Tekeleza zote tatu na upakie upya usanidi, kisha thibitisha kwa apache2ctl -M | grep fcgi kwamba proxy_fcgi_module imeorodheshwa. Hadi utakaporekebisha tatizo hili, seva inavuja source code, kwa hiyo lichukulie kuwa la dharura.

Kwa nini access ya root imekataliwa katika MariaDB hata ninapotumia password sahihi?

Kwa sababu hakuna password, MariaDB ya Ubuntu huthibitisha account ya root kwa kutumia unix_socket na kuihusisha na mtumiaji root wa mfumo wa uendeshaji. mysql -u root kutoka shell ya kawaida hurudisha ERROR 1698 (28000): Access denied for user 'root'@'localhost' kwa makusudi. Unganisha kwa kutumia sudo mysql badala yake, na umtengenezee kila application user tofauti anayethibitishwa kwa password, badala ya kutumia root tena.

Nitaongezaje HTTPS kwenye site yangu ya LAMP?

Sakinisha certbot na python3-certbot-apache, elekeza A record ya domain kwenye seva, kisha tekeleza sudo certbot --apache. Apache authenticator huthibitisha udhibiti wa domain kupitia Apache yako inayoendesha. Kisha installer hubadilisha virtual host kwa port 443 na kuweka automatic renewal. Mwongozo kamili wa Certbot na Apache unaeleza challenge, renewal timer na njia za kawaida za kushughulikia failures.