Ubuntu 24.04 वर LAMP स्टॅक आणि PHP-FPM कसे सेट करावे

तुम्ही काय तयार करत आहात

LAMP स्टॅक म्हणजे Ubuntu 24.04 सर्व्हरवरील चार घटक: पाया म्हणून Linux, HTTP विनंत्यांना प्रतिसाद देणारा Apache, डेटा साठवणारे MariaDB आणि कोड चालवणारे PHP 8.3. या मार्गदर्शिकेच्या शेवटी, तुमच्याकडे एक नेम-बेस्ड व्हर्च्युअल होस्ट असेल जो प्रत्यक्ष ॲप्लिकेशन डिरेक्टरी सर्व्ह करेल, एक डेटाबेस असेल ज्यासाठी कमीत कमी अधिकारांचा (least-privilege) वापरकर्ता असेल, PHP-FPM द्वारे Apache शी जोडलेले PHP असेल आणि त्यावर एक मोफत Let's Encrypt प्रमाणपत्र असेल.

इन्स्टॉलेशनसाठी केवळ चार apt कमांड्स लागतात. या मार्गदर्शिकेतील बहुतेक भाग हा या घटकांमधील जोडणी आणि अशा काही सामान्य चुकांबद्दल आहे, ज्यामुळे नवीन स्टॅक कोरी पाने (blank page) दाखवतो, तुमचा सोर्स कोड ब्राउझरमध्ये डाउनलोड म्हणून देतो किंवा तुम्ही नुकत्याच इन्स्टॉल केलेल्या डेटाबेसमध्ये प्रवेश नाकारतो. यातील प्रत्येक त्रुटीची एक विशिष्ट खूण असते, जी तुम्ही ओळखू शकता आणि खाली प्रत्येक त्रुटीचे नेमके नाव दिले आहे जे तुम्हाला दिसेल.

पूर्वअटी आणि महत्त्वाच्या बाबी

तुमच्याकडे Ubuntu 24.04 वर आधारित एक नवीन KVM VPS, sudo वापरकर्ता किंवा root ॲक्सेस आणि एक सार्वजनिक IPv4 ॲड्रेस असल्याची खात्री करा. एक किमान स्टॅक 1 GB RAM वर चालू शकतो; परंतु त्यावर डेटाबेसवर आधारित ॲप्लिकेशन चालवण्यापूर्वी किमान 2 GB RAM द्या, कारण MariaDB चे डीफॉल्ट बफर आणि काही PHP-FPM वर्कर्स मिळून सुरुवातीची 1 GB RAM लवकर वापरतात.

शेवटी Certbot कार्य करण्यासाठी दोन गोष्टी पूर्ण होणे आवश्यक आहे, त्यामुळे त्या आताच तपासून घ्या. तुमच्याकडे एक domain name असणे आवश्यक आहे ज्याचा A रेकॉर्ड VPS च्या सार्वजनिक IP कडे निर्देशित करतो. Let's Encrypt हे HTTP द्वारे त्या नावाची पडताळणी करते, त्यामुळे केवळ IP ॲड्रेसवर प्रमाणपत्र (certificate) मिळू शकत नाही. तसेच, 80 आणि 443 हे पोर्ट्स इंटरनेटवरून ॲक्सेस करण्यायोग्य असावेत. अनेक प्रोव्हायडर्सच्या बाबतीत, याचा अर्थ असा की तुम्हाला कंट्रोल पॅनेलवरील नेटवर्क फायरवॉलमध्ये आणि सर्व्हरवरील ufw मध्ये हे पोर्ट्स उघडावे लागतील. DNS बदल पूर्णपणे लागू होण्यासाठी एक तासापर्यंत वेळ लागू शकतो, म्हणून A रेकॉर्ड आधीच सेट करा जेणेकरून गरज पडेल तेव्हा तो सक्रिय असेल.

पायरी 1 - Apache स्थापित करा आणि डीफॉल्ट पेज तपासा

sudo apt update
sudo apt install -y apache2

apt तुमच्यासाठी सर्व्हिस सुरू करते आणि इनेबल करते. ती तपासा:

systemctl status apache2

तुम्हाला active (running) अशी ओळ दिसेल. आता ब्राउझरमध्ये http://YOUR_SERVER_IP/ उघडा. मोठ्या "It works!" बॅनरसह असलेले Apache2 Ubuntu Default Page हे योग्य परिणाम आहे; हे सिद्ध करते की Apache सर्व्ह करत आहे, कोणतीही चूक नाही. ते पेज /var/www/html/index.html येथे असते आणि ते शिप केलेले डीफॉल्ट व्हर्च्युअल होस्ट 000-default.conf द्वारे सर्व्ह केले जाते. तुम्ही नंतर या दोन्ही गोष्टी डिसेबल कराल; सध्या त्यांची उपस्थिती तुम्हाला हवी तशीच आहे.

