स्वचालित इंस्टॉलेशन

खरीदें Self-Hosted Protection
Live
Demo

स्वचालित तरीका: अकाउंट से एक स्क्रिप्ट पूरे सर्वर को तैयार कर देती है (वेब-स्टैक Apache + PHP, डेटाबेस, सुरक्षा टूल, cron)। इसके बाद — पैनल तैनात करें, SSL जारी करें और लाइसेंस दर्ज करें। यह Ubuntu/Debian पर चलता है: नए VPS पर सब कुछ शुरू से सेट करता है, पहले से सेट सर्वर पर — केवल अतिरिक्त रूप से (प्रोफ़ाइल “सेट किया गया सर्वर”, चरण 01)। नीचे दी गई सभी कमांड क्रम में हैं, बस ऊपर से नीचे स्क्रॉल करें। नए VPS पर हर चरण एक के बाद एक उपयुक्त है; यदि सर्वर पहले से सेट है या उस पर कोई होस्टिंग-पैनल लगा है, तो कुछ काम स्क्रिप्ट जान-बूझकर आप पर छोड़ देती है — वह क्या है, यह वह अपने काम के अंत में लिख देती है (आउटपुट का विश्लेषण — चरण 01 में)।

तरीका चुनें मैनुअल इंस्टॉलेशन FAQ-संदर्भिका
कमांड में प्लेसहोल्डर मान अपने मानों से बदलें: monitor.example.com — आपका डोमेन; 203.0.113.10 — सर्वर का वास्तविक IP; /var/www/monitor — पैनल का रूट (जहाँ public/, assets/, config.php रहते हैं); DB का पासवर्ड अपना बनाएं।
पूरा सेट (“पूर्ण सुरक्षा”) नए VPS के लिए है। साफ़ Ubuntu/Debian पर यह सुरक्षा प्रणाली शुरू से सेट करता है — Fail2ban (jail.local), root-crontab, UFW नियम, Apache कॉन्फ़िग। अगर सर्वर पहले से सेट है (चालू पैनल, साइटें, मेल, अपने jail) — तो प्रोफ़ाइल “सेट किया गया सर्वर” चुनें: यह केवल अतिरिक्त बदलाव करता है और आपके फ़ायरवॉल, Fail2ban, मेल, SSH और sysctl को नहीं छूता। होस्टिंग-पैनल मिलने पर स्क्रिप्ट खुद इस मोड पर स्विच हो जाती है। पहली बार चलाने से पहले ड्राई रन चालू कर सकते हैं (अकाउंट में चेकबॉक्स) — यह बिना कुछ बदले दिखाएगा कि क्या किया जाएगा। चालू सर्वर पर एहतियातन एक snapshot बना लें।

01. अकाउंट से ऑटो-सेटअप कमांड

यह कमांड आपको अपने अकाउंट my.arciveo.com → “सर्वर सेटअप” सेक्शन में मिलेगी (Arcivéo Security Monitor लेने के बाद उपलब्ध)। यह आपके अकाउंट से जुड़ी है और इसमें एक व्यक्तिगत टोकन है।

स्क्रिप्ट पूरे सर्वर को तैयार करती है: वेब-स्टैक (Apache + PHP), डेटाबेस, SSL के लिए टूल, सुरक्षा साधनों का पूरा सेट और cron-कार्य (Lynis, SMART, debsums, Logwatch, दैनिक रिपोर्ट, ipsum अपडेट)।

1) सुरक्षा स्तर चुनें (कमांड कॉपी करने से पहले, अकाउंट में):

  • पूर्ण सुरक्षा (अनुशंसित) — UFW (फ़ायरवॉल), Fail2ban, CrowdSec + bouncer, ipsum (IP ब्लॉक-लिस्ट), Suricata (IDS/IPS), Falco, ModSecurity + OWASP CRS (WAF), PSAD, mod_evasive (एंटी-DoS), AIDE (फ़ाइल इंटीग्रिटी), debsums, ClamAV + maldet (एंटीवायरस), Auditd, AppArmor, Monit, Lynis (ऑडिट), Logwatch, स्वतः सुरक्षा अपडेट।
  • हल्का — कम RAM वाले VPS के लिए: भारी कंपोनेंट्स के बिना बुनियादी सेट।
  • कॉन्फ़िगर किया गया सर्वर (होस्टिंग-पैनल) — पहले से चल रहे पैनल (HestiaCP आदि), साइट्स और मेल वाले सर्वर के लिए: केवल अतिरिक्त बदलाव (टूल की अतिरिक्त इंस्टॉलेशन, cron, sudo-नियम), जबकि फ़ायरवॉल, Fail2ban, मेल, SSH और sysctl जैसे-के-तैसे रहते हैं। पैनल वाले सर्वर पर स्क्रिप्ट यह मोड स्वयं चुन लेती है।