जर पेज लोड होत नसेल पण systemctl नुसार प्रोसेस सुरू असेल, तर फायरवॉलमध्ये अडथळा आहे. ही पुढची पायरी आहे.

पायरी 2 - HTTP आणि HTTPS साठी फायरवॉल उघडा

apache2 पॅकेज तीन ufw ॲप्लिकेशन प्रोफाइल्स नोंदवते. त्यांची यादी करा:

sudo ufw app list

तुम्हाला Apache, Apache Full, आणि Apache Secure दिसतील. Apache फक्त पोर्ट 80 साठी आहे, Apache Secure फक्त 443 साठी आहे, आणि Apache Full दोन्हीसाठी आहे. तुम्हाला हेच हवे आहे, कारण तुम्ही शेवटी TLS जोडणार आहात.

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

ufw enable चालवण्यापूर्वी OpenSSH ला परवानगी द्या. ufw डीफॉल्टनुसार सर्व येणारी ट्रॅफिक नाकारते. SSH नियमाशिवाय ते सक्रिय केल्यास, ते सुरू होताच तुमचे कनेक्शन तुटते. तुम्ही सध्याच्या सत्रात राहता, परंतु पुन्हा कनेक्ट होऊ शकत नाही. sudo ufw status सह खात्री करा; तुम्हाला OpenSSH, Apache Full, आणि त्यांचे v6 समतुल्य सर्व ALLOW असे वाचायला हवे.

पायरी 3 - MariaDB स्थापित करा आणि सुरक्षित करा

sudo apt install -y mariadb-server
systemctl status mariadb

Ubuntu 24.04 मध्ये MariaDB 10.11 ही दीर्घकालीन समर्थित (long-term-support) आवृत्ती उपलब्ध आहे, त्यामुळे तुम्हाला बाह्य रिपॉझिटरीची आवश्यकता नाही. सर्व्हिस सुरू झाल्यावर, ती सुरक्षित करा:

sudo mysql_secure_installation

येणाऱ्या सूचना घाईघाईने Enter दाबण्याऐवजी वाचणे महत्त्वाचे आहे. जेव्हा ते current root password विचारते, तेव्हा Enter दाबा, कारण तो अद्याप सेट केलेला नाही. जेव्हा ते "Switch to unix_socket authentication?" विचारते, तेव्हा उत्तर काहीही दिले तरी फरक पडत नाही कारण या पॅकेजवर ते आधीच सक्षम आहे, म्हणून n दाबा. "Change the root password?" या प्रश्नाला n म्हणा, याचे कारण पुढील परिच्छेदात दिले आहे. त्यानंतर उर्वरित प्रश्नांसाठी Y उत्तर द्या: निनावी वापरकर्ते (anonymous users) काढून टाका, रिमोट रूट लॉगिन नाकारा, टेस्ट डेटाबेस काढून टाका आणि प्रिव्हिलेज टेबल पुन्हा लोड करा.

येथे असा भाग आहे जो सर्वांना गोंधळात टाकतो. Ubuntu च्या MariaDB वर root डेटाबेस खाते पासवर्डऐवजी unix_socket ऑथेंटिकेशन वापरते. याचा अर्थ असा की डेटाबेस तुम्ही ज्या ऑपरेटिंग-सिस्टम वापरकर्त्याद्वारे आधीच ऑथेंटिकेट झाला आहात, त्यावर विश्वास ठेवतो. त्यामुळे रूट शेलवरून हे काम करते:

sudo mysql

...आणि हे तुम्हाला कोणत्याही पासवर्डची विचारणा न करता MariaDB [(none)]> प्रॉम्प्टवर घेऊन जाते. हाच कमांड अनप्रिव्हिलेज्ड वापरकर्त्याद्वारे चालवल्यास तो नाकारला जातो, आणि हाच याचा मुख्य उद्देश आहे: डेटाबेस रूटचा प्रवेश हा मशीनवरील sudo शी जोडलेला असतो आणि चोरी करण्यासाठी, फिशिंग करण्यासाठी किंवा ब्रूट-फोर्स करण्यासाठी कोणताही पासवर्ड नसतो. हे पासवर्डपेक्षा अधिक सुरक्षित आहे, म्हणून त्यात बदल करू नका. यावरून येणारा नियम असा: कधीही एखाद्या ॲप्लिकेशनला root खात्याशी जोडू नका. प्रत्येक ॲप्लिकेशनसाठी एक स्वतंत्र वापरकर्ता तयार करा (पायरी 7), कारण युजरनेम आणि पासवर्ड वापरून TCP द्वारे कनेक्ट होणारे ॲप सॉकेट ऑथेंटिकेशन वापरू शकत नाही आणि तुम्हाला प्रत्येक ॲपला त्याच्या स्वतःच्या डेटाबेसपुरते मर्यादित ठेवायचे असते.

पायरी 4 - PHP 8.3 आणि PHP-FPM इन्स्टॉल करा

Ubuntu 24.04 मध्ये डीफॉल्ट PHP 8.3 आहे. FPM प्रोसेस मॅनेजर आणि सामान्य ॲप्लिकेशनसाठी आवश्यक असलेले एक्स्टेंशन्स इन्स्टॉल करा:

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

या यादीत काय नाही ते लक्षात घ्या: libapache2-mod-php. हे जुने पॅकेज प्रत्येक Apache प्रोसेसमध्ये PHP इंटरप्रिटर एम्बेड करते. हे सोपे आहे, परंतु प्रत्येक वर्कर स्क्रिप्ट सर्व्ह करत असो किंवा स्टॅटिक इमेज, तो PHP ची एक प्रत सोबत ठेवतो. या दोघांचे लाइफसायकल एकच असते आणि ते फक्त Apache च्या prefork MPM सोबत काम करते, जे सर्वात कमी कार्यक्षम आहे. त्याऐवजी, PHP-FPM हे PHP ला स्वतःच्या प्रोसेस पूलमध्ये चालवते, ज्याच्याशी Apache एका सॉकेटद्वारे संवाद साधते. यामुळे Apache स्टॅटिक फाइल्ससाठी थ्रेडेड event MPM वापरू शकते आणि फक्त PHP विनंत्या पुढे पाठवू शकते. हा पूल वेब सर्व्हरपासून स्वतंत्रपणे ट्यून केला जाऊ शकतो आणि भविष्यात जर तुम्ही समोर nginx वापरले, तरीही हीच FPM सेटअप काम करते. चांगल्या कारणामुळे हे सध्याचे डीफॉल्ट आहे.

Apache हे proxy_fcgi मॉड्यूलद्वारे FPM पर्यंत पोहोचते. ते इनेबल करा, FPM पॅकेजने दिलेले कॉन्फिगरेशन इनेबल करा आणि सर्व्हर रीस्टार्ट करा:

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

a2enconf php8.3-fpm हे /etc/apache2/conf-available/php8.3-fpm.conf ला सक्रिय करते, ज्यामध्ये PHP फाइल्सना FPM सॉकेटवर राउट करण्याचे नियम असतात. यातील मुख्य भाग कोणत्याही .php फाइलशी जुळतो आणि तिला /run/php/php8.3-fpm.sock वरील सॉकेटवर फॉरवर्ड करतो:

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

तुम्ही ती फाइल एडिट करू नका; ती योग्य स्वरूपातच येते. परंतु सॉकेटचा पाथ माहित असणे तुम्हाला नंतर उद्भवणाऱ्या "PHP downloads instead of running" आणि "Primary script unknown" यांसारख्या त्रुटींचे निदान करण्यास मदत करते. या दोन्ही त्रुटी Apache आणि FPM मधील सॉकेट किंवा त्यामागील फाइलच्या विसंगतीमुळे निर्माण होतात.

Step 5 - तुमच्या ॲपसाठी नेम-बेस्ड व्हर्च्युअल होस्ट

नेम-बेस्ड व्हर्च्युअल होस्टिंगमुळे एकाच IP वर अनेक साइट्स चालवता येतात; Apache विनंतीमधील Host: हेडरवरून साइट निवडते. ॲपसाठी एक डिरेक्टरी तयार करा, जी डिफॉल्ट /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

मालकी हक्क (Ownership) महत्त्वाचे आहेत. Ubuntu वर Apache आणि PHP-FPM दोन्ही www-data युजर म्हणून चालतात, त्यामुळे वेब सर्व्हरला वाचण्यासाठी आवश्यक असलेल्या फाइल्स आणि ॲपला लिहिण्यासाठी आवश्यक असलेल्या डिरेक्टरीज (उदा. uploads फोल्डर), यांची मालकी www-data कडे असावी. जर तुम्ही तुमच्या लॉगिन युजरने फाइल्स एडिट करणार असाल, तर फाइल्सची मालकी स्वतःकडे ठेवणे आणि तुमच्या युजरला www-data ग्रुपमध्ये समाविष्ट करणे ही एक सामान्य पद्धत आहे; साध्या डिप्लॉयमेंटसाठी, www-data:www-data वापरणे सर्वात सोयीचे ठरते.

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