ड्राई रन। अकाउंट में “ड्राई रन” का चेकबॉक्स लगाया जा सकता है — तब कमांड केवल दिखाएगी कि स्क्रिप्ट क्या इंस्टॉल और बदलेगी, और बिना कुछ छुए समाप्त हो जाएगी। पहले से कॉन्फ़िगर सर्वर पर उपयोगी: पहले ड्राई रन, फिर बिना चेकबॉक्स के असली रन।

2) सर्वर पर root के तहत चलाएँ अकाउंट से मिली कमांड — यह ऐसी दिखती है:

curl -fsSL "https://my.arciveo.com/install.php?token=YOUR_TOKEN" | sudo bash
कमांड को गुप्त रखें — यह आपके अकाउंट से जुड़ी है। लिंक की वैधता सीमित समय के लिए है; यदि यह समाप्त हो गई हो, तो अकाउंट में “नया लिंक पाएँ” दबाएँ।
ऑटो-सेटअप के बाद वेब-सर्वर — Apache + PHP-FPM, और सुरक्षा टूल तथा cron-कार्य पहले से इंस्टॉल हैं और “आउट ऑफ द बॉक्स” काम करते हैं।

3) अंत में आया आउटपुट पढ़ें — वहीं लिखा होता है कि क्या आप पर छोड़ा गया है। स्क्रिप्ट अपना काम जाँचों के एक ब्लॉक और “आगे — पैनल की इंस्टॉलेशन” सूची के साथ समाप्त करती है। कुछ चरण वह जान-बूझकर नहीं करती: कौन-से, यह चुने गए प्रोफ़ाइल पर और इस पर निर्भर करता है कि उसे सर्वर पर क्या मिला। नीचे दी गई सूची से मिलान करें — केवल वही बिंदु करने हैं जिनकी पंक्तियाँ आपके आउटपुट में दिखी हों।

  • Control panel detected (…) — साइट स्वयं होस्टिंग-पैनल के साधनों से बनाई जाती है, vhost स्क्रिप्ट नहीं बनाती। चरण 03, शाखा “होस्टिंग-पैनल वाला सर्वर”।
  • No vhost created (no domain given) — प्रोफ़ाइल “सेट किया गया सर्वर” बिना डोमेन के: बिना नाम वाला vhost डिफ़ॉल्ट साइट बन जाता और आपकी ही साइटों को रोक लेता, इसलिए वह बनाया नहीं गया। चरण 03, शाखा “vhost हाथ से बनाएँ”।
  • sudo rules NOT written — स्क्रिप्ट यह तय नहीं कर पाई कि पैनल किस अकाउंट के तहत काम करता है। यह सामान्य स्थिति है: पैनल की फ़ाइलें ऑटो-सेटअप के बाद ही अपलोड होती हैं, और तय करने के लिए तब कुछ था ही नहीं। इन नियमों के बिना मॉड्यूल सिस्टम डेटा नहीं देख पाएँगे। चरण 04, ब्लॉक “वेब-सर्वर के लिए sudo”।
  • ! Nginx does not read .htaccess — Apache के आगे Nginx है, और उसके कॉन्फ़िग में प्रतिबंध स्वतः लिखा नहीं जा सका। यह अवश्य करें: वरना data/, keys/, database/ और config.php .htaccess को दरकिनार करते हुए बाहर परोसे जाते हैं। चरण 03, ब्लॉक “अगर Apache के आगे Nginx है”।
  • UFW installed but inactive — फ़ायरवॉल इंस्टॉल है, पर बंद है: सेट किए गए सर्वर पर स्क्रिप्ट उसे खुद चालू नहीं करती, ताकि आपकी पहुँच न कट जाए। उसे स्वयं चालू करें, अपना SSH-पोर्ट अवश्य अनुमत करते हुए:
    sudo ufw allow OpenSSH # ग़ैर-मानक SSH पोर्ट: sudo ufw allow 2222/tcp sudo ufw allow 80,443/tcp sudo ufw enable
  • Fail2ban installed but not running — चालू करें: sudo systemctl enable --now fail2ban।
  • Database server present … but not running — चरण 04 से पहले DBMS चालू करें: sudo systemctl enable --now mariadb (या mysql — जो लगा हो उसके अनुसार)।
  • Certbot skipped — issue SSL in … — प्रमाणपत्र होस्टिंग-पैनल में Let's Encrypt के स्विच से जारी होता है; चरण 06 आपके लिए ज़रूरी नहीं।