ServerName ला तुमच्या प्रत्यक्ष डोमेनवर सेट करा. जेव्हा इंडेक्स फाइल नसते, तेव्हा Options -Indexes मुळे Apache डिरेक्टरीची यादी दाखवणे थांबवते, अन्यथा अभ्यागत तुमचे सोर्स ट्री ब्राउझ करू शकतील. AllowOverride All मुळे .htaccess फाइल कार्य करते, ज्याची अपेक्षा बहुतेक PHP ॲप्लिकेशन्स 'प्रिटी URL' साठी करतात; जर तुमच्या ॲपला याची गरज नसेल, तर थोड्या वेगवान कामगिरीसाठी ते None वर सेट करा. ही साइट इनेबल करा, डिफॉल्ट साइट डिसेबल करा, कॉन्फिगरेशन तपासा आणि रिलोड करा:

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

apache2ctl configtest ने Syntax OK असे प्रिंट केले पाहिजे. a2dissite 000-default ही ओळ लोक विसरतात, आणि म्हणूनच नंतर डिफॉल्ट पेज अडकल्यासारखे वाटते, ज्याबद्दल 'failures' विभागात माहिती दिली आहे.

पायरी 6 - PHP चालत असल्याची खात्री करा, त्यानंतर पुरावा हटवा

अ‍ॅप रूटमध्ये एक ओळीची PHP फाईल तयार करा:

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

http://app.example.com/info.php ला भेट द्या. योग्य निकाल म्हणजे लांब जांभळ्या आणि राखाडी रंगाचा PHP Version 8.3.x तक्ता, ज्यामध्ये तुमचे लोड केलेले मॉड्यूल्स दिसतील आणि Server API ओळीवर FPM/FastCGI असे लिहिलेले असेल. ही शेवटची ओळ हे सिद्ध करते की विनंत्या mod_php द्वारे न जाता PHP-FPM द्वारे जात आहेत.

आता ती फाईल त्वरित हटवा:

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

phpinfo() मुळे तुमची अचूक PHP आवृत्ती, प्रत्येक लोड केलेले एक्स्टेंशन, फाईल पाथ आणि एनवायरमेंट डिटेल्स उघड होतात. सर्व्हरमध्ये त्रुटी शोधणाऱ्या कोणासाठीही ही एक मोठी भेट ठरू शकते. ही एक चाचणी आहे, फिचर नाही. पेज पाहिल्यानंतर लगेच ती फाईल हटवा. जर तक्त्याऐवजी तुमच्या ब्राउझरने info.php डाउनलोड करण्याचा पर्याय दिला, तर PHP हे Apache शी जोडलेले नाही; इतर काहीही करण्यापूर्वी 'अपयश' (failures) विभागाकडे जा.

पायरी 7 - ॲप डेटाबेस आणि कमीत कमी अधिकारांचा वापरकर्ता तयार करा

सॉकेट-ऑथेंटिकेटेड root वापरून डेटाबेस उघडा:

sudo mysql

त्यानंतर एक डेटाबेस आणि फक्त त्या डेटाबेसपुरता मर्यादित असलेला एक वापरकर्ता तयार करा:

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;

येथे तीन जाणीवपूर्वक निवडलेले निर्णय घेतले आहेत. utf8mb4 हे खऱ्या अर्थाने चार-बाइटचे UTF-8 आहे, जुने utf8 हे नाव इमोजी आणि काही CJK वर्णांना नकळतपणे कापून टाकते, म्हणून नेहमी utf8mb4 वापरा. ग्रांट (grant) ही appdb.* वर दिली आहे, *.* वर नाही: हा वापरकर्ता फक्त स्वतःच्या डेटाबेसमध्ये बदल करू शकतो आणि इतर कशालाही स्पर्श करू शकत नाही, त्यामुळे ॲप्लिकेशनमधील SQL-injection त्रुटीमुळे इतर कोणत्याही साइटच्या टेबल्स वाचता येणार नाहीत. आणि 'appuser'@'localhost' हे खाते फक्त त्याच सर्व्हरवरून येणाऱ्या कनेक्शनपुरते मर्यादित ठेवते.

त्या वापरकर्त्यासह याची चाचणी घ्या:

mysql -u appuser -p appdb

हे पासवर्ड विचारेल आणि तुम्हाला MariaDB [appdb]> प्रॉम्प्टवर घेऊन जाईल. लक्षात घ्या की येथे कोणताही -h फ्लॅग नाही, तो न वापरल्यास क्लायंट स्थानिक Unix सॉकेटद्वारे कनेक्ट होतो, ज्याला MariaDB नेमके localhost मानते. एक महत्त्वाची गोष्ट लक्षात ठेवा: MySQL आणि MariaDB साठी, localhost म्हणजे Unix सॉकेट आणि 127.0.0.1 म्हणजे TCP कनेक्शन. स्टॉक Ubuntu 24.04 MariaDB वर सर्व्हर अजूनही 127.0.0.1 कडून येणारे TCP कनेक्शन localhost कडे रिझॉल्व्ह करतो, त्यामुळे दोन्ही खात्यांशी जुळतात. परंतु, ज्या सर्व्हरवर skip-name-resolve सक्षम आहे (हा एक सामान्य परफॉर्मन्स बदल आहे आणि अनेक कंटेनर इमेजेसमध्ये हे प्रमाण आहे), तिथे या दोन होस्टना वेगळे मानले जाते. अशा वेळी, 127.0.0.1 वर कनेक्ट होणाऱ्या ॲप्लिकेशनला पासवर्ड बरोबर असूनही ERROR 1045 (28000): Access denied for user 'appuser'@'127.0.0.1' (using password: YES) एररमुळे नाकारले जाते.

त्यामुळे तुमच्या ॲप्लिकेशनला localhost होस्ट, appuser वापरकर्ता आणि appdb डेटाबेसवर पॉइंट करा, कधीही root वर करू नका. PHP चे mysqli आणि PDO दोन्ही जेव्हा होस्ट म्हणून localhost ही अक्षरशः स्ट्रिंग वापरली जाते, तेव्हा Unix सॉकेटवर स्विच होतात, जे तुम्ही नुकत्याच तयार केलेल्या खात्याशी जुळते. जर एखादे फ्रेमवर्क संख्यात्मक TCP होस्टचा आग्रह धरत असेल, तर वापरकर्त्याला ते ज्या प्रकारे कनेक्ट होते त्यानुसार तयार करा, उदा. 'appuser'@'127.0.0.1', किंवा जर त्याला दुसऱ्या मशीनवरून डेटाबेसपर्यंत पोहोचायचे असेल तरच @'%' (फायरवॉल नियमासह) वापरा.

पायरी 8 - Certbot सह HTTPS जोडा

प्लेन HTTP वर लॉगिन फॉर्म सर्व्ह केल्यास पासवर्ड स्पष्ट मजकुरात (clear text) पाठवले जातात आणि प्रत्येक आधुनिक ब्राउझर त्या पृष्ठाला "Not secure" असे चिन्हांकित करतो. Certbot एका कमांडमध्ये ही समस्या सोडवते. ते Apache प्लगइनसह इंस्टॉल करा:

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

Certbot येथे दोन प्लगइन वापरते. apache authenticator तुमच्या चालू असलेल्या Apache द्वारे एक चॅलेंज फाइल थोड्या काळासाठी सर्व्ह करून तुम्ही डोमेन नियंत्रित करता हे सिद्ध करते आणि त्यानंतर apache installer तुमच्या व्हर्च्युअल होस्टला पुन्हा लिहून (rewrite) त्यात 443 ब्लॉक जोडते, ते नवीन प्रमाणपत्राकडे (certificate) निर्देशित करते आणि डीफॉल्टनुसार सर्व HTTP ट्रॅफिक HTTPS वर रिडायरेक्ट करते. Certbot 2.0 पासून रिडायरेक्टबाबत कोणताही प्रश्न विचारला जात नाही; जर तुम्हाला प्लेन HTTP सर्व्ह करणे सुरू ठेवायचे असेल तर --no-redirect पास करा. तुम्ही पायरी 5 मध्ये वास्तविक ServerName सेट केल्यामुळे, Certbot आपोआप डोमेन शोधते. प्रमाणपत्रे 90 दिवस वैध असतात आणि पॅकेज एक systemd टायमर इंस्टॉल करते जे त्यांचे नूतनीकरण (renew) करते; sudo certbot renew --dry-run सह टायमरची पडताळणी करा, जो Congratulations, all simulated renewals succeeded वर संपला पाहिजे.

चॅलेंज, नूतनीकरण टायमर आणि DNS व फायरवॉल आवश्यकतांच्या संपूर्ण माहितीसाठी, Apache वर Certbot सह मोफत Let's Encrypt TLS प्रमाणपत्रे जारी करणे हे मार्गदर्शक पहा.

बॅकअप, अपग्रेड आणि हार्डनिंग