यदि जाँचों के ब्लॉक में सब ठीक है, तो अंतिम पंक्ति होगी — All checks passed। ! वाले बिंदुओं पर ध्यान देना ज़रूरी है; विवरण लॉग में लिखा जाता है, जिसका पथ स्क्रिप्ट बिल्कुल अंत में छापती है (Log: …)।

02. डोमेन और DNS

पैनल को monitor.example.com जैसे पते पर खोलने और मुफ़्त SSL पाने के लिए, डोमेन को सर्वर की ओर इंगित करना चाहिए। DNS प्रबंधन पैनल में (रजिस्ट्रार या होस्टर के पास) एक A-रिकॉर्ड बनाएँ:

प्रकार: A नाम: monitor (सबडोमेन → monitor.example.com) या @ (डोमेन रूट → example.com) मान: 203.0.113.10 ← आपके सर्वर का IP TTL: 3600

कुछ मिनटों बाद (कभी-कभी एक घंटे तक) जाँचें कि डोमेन सर्वर की ओर इंगित करता है:

dig +short monitor.example.com # आपका IP लौटाना चाहिए # या, अगर dig न हो: getent hosts monitor.example.com
SSL प्रमाणपत्र (चरण 06) केवल डोमेन पर जारी होता है — इसलिए प्रमाणपत्र जारी होने से पहले DNS को सर्वर की ओर इंगित करना चाहिए।

03. पैनल की फ़ाइलें अपलोड करें

सामान्य स्थिति (नया VPS)। ऑटो-सेटअप ने पैनल की डायरेक्टरी /var/www/monitor पहले ही बना दी है और Apache साइट कॉन्फ़िगर कर दी है (DocumentRoot पैनल की रूट पर, PHP-FPM, .htaccess के लिए AllowOverride)। स्क्रिप्ट के आउटपुट में यह vhost … → DocumentRoot … पंक्ति होती है। अलग से डायरेक्टरी और vhost बनाने की ज़रूरत नहीं — बस फ़ाइलें अपलोड करें और अनुमतियाँ सेट करें।
दो स्थितियाँ, जब vhost नहीं बनाया जाता — स्क्रिप्ट अपने काम के अंत में इसकी सीधी सूचना देती है। तब पहले नीचे दी गई उपयुक्त शाखा पूरी करें, और उसके बाद ही फ़ाइलें अपलोड करें।

शाखा “होस्टिंग-पैनल वाला सर्वर” (आउटपुट में: Control panel detected (…))। ऐसे सर्वर पर साइटों का प्रबंधन पैनल करता है, और अपना vhost स्क्रिप्ट जान-बूझकर नहीं बनाती — पैनल द्वारा कॉन्फ़िग की पहली ही पुनर्रचना पर वह मिट जाता। क्रम इस प्रकार है:

  1. होस्टिंग पैनल (HestiaCP आदि) में एक वेब-डोमेन बनाएँ — उसका DocumentRoot वैसा ही रहने दें।
  2. डिस्ट्रीब्यूशन को पूरा इस डोमेन के public_html में अपलोड करें: index.php, api/, assets/ के साथ-साथ सेवा वाली config.php, includes/, data/, tmp/, logs/, keys/, cron/, database/ भी वहीं होनी चाहिए। वेब-रूट से ऊपर कुछ भी निकालने की ज़रूरत नहीं: सेवा वाले फ़ोल्डर डिस्ट्रीब्यूशन की .htaccess फ़ाइल से बंद हैं, और Nginx के तहत — उस प्रतिबंध से जो स्क्रिप्ट ने डोमेन के कॉन्फ़िग में लिख दिया है।
  3. SSL पैनल में ही Let's Encrypt के स्विच से जारी होता है — चरण 06 छोड़ दें।
  4. आगे — अनुमतियाँ (इसी चरण में नीचे), डेटाबेस (चरण 04) और config.php (चरण 05)। कमांड में पथ /home/account/web/domain/public_html से बदलें, और मालिक — www-data की जगह इस डोमेन के उपयोगकर्ता से।

शाखा “vhost हाथ से बनाएँ” (आउटपुट में: No vhost created (no domain given))। ऐसा केवल “सेट किया गया सर्वर” प्रोफ़ाइल पर होता है, जब डोमेन पास नहीं किया गया था। सबसे आसान है — अकाउंट से मिली कमांड को डोमेन बताते हुए फिर से चलाना:

curl -fsSL "https://my.arciveo.com/install.php?token=YOUR_TOKEN&profile=existing" | sudo bash -s -- monitor.example.com

दोबारा चलाना सुरक्षित है: जो पहले हो चुका है वह दोहराया नहीं जाता। और अगर vhost हाथ से ही बनाना हो — यह रहा वही कॉन्फ़िग जो इंस्टॉलर लिखता है:

sudo mkdir -p /var/www/monitor # PHP-FPM सॉकेट स्वतः पहचाना जाता है — सर्वरों पर PHP का संस्करण अलग-अलग होता है। PHPSOCK=$(ls -1 /run/php/php*-fpm.sock 2>/dev/null | head -1) sudo tee /etc/apache2/sites-available/arciveo-monitor.conf > /dev/null <<'EOF' <VirtualHost *:80> ServerName monitor.example.com DocumentRoot /var/www/monitor <Directory /var/www/monitor> Options -Indexes +FollowSymLinks AllowOverride All Require all granted </Directory> <FilesMatch "\.php$"> SetHandler "proxy:unix:__PHPSOCK__|fcgi://localhost" </FilesMatch> ErrorLog ${APACHE_LOG_DIR}/arciveo-monitor_error.log CustomLog ${APACHE_LOG_DIR}/arciveo-monitor_requests.log combined </VirtualHost> EOF sudo sed -i "s#__PHPSOCK__#${PHPSOCK}#" /etc/apache2/sites-available/arciveo-monitor.conf sudo a2ensite arciveo-monitor.conf sudo apache2ctl configtest sudo systemctl reload apache2
यहाँ ServerName अनिवार्य है। बिना नाम वाला vhost Apache की डिफ़ॉल्ट साइट बन जाता है और उसी सर्वर पर मौजूद दूसरे डोमेन के लिए जवाब देने लगता है। इसी कारण सेट किए गए सर्वर पर 000-default.conf बंद न करें: यह साइट किसी चालू साइट के लिए बदली गई हो सकती है — नए VPS पर इंस्टॉलर उसे खुद हटा देता है, यहाँ ऐसा करने की ज़रूरत नहीं।
अगर Apache के आगे Nginx है (आउटपुट में: ! Nginx does not read .htaccess)। Nginx स्थिर फ़ाइलें सीधे डिस्क से परोसता है और .htaccess नहीं पढ़ता — सेवा वाले फ़ोल्डर बाहर से खुले रह जाएँगे, भले ही Apache उन्हें सही तरीके से बंद करता हो। स्क्रिप्ट ने प्रतिबंधों वाली फ़ाइल पहले से तैयार कर दी है; उसे अपनी साइट के server{} ब्लॉक में जोड़ना है और Nginx को रीलोड करना है:
include /etc/nginx/snippets/arciveo-deny.conf;
sudo nginx -t && sudo systemctl reload nginx # जाँच: 403 लौटना चाहिए, फ़ाइल की सामग्री नहीं curl -sI https://monitor.example.com/config.php | head -1
पैनल की फ़ाइलें (डिस्ट्रीब्यूशन आर्काइव) खरीद के बाद my.arciveo.com → “डाउनलोड” अकाउंट में डाउनलोड होती हैं। सर्वर पर अपलोड करने से पहले आर्काइव को अनपैक करें।

डिस्ट्रीब्यूशन की सामग्री अपलोड करें /var/www/monitor में (ताकि अंदर public/, assets/, config.php आदि आ जाएँ) — SFTP/SCP (FileZilla / WinSCP) के ज़रिए या अपने लोकल कंप्यूटर से scp कमांड से:

scp -r ./monitor/* deploy@203.0.113.10:/var/www/monitor/
vhost में आपका डोमेन तुरंत लिखा जाए (ServerName), इसके लिए उसे स्टेप 01 पर ही ऑटो-सेटअप कमांड में पास किया जाता है: … | sudo bash -s -- monitor.example.com (या अकाउंट में “पैनल डोमेन” फ़ील्ड में डोमेन दर्ज करें)। अगर डोमेन पास नहीं किया — पैनल किसी भी होस्ट पर और IP पर जवाब देता है, और ServerName को SSL जारी करते समय (स्टेप 06) certbot लिख देगा; कुछ भी दोबारा इंस्टॉल करने की ज़रूरत नहीं।
फ़ाइलों पर अनुमतियाँ सेट करें — यह अनिवार्य स्टेप है। अगर आपने root के तहत या SFTP से अपलोड किया, तो फ़ाइलें root की हैं, और वेब-सर्वर (www-data) उन्हें पढ़ नहीं पाएगा — पैनल खाली या 403 त्रुटि के साथ खुलेगा (लॉग में: .htaccess unreadable / directory not executable)। नीचे दी गई कमांड इसे ठीक करती है:
# पूरे वेबरूट की अनुमतियाँ सामान्य करें: root द्वारा बनाई डायरेक्टरी # वेब-सर्वर (www-data) के लिए अनुपलब्ध है — इसके बिना पैनल खाली पेज या 403 देता है। cd /var/www/monitor # काम की फ़ोल्डर chown से पहले बनाएँ — वरना नई डायरेक्टरियाँ root:root रहेंगी # और chmod 750 पर वेब-सर्वर (www-data) उनमें लिख नहीं पाएगा। sudo mkdir -p data/lynis data/logwatch tmp logs sudo chown -R www-data:www-data /var/www/monitor sudo find /var/www/monitor -type d -exec chmod 755 {} \; sudo find /var/www/monitor -type f -exec chmod 644 {} \; sudo chmod 640 /var/www/monitor/config.php sudo chmod 750 data tmp logs

अपने लिए SFTP से फ़ाइल अपलोड खोलें। ऊपर वाली कमांड के बाद सभी फ़ाइलें www-data की हो जाती हैं, जबकि FileZilla / WinSCP आपके अपने यूज़र से जुड़ते हैं — तब अपलोड SSH_FX_PERMISSION_DENIED (Permission denied) के साथ विफल होगा। दो विकल्पों में से एक चुनें।

विकल्प A — केवल आपके यूज़र के लिए ACL (अनुशंसित)। लिखने का अधिकार सिर्फ़ आपको मिलता है; वेब-सर्वर तब भी पैनल का कोड नहीं बदल सकता:

sudo apt install -y acl # पैनल की पूरी डायरेक्टरी पर आपके यूज़र को लिखने का अधिकार: sudo setfacl -R -m u:deploy:rwX /var/www/monitor # वही नियम डिफ़ॉल्ट के रूप में — बाद में बनने वाली फ़ाइलों और फ़ोल्डरों के लिए: sudo setfacl -R -d -m u:deploy:rwX /var/www/monitor

विकल्प B — www-data ग्रुप के ज़रिये। आसान है, लेकिन पैनल की फ़ाइलों पर लिखने का अधिकार वेब-सर्वर को भी मिल जाता है: PHP में कोई कमज़ोरी हुई तो कोड बदला जा सकता है। कमांड का क्रम मायने रखता है — config.php और वर्किंग फ़ोल्डर सबसे आख़िर में बंद किए जाते हैं:

sudo usermod -aG www-data deploy # ग्रुप को लिखने का अधिकार + setgid (बिट 2): SFTP से अपलोड की गई फ़ाइलें # www-data ग्रुप में ही रहती हैं — वरना पैनल उन्हें दोबारा नहीं लिख सकेगा। sudo find /var/www/monitor -type d -exec chmod 2775 {} \; sudo find /var/www/monitor -type f -exec chmod 664 {} \; sudo chmod 640 /var/www/monitor/config.php sudo chmod 2750 /var/www/monitor/data /var/www/monitor/tmp /var/www/monitor/logs
विकल्प B के बाद FileZilla में दोबारा कनेक्ट करें (सर्वर → डिस्कनेक्ट, फिर से लॉगिन करें) — नया ग्रुप नए लॉगिन पर ही लागू होता है, उससे पहले अधिकार फिर भी नहीं मिलेंगे। जाँच: id deploy — ग्रुप सूची में www-data दिखना चाहिए; ls -ld /var/www/monitor — अधिकार drwxrwsr-x, x की जगह s अक्षर का मतलब है कि setgid सेट है।

04. डेटाबेस

डेटाबेस और उपयोगकर्ता बनाएँ, फिर स्कीमा इम्पोर्ट करें। DB वाला ब्लॉक टर्मिनल में पूरा पेस्ट करें (sudo mysql unix-सॉकेट के ज़रिए root से लॉगिन करता है — root पासवर्ड की ज़रूरत नहीं)। monitor_db और monitor_user — उदाहरण के नाम हैं, आप अपने कोई भी नाम रख सकते हैं; डेटाबेस, उपयोगकर्ता और पासवर्ड याद रखें — अगले चरण में उन्हें config.php में डालना होगा:

# 1. डेटाबेस। डेटाबेस का नाम, उपयोगकर्ता और पासवर्ड नीचे एक ही बार सेट होते हैं और सभी लाइनों में लग जाते हैं। # ब्लॉक टर्मिनल में पूरा पेस्ट करें; sudo mysql unix-सॉकेट से root लॉगिन करता है # (root पासवर्ड की ज़रूरत नहीं)। इंटरैक्टिव `sudo mysql -u root -p` कॉपी-पेस्ट के # साथ न इस्तेमाल करें — पेस्ट करते समय SQL लाइनें पासवर्ड प्रॉम्प्ट में चली जाएँगी और खो जाएँगी। DBNAME='monitor_db' # ← डेटाबेस का नाम, वैसा ही रह सकता है DBUSER='monitor_user' # ← डेटाबेस उपयोगकर्ता, वैसा ही रह सकता है DBPASS='CHOOSE_A_PASSWORD' # ← पासवर्ड, अपना तय करें sudo mysql <<SQL CREATE DATABASE IF NOT EXISTS $DBNAME CHARACTER SET utf8mb4; CREATE USER IF NOT EXISTS '$DBUSER'@'localhost' IDENTIFIED BY '$DBPASS'; GRANT ALL ON $DBNAME.* TO '$DBUSER'@'localhost'; FLUSH PRIVILEGES; SQL # जाँच ($DBNAME दिखनी चाहिए): mysql -u "$DBUSER" -p"$DBPASS" -e "SHOW DATABASES;" # ये तीनों मान config.php → DB_NAME, DB_USER, DB_PASS में लिखें।
आमतौर पर स्कीमा इम्पोर्ट करने की ज़रूरत नहीं होती — यदि DB खाली है तो ब्राउज़र में पहली बार खोलने पर पैनल खुद ही टेबल और admin अकाउंट (database/db.sql से) बना लेता है।

अगर टेबल नहीं बनीं (पैनल DB कनेक्शन की त्रुटि दिखाता है या लॉगिन फ़ॉर्म की जगह खाली स्क्रीन) — स्कीमा हाथ से इम्पोर्ट करें। कमांड पैनल की रूट में चलाई जाती है, मान ऊपर वाले ब्लॉक से लिए जाते हैं:

# स्कीमा का इम्पोर्ट: cd /var/www/monitor && mysql -u "$DBUSER" -p"$DBPASS" "$DBNAME" < database/db.sql # जाँच — टेबल की सूची दिखनी चाहिए: mysql -u "$DBUSER" -p"$DBPASS" "$DBNAME" -e "SHOW TABLES;"
अगर $DBNAME / $DBUSER / $DBPASS वेरिएबल “भूल” चुके हैं (टर्मिनल का नया सेशन) — कमांड में मान हाथ से डालें या ऊपर वाले ब्लॉक की उन्हीं तीन पंक्तियों से उन्हें दोबारा सेट कर लें।
वेब-सर्वर के लिए sudo। आमतौर पर नियम ऑटो-सेटअप द्वारा पहले ही लिख दिए जाते हैं, और मॉड्यूल सिस्टम डेटा तुरंत देख लेते हैं। लेकिन अगर स्क्रिप्ट के आउटपुट में sudo rules NOT written पंक्ति थी — तो पैनल का अकाउंट तय करने के लिए कुछ था ही नहीं (फ़ाइलें अभी अपलोड नहीं हुई थीं), और नियम बने नहीं। इनके बिना फ़ायरवॉल, Fail2ban और CrowdSec जैसे सेक्शन खाली रहेंगे। अब जब फ़ाइलें अपनी जगह हैं, अकाउंट का नाम स्पष्ट रूप से बताते हुए अकाउंट वाली कमांड दोबारा चलाएँ:
curl -fsSL "https://my.arciveo.com/install.php?token=YOUR_TOKEN&profile=existing" | sudo ARCIVEO_USER=www-data bash -s -- monitor.example.com
www-data की जगह वह उपयोगकर्ता डालें जिसके तहत आपकी साइट का PHP चलता है (होस्टिंग-पैनल पर यह आमतौर पर डोमेन का मालिक होता है)। उसे इस तरह देखा जा सकता है:
ps -o user= -C php-fpm8.3 | sort -u # संस्करण अपना डालें # या: ps aux | grep -m3 '[p]hp-fpm'
दोबारा चलाने के बाद जाँच: फ़ाइल /etc/sudoers.d/monitor मौजूद है और उसमें आपके उपयोगकर्ता वाली पंक्तियाँ हैं।

05. config.php की सेटिंग

पैनल की रूट में मौजूद config.php (/var/www/monitor/config.php) — एकमात्र फ़ाइल है जिसे हाथ से एडिट करना ज़रूरी है। पैनल की सभी सेटिंग्स इसमें define() कॉन्स्टेंट के रूप में तय हैं। इसे एडिटर में खोलें:

sudo nano /var/www/monitor/config.php

हाइलाइट की गई जगहों पर अपने मान भरें; बाकी सब वैसा ही रहने दें:

// --- डेटाबेस (चरण 04 से) --- define('DB_HOST', 'localhost'); // वैसा ही रहने दें define('DB_NAME', 'db_name'); // चरण 04 में जो बनाया था define('DB_USER', 'user'); // चरण 04 में जो बनाया था define('DB_PASS', 'db_password'); // चरण 04 में जो तय किया था define('DB_CHARSET', 'utf8mb4'); // वैसा ही रहने दें // --- ऐप्लिकेशन --- define('APP_URL', 'https://monitor.example.com'); // पैनल का पता, अंत में स्लैश के बिना define('TIMEZONE', 'Asia/Kolkata'); // आपका टाइमज़ोन // --- सेशन का समय --- define('SESSION_LIFETIME', 28800); // दोबारा लॉगिन तक निष्क्रियता, सेकंड (28800 = 8 घंटे)

क्या बदलना है:

  • DB_NAME, DB_USER, DB_PASS — बिल्कुल वही डेटाबेस नाम, यूज़र और पासवर्ड जो आपने चरण 04 में DB बनाते समय तय किए थे (यदि उदाहरण वाले रखे — monitor_db / monitor_user)। DB_HOST और DB_CHARSET को न छुएँ।
  • APP_URL — पैनल का पूरा पता https:// के साथ, अंत में स्लैश के बिना और www के बिना। यह उसी डोमेन से मेल खाना चाहिए जिस पर आप लाइसेंस एक्टिवेट करते हैं (चरण 07), वरना की अस्वीकृत हो जाएगी।
  • TIMEZONE — आपका टाइमज़ोन (सूची — timedatectl list-timezones)। यह केवल इस पर असर डालता है कि पैनल तारीखें कैसे दिखाता है; cron-कार्यों के चलने के समय पर इसका असर नहीं होता (वहाँ सिस्टम का ज़ोन लागू होता है)।
  • SESSION_LIFETIME — कितने सेकंड की निष्क्रियता के बाद पैनल दोबारा लॉगिन माँगेगा (डिफ़ॉल्ट 8 घंटे)। उदा. 3600 = 1 घंटा, 86400 = एक दिन।
  • त्रुटि लॉगिंग का ब्लॉक (display_errors, log_errors, error_log) — डिफ़ॉल्ट पर रहने दें।

फ़ाइल सेव करें (Ctrl+O, Enter, फिर Ctrl+X) और PHP-FPM को रीस्टार्ट करें — वरना OPcache के कारण बदलाव लागू नहीं होंगे:

sudo systemctl restart php*-fpm
config.php — गोपनीय फ़ाइल है (इसमें DB का पासवर्ड है)। यह पैनल की रूट में है, जो वेब-रूट भी है, पर सुरक्षित है: अनुमतियाँ 640 (चरण 03 में सेट की गईं) और रूट के .htaccess में स्पष्ट प्रतिबंध। इसे सार्वजनिक रिपॉज़िटरी में न डालें और असली पासवर्ड के साथ सपोर्ट को न भेजें।
सभी पैरामीटर का विस्तृत विवरण — FAQ में: “config.php फ़ाइल — पैनल की सभी सेटिंग्स”।

06. SSL जारी करें (HTTPS)

डैशबोर्ड केवल HTTPS पर काम करता है। लॉगिन सेशन एक सुरक्षित cookie का उपयोग करता है, और WebAuthn (2FA) मानक के अनुसार केवल HTTPS पर काम करता है। http:// से आप लॉग इन नहीं कर पाएंगे।
होस्टिंग-पैनल वाले सर्वर पर यह चरण ज़रूरी नहीं (स्क्रिप्ट के आउटपुट में: Certbot skipped — issue SSL in …)। प्रमाणपत्र पैनल में ही वेब-डोमेन पर Let's Encrypt के स्विच से जारी होता है — इस तरह उसका नवीनीकरण भी पैनल ही करता है।

certbot और Apache का प्लगइन ऑटो-सेटअप द्वारा पहले ही इंस्टॉल हो चुके हैं। डोमेन का DNS पहले से सर्वर की ओर इंगित करना चाहिए (चरण 02)। एक कमांड में जारी करें:

sudo certbot --apache -d monitor.example.com

अगर पैनल www. से भी खुलना चाहिए — दोनों नाम एक ही कमांड में गिनाएँ, वरना दूसरे पते पर ब्राउज़र प्रमाणपत्र की चेतावनी दिखाएगा:

sudo certbot --apache -d monitor.example.com -d www.monitor.example.com
दूसरा नाम केवल तभी जोड़ें जब उस पर भी A-रिकॉर्ड हो जो इसी सर्वर की ओर इंगित करता हो (चरण 02)। वरना Let's Encrypt उसे सत्यापित नहीं कर पाएगा और पूरा प्रमाणपत्र जारी नहीं करेगा — मुख्य डोमेन समेत।
certbot क्या पूछेगा:
  1. Enter email address — आपका e-mail (वहीं सर्टिफिकेट की समाप्ति की सूचनाएं आएंगी)।
  2. Terms of Service … (Y)es/(N)o — Y।
  3. Share email with the EFF … (Y)es/(N)o — आपकी मर्ज़ी।
इसके बाद certbot खुद सर्टिफिकेट जारी करेगा, <VirtualHost *:443> लिखेगा, http→https रीडायरेक्ट और ऑटो-रिन्यूअल सेट करेगा। अंत में — Successfully enabled HTTPS।
अगर जारी करना विफल हो — जांचें कि dig +short monitor.example.com सर्वर का IP लौटाता है और पोर्ट 80/443 खुले हैं (sudo ufw allow 80,443/tcp)।

जारी करने के बाद: https://monitor.example.com ताले के साथ खुलता है, http:// https:// पर रीडायरेक्ट करता है।

07. लॉगिन और प्रारंभिक सेटअप

https://monitor.example.com खोलें, admin / useradmin से लॉगिन करें और चेकलिस्ट पूरी करें:

  1. admin पासवर्ड बदलें — मेनू में “उपयोगकर्ता” अनुभाग।
  2. WebAuthn (2FA) चालू करें — “WebAuthn कुंजियाँ” → key/passkey रजिस्टर करें (HTTPS आवश्यक)। तुरंत दो रजिस्टर करें: एकमात्र कुंजी खो जाने पर उससे लॉगिन असंभव हो जाएगा। अधिक जानें।
  3. IP द्वारा पहुँच सीमित करें — “सेटिंग्स” → “IP द्वारा पहुँच प्रतिबंध” (चालू करने से पहले अपना IP दर्ज करें, वरना अपनी ही पहुँच बंद कर लेंगे)।
  4. लाइसेंस दर्ज करें — अकाउंट से मिला एक्टिवेशन कोड ARCIVEO-… अपने डोमेन पर एक्टिवेट करें और कुंजी को “सेटिंग्स” → “लाइसेंस” में डालें। अधिक जानें।
  5. सूचनाएँ सेट करें — “सेटिंग्स” में Telegram और/या Email। अधिक जानें।
  6. इंस्टॉलर हटाएँ public/start_db.php, यदि वह बचा हो: यह बिना प्रमाणीकरण के डेटाबेस को फिर से बना सकता है। जब तक यह फ़ाइल पैनल की रूट या public/ में रहती है, पैनल लाल बैनर से इसके बारे में चेतावनी देता है।
  7. पहली जाँचें हाथ से चलाएँ — वरना कुछ सेक्शन रात तक खाली रहेंगे (नीचे वाला ब्लॉक देखें)।
“Lynis ऑडिट” और “Logwatch” शुरू में खाली क्यों हैं। ऑटो-सेटअप ने टूल इंस्टॉल किए और cron-कार्य बना दिए, लेकिन जाँचें स्वयं नहीं चलाईं — वे शेड्यूल पर चलेंगी: Lynis 03:00 बजे, Logwatch 06:00 बजे, debsums 04:30 बजे, ClamAV 01:30 बजे। तब तक सेक्शन ईमानदारी से दिखाते हैं कि रिपोर्ट अभी नहीं हैं। एक दिन इंतज़ार न करना पड़े, इसके लिए उन्हें एक बार हाथ से चला लें:
# Lynis ऑडिट — पहली रिपोर्ट (कुछ मिनट): sudo /usr/local/bin/lynis-scan.sh # एक दिन की Logwatch रिपोर्ट: sudo /usr/local/bin/logwatch_daily.sh # पैकेजों की इंटीग्रिटी (debsums) — बड़े सर्वर पर देर लगती है: sudo /usr/local/bin/debsums-scan.sh
Lynis को सीधे पैनल से भी चलाया जा सकता है — “Lynis ऑडिट” पेज पर “ऑडिट चलाएँ” बटन: यह वही स्क्रिप्ट पृष्ठभूमि में चलाता है और रिपोर्ट खुद अपडेट कर देता है। आगे सब कुछ शेड्यूल पर चलता है, हाथ से चलाने की ज़रूरत नहीं।
पहला एंटीवायरस स्कैन (sudo /usr/local/bin/clamav-scan.sh) डिस्क और प्रोसेसर पर भारी बोझ डालता है और एक घंटे या उससे अधिक चल सकता है — चालू सर्वर पर 01:30 बजे के रात्रिकालीन रन का इंतज़ार करना बेहतर है। “डिस्क (SMART)”, “प्रदर्शन” और “सुरक्षा अपडेट” सेक्शन खुद भरते हैं: क्रमशः हर 30 मिनट, 5 मिनट और घंटे में एक बार।
हो गया। हर उपकरण की जानकारी FAQ में है।
यदि इस सर्वर पर अपने डोमेन के साथ एक और साइट चाहिए — FAQ देखें: “इसी सर्वर पर दूसरी साइट (एक और डोमेन)”।
तरीका चुनें FAQ-संदर्भिका