तुमची स्थिती (state) जपणाऱ्या दोन गोष्टींचा बॅकअप घ्या: डेटाबेस आणि वेब रूट. दररोज रात्री घेतला जाणारा लॉजिकल डंप हा सर्वात सोपा आणि विश्वासार्ह मार्ग आहे, sudo sh -c 'mysqldump --all-databases --single-transaction | gzip > /root/db-$(date +%F).sql.gz', जो नंतर सर्व्हरवरून बाहेर कॉपी केला जातो. संपूर्ण पाइपलाइनला sudo sh -c मध्ये गुंडाळणे महत्त्वाचे आहे: त्याशिवाय शेल > /root/... रिडायरेक्ट तुमच्या स्वतःच्या युजर म्हणून चालवते आणि Permission denied मुळे अयशस्वी होते, कारण फक्त mysqldump कडेच sudo वारसाहक्काने आलेले असते. --single-transaction मुळे InnoDB टेबल्सना लॉक न करता त्यांचे सुसंगत स्नॅपशॉट मिळते. याला /var/www आणि /etc/apache2/sites-available च्या tar सोबत जोडा, म्हणजे तुम्ही त्या फाइल्स वापरून नवीन VPS वर संपूर्ण स्टॅक पुन्हा तयार करू शकता.

अपग्रेड ही एक सामान्य sudo apt update && sudo apt upgrade प्रक्रिया आहे. PHP व्हर्जनमधील बदल ही एक त्रासदायक गोष्ट ठरू शकते, जेव्हा भविष्यातील Ubuntu डीफॉल्ट म्हणून PHP 8.4 वर जाते, तेव्हा apt कदाचित 8.3 सोबत php8.4-fpm इन्स्टॉल करेल, सॉकेट /run/php/php8.4-fpm.sock होईल आणि तुमचे Apache कॉन्फिगरेशन अजूनही 8.3 सॉकेटकडे निर्देश करत असेल. नवीन कॉन्फ (sudo a2enconf php8.4-fpm) इनेबल करा आणि जुने डिसेबल करा, अन्यथा नियमित अपग्रेडनंतरही तुमची साइट Primary script unknown एरर देऊ लागेल. PHP रिलीज हे LTS डिस्ट्रोपेक्षा वेगाने बदलत असल्याने, पॅच व्हर्जन पिन करण्याऐवजी सध्याच्या PHP रिलीज नोट्स तपासा.

हार्डनिंगच्या दोन पायऱ्या पहिल्या दिवशी करणे फायदेशीर ठरते. प्रथम, सर्व्हरवर Fail2Ban watching SSH सेट करा, सार्वजनिक VPS वर काही मिनिटांतच स्वयंचलित लॉगिन प्रयत्न सुरू होतात आणि एक लहान जेल हजारो प्रयत्नांना बॅन करण्यापूर्वी काही मोजक्या प्रयत्नांपर्यंत मर्यादित करते. दुसरे, जर तुम्हाला Apache व्हर्च्युअल होस्ट्स, MariaDB डेटाबेस आणि युजर्सचे व्यवस्थापन फाइल्स मॅन्युअली एडिट करण्याऐवजी ब्राउझरद्वारे करायचे असेल, तर the Webmin web-based control panel या स्टॅकवर व्यवस्थित बसते आणि तुम्ही तयार केलेल्या त्याच कॉन्फिगरेशन फाइल्स नियंत्रित करते. यापैकी कोणतीही गोष्ट तांत्रिक बाबी समजून घेण्याला पर्याय नाही, परंतु दोन्ही दैनंदिन कामातील अडथळे कमी करतात.

अपयशाचे प्रकार आणि दिसणारे संदेश

डीफॉल्ट पेज जात नाही. तुम्ही तुमच्या व्हर्च्युअल होस्टमध्ये बदल केले, सर्व्हिस रीलोड केली, तरीही ब्राउझरमध्ये अजूनही "Apache2 Ubuntu Default Page" आणि त्याचा "It works!" हा बॅनर दिसत आहे. Apache सर्वात आधी जुळणारा व्हर्च्युअल होस्ट सर्व्ह करतो. जेव्हा विनंतीशी (request) कोणतेही ServerName जुळत नाही, तेव्हा वर्णक्रमानुसार (alphabetically) पहिले कॉन्फिगरेशन निवडले जाते; 000-default.conf हे testapp.conf च्या आधी येते. एकतर विनंतीमधील होस्टचे नाव तुमच्या ServerName शी जुळत नाहीये, किंवा तुम्ही sudo a2dissite 000-default कधीच चालवले नाही. डीफॉल्ट कॉन्फिगरेशन sudo systemctl reload apache2 वापरून बंद करा आणि apache2ctl -S वापरून खात्री करा. हे कमांड व्हर्च्युअल होस्टचा नकाशा प्रिंट करते आणि डीफॉल्ट कॉन्फिगरेशन कोणत्या फाईलकडे आहे हे दाखवते. ब्राउझरची कॅशे (cache) देखील साफ करा; जुन्या पेजचा 200 रिस्पॉन्स कॅशेमध्ये राहिल्यामुळे ही समस्या येऊ शकते.

.php फाईल रन होण्याऐवजी डाउनलोड होत आहे. तुम्ही info.php उघडता तेव्हा ब्राउझर ते रन करण्याऐवजी त्यातील कच्चा <?php सोर्स कोड डाउनलोड करतो किंवा तो साध्या मजकुराप्रमाणे दाखवतो. Apache ही फाईल स्टॅटिक ॲसेट म्हणून सर्व्ह करत आहे कारण PHP हँडलर जोडलेला नाही, तुम्ही sudo a2enmod proxy_fcgi किंवा sudo a2enconf php8.3-fpm करायचे विसरला आहात, किंवा त्यानंतर Apache रीस्टार्ट केलेले नाही. या तिन्ही पायऱ्या (Step 4) पूर्ण करा आणि रीलोड करा. apache2ctl -M | grep fcgi वापरून मॉड्यूल लोड झाल्याची खात्री करा, ज्यामध्ये proxy_fcgi_module दिसले पाहिजे. ही सोर्स-कोड लीकची समस्या आहे, केवळ दिसण्यातील त्रुटी नाही, त्यामुळे सर्व्हरवर कोणतीही महत्त्वाची माहिती ठेवण्यापूर्वी हे दुरुस्त करा.

ERROR 1698 (28000): Access denied for user 'root'@'localhost'. तुम्ही mysql -u root किंवा mariadb -u root हे sudo शिवाय चालवले आहे. रूट अकाउंट unix_socket ऑथेंटिकेशन वापरते, त्यामुळे जेव्हा तुमचा OS युजर प्रत्यक्षात root असतो, तेव्हाच ते तुम्हाला स्वीकारते. याचे निराकरण sudo mysql असे आहे, यात -u root किंवा पासवर्डची गरज नाही. हा संदेश सॉकेट ऑथेंटिकेशन योग्यरित्या काम करत असल्याचे लक्षण आहे, इन्स्टॉलेशन खराब झाल्याचे नाही.

ॲप्लिकेशनकडून ERROR 1045 (28000): Access denied for user 'appuser'@'127.0.0.1', योग्य पासवर्ड असूनही. अकाउंट 'appuser'@'localhost' म्हणून अस्तित्वात आहे, परंतु तुमचे ॲप TCP द्वारे 127.0.0.1 वर कनेक्ट होत आहे, जिथे होस्ट-नेम रिझोल्यूशन बंद आहे (skip-name-resolve). त्यामुळे MariaDB या दोघांना वेगळे होस्ट मानते; localhost हे Unix सॉकेट आहे, तर 127.0.0.1 हे TCP आहे. ॲपला localhost होस्टकडे निर्देशित करा जेणेकरून ते सॉकेट वापरून अकाउंटशी जुळेल, किंवा जर फ्रेमवर्क फक्त TCP वापरत असेल तर दुसरे अकाउंट 'appuser'@'127.0.0.1' तयार करा.

/var/log/apache2/testapp-error.log मध्ये AH01071: Got error 'Primary script unknown', आणि ब्राउझरमध्ये File not found. दिसत आहे. Apache ने विनंती PHP-FPM कडे पाठवली, परंतु Apache ने दिलेल्या पाथवर FPM ला स्क्रिप्ट सापडली नाही. याची दोन सामान्य कारणे आहेत: तुमच्या कॉन्फिगरेशनमधील FPM सॉकेट अशा PHP व्हर्जनकडे निर्देशित करत आहे जे इन्स्टॉल केलेले नाही (उदा. अपग्रेडनंतर php8.4 सॉकेट, तर फक्त 8.3 रन होत आहे), किंवा DocumentRoot आणि प्रत्यक्ष डिरेक्टरीमध्ये तफावत असल्यामुळे फाईल तिथे नाही. ls -l /run/php/ वापरून सॉकेट अस्तित्वात असल्याची खात्री करा, DocumentRoot फाईलच्या प्रत्यक्ष स्थानाशी जुळते का ते तपासा आणि php8.3-fpm व apache2 दोन्ही रीस्टार्ट करा.

प्रत्येक रीस्टार्टवर AH00558: apache2: Could not reliably determine the server's fully qualified domain name. ही एक निरुपद्रवी सूचना आहे, त्रुटी नाही. Apache तुम्हाला सांगत आहे की कोणतेही ग्लोबल ServerName सेट केलेले नाही. हे शांत करण्यासाठी ServerName your.domain हे /etc/apache2/conf-available/servername.conf मध्ये लिहा आणि sudo a2enconf servername चालवा.

Apache सुरू होताना (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80. दुसरी वेब सर्व्हर सिस्टिम आधीच पोर्ट 80 वापरत आहे, बहुतेकदा मागील प्रयोगातील एखादे nginx प्रोसेस तिथे असू शकते. sudo ss -ltnp | grep :80 वापरून ते शोधा, त्यानंतर Apache सुरू करण्यापूर्वी ती सर्व्हिस थांबवा आणि बंद करा.

FAQ

mod_php की PHP-FPM - मी कशाचा वापर करावा?

PHP-FPM वापरा. mod_php प्रत्येक Apache प्रक्रियेमध्ये एक इंटरप्रिटर एम्बेड करते आणि संथ prefork MPM वापरण्यास भाग पाडते, त्यामुळे स्थिर प्रतिमा (static image) सर्व्ह करतानाही Apache वर PHP चा अतिरिक्त भार असतो. PHP-FPM हे PHP ला एका स्वतंत्र आणि स्वतंत्रपणे ट्यून केलेल्या पूलमध्ये चालवते, ज्यामध्ये Apache एका सॉकेटद्वारे प्रवेश करते. हे अधिक वेगवान थ्रेडेड event MPM सोबत काम करते आणि नंतर nginx वर सहजपणे स्थलांतरित करता येते. हे आधुनिक डीफॉल्ट आहे; mod_php केवळ अशा जुन्या ॲप्लिकेशन्ससाठी योग्य आहे जी इन-प्रोसेस वर्तनावर अवलंबून असतात.

माझा ब्राउझर PHP फाईल रन करण्याऐवजी ती डाउनलोड का करत आहे?

Apache या .php फाईलला एक स्थिर डाउनलोड म्हणून हाताळत आहे कारण तिला कोणताही PHP हँडलर जोडलेला नाही. Ubuntu 24.04 वर FPM वापरत असताना याचा अर्थ असा की तुम्ही sudo a2enmod proxy_fcgi, sudo a2enconf php8.3-fpm किंवा त्यानंतरच्या Apache रीस्टार्टपैकी काहीतरी चुकवले आहे. या तिन्ही कमांड्स रन करा आणि रिलोड करा, त्यानंतर apache2ctl -M | grep fcgi वापरून तपासा की proxy_fcgi_module सूचीबद्ध आहे. जोपर्यंत तुम्ही हे दुरुस्त करत नाही, तोपर्यंत सर्व्हर सोर्स कोड लीक करत आहे, म्हणून याला तातडीचे काम समजा.

योग्य पासवर्ड असूनही MariaDB मध्ये root ॲक्सेस नाकारला का जातो?

पासवर्ड नसल्यामुळे, Ubuntu चे MariaDB हे root अकाउंटला unix_socket द्वारे प्रमाणित करते, जे ऑपरेटिंग सिस्टमच्या root युजरशी जोडलेले असते. सामान्य शेलमधून mysql -u root रन केल्यास डिझाइननुसार ERROR 1698 (28000): Access denied for user 'root'@'localhost' मिळते. त्याऐवजी sudo mysql वापरून कनेक्ट करा आणि root चा पुनर्वापर करण्याऐवजी कोणत्याही ॲप्लिकेशनसाठी स्वतंत्र पासवर्ड-प्रमाणित युजर तयार करा.

मी माझ्या LAMP साइटवर HTTPS कसे जोडू?

certbot आणि python3-certbot-apache इंस्टॉल करा, डोमेनचा A रेकॉर्ड सर्व्हरकडे निर्देशित करा आणि नंतर sudo certbot --apache रन करा. Apache ऑथेंटिकेटर तुमच्या चालू असलेल्या Apache द्वारे डोमेनवरील नियंत्रण सिद्ध करतो आणि इंस्टॉलर पोर्ट 443 साठी व्हर्च्युअल होस्ट पुन्हा लिहितो आणि स्वयंचलित नूतनीकरण (automatic renewal) सेट करतो. पूर्ण Certbot आणि Apache मार्गदर्शिका मध्ये चॅलेंज, नूतनीकरण टायमर आणि सामान्य त्रुटींच्या प्रकारांची माहिती दिली आहे.