NcStatusCheck

एकाधिक Nextcloud इंस्टेंस के लिए केंद्रीकृत निगरानी

NcStatusCheck एक निगरानी उपकरण है जो आपको एक ही वेब इंटरफ़ेस से कई Nextcloud सर्वरों के स्वास्थ्य को ट्रैक करने देता है। यह Nextcloud और PHP संस्करणों का विश्लेषण करता है और अद्यतन अनुशंसाएँ प्रदान करता है।

🎯 विशेषताएँ

निगरानी

• एकाधिक Nextcloud इंस्टेंस की स्वचालित निगरानी
• प्रति सर्वर तीन डेटा संग्रह मोड: बेसिक (केवल NC संस्करण), विस्तारित (serverinfo API के माध्यम से पूर्ण डेटा), और पुश (दूरस्थ इंस्टेंस द्वारा भेजा गया डेटा)
• Nextcloud और PHP के लिए संस्करण विश्लेषण
• वेब सर्वर पहचान (nginx, Apache) और HTTP प्रोटोकॉल
• अप/डाउन ट्रैकिंग (मिनी अपटाइम): वर्तमान पहुँच क्षमता + अंतिम स्थिति परिवर्तन, केवल डाउन होने पर लाल "ऑफ़लाइन" बैज के रूप में दिखाया जाता है। एक सीमित संक्रमण जर्नल विस्तार पृष्ठ पर 30-दिन की उपलब्धता% और हाल की घटनाओं की सूची को भी फीड करता है
• SSL प्रमाणपत्र समाप्ति चेतावनी: मौजूदा HTTPS जांच से पढ़ा गया (कोई अतिरिक्त अनुरोध नहीं), जब प्रमाणपत्र जल्द समाप्त होने वाला हो तो बैज (< 15d / < 7d)
• स्थापित ऐप्स ऑडिट: occ app:list को Nextcloud ऐप स्टोर के विरुद्ध क्रॉस-चेक करके समीक्षा के लिए ऐप्स को फ़्लैग करता है — अवरोधक (अपग्रेड-अवरोधक, असंगत, उत्पादन में परीक्षण ऐप्स) साथ ही सूचनात्मक परिपक्वता/अशांति संकेत (हाल ही में प्रकाशित, प्री-1.0, अल्फा/बीटा/आरसी बिल्ड, रिलीज़ का विस्फोट, ताजा जारी संस्करण)
• बेड़े-व्यापी वॉच ब्लॉक्स: एक "Apps to watch" (📦) और एक जुड़वां "Containers to watch" (🐳) ब्लॉक प्रत्येक फ़्लैग किए गए ऐप / Docker इमेज को सभी इंस्टेंस में से एक प्रविष्टि में एकत्रित करता है, प्रति-समूह प्रकार फिल्टर और प्रभावित इंस्टेंस और उनके संस्करणों को सूचीबद्ध करने वाले पॉपअप के साथ
• सक्रिय चेतावनियाँ (वेबहुक और/या ईमेल): पुष्टि किए गए अप/डाउन स्थिति परिवर्तन (ऑफ़लाइन, रखरखाव, पुनर्प्राप्त) पर फायर करता है ताकि आपको डैशबोर्ड खोले बिना सूचित किया जाए — Slack / Mattermost / Google Chat / Discord / रॉ JSON (ALERT_WEBHOOK_URL), और/या प्रति बैच एक डाइजेस्ट ईमेल (ALERT_EMAIL_TO) जो आपके मेल सर्वर पर सीधे SMTP सबमिशन द्वारा भेजा जाता है (vendored PHPMailer; जब कोई SMTP रिले कॉन्फ़िगर नहीं किया गया हो तो स्थानीय MTA पर वापस आ जाता है)। धीमी गति वाले संकेतों (ALERT_CHECKS) को भी शामिल करता है: SSL प्रमाणपत्र समाप्ति (स्तरीय), कमजोर/अप्रचलित Nextcloud संस्करण, पुरानी Push जांच, महत्वपूर्ण ऑडिट रिपोर्ट, अवरोधक ऐप निष्कर्ष — प्रति नई स्थिति एक चेतावनी, कोई रिमाइंडर स्पैम नहीं
• अद्यतन अनुग्रह विलंब: एक इंस्टेंस को पैच जारी होने के कुछ दिनों बाद ही पुराना के रूप में फ़्लैग किया जाता है (nc_update_grace_days), उसी दिन बग्गी रिलीज़ का पीछा करने से बचने के लिए
• स्वास्थ्य स्तंभ जो "साइलेंस = सब ठीक है" सिद्धांत का उपयोग करता है: केवल तब बैज दिखाता है (⚠️ चेतावनियाँ, 📦 ऐप्स, 🔄 Docker, 🔒 SSL, 🔴 ऑफ़लाइन, 🚧 रखरखाव) जब रिपोर्ट करने के लिए कुछ हो
• कैश सिस्टम सर्वर डेटा और आधिकारिक संस्करणों के लिए

विस्तार पृष्ठ

• प्रत्येक Nextcloud सर्वर के कॉन्फ़िगरेशन का पूर्ण दृश्य (PHP, OPcache, Redis, डेटाबेस…) विस्तारित/पुश सर्वरों के लिए
• बेसिक विस्तार पृष्ठ बिना जांच वाले सर्वरों के लिए: संस्करण, वेब सर्वर, HTTP प्रोटोकॉल और एक अपग्रेड संकेत दिखाता है
• 30-दिन की उपलब्धता% और हाल की घटनाओं की सूची (प्रारंभ, अंत, अवधि, कारण), सीमित अप/डाउन संक्रमण जर्नल से गणना की गई — ईमानदार "N दिनों में मापा गया" लेबल जब जर्नल विंडो से छोटा हो
• कॉन्फ़िगरेशन चेतावनी नियम जिनमें ⚠️ संकेतक हों, प्रत्येक स्वीकार्य (कारण + वैकल्पिक समाप्ति)
• सर्वर ऑडिट रिपोर्ट अनुभाग जब इंस्टेंस अपनी मासिक nc-audit.sh रिपोर्ट भेजता है
• किसी भी सर्वर नाम या स्वास्थ्य संकेतक पर क्लिक करके सुलभ

इंटरफ़ेस

• केंद्रीकृत डैशबोर्ड स्थिति अवलोकन के साथ (सारांश कार्ड केवल तब गैर-शून्य होने पर ऑफ़लाइन / समाप्त होने वाले प्रमाणपत्र / समीक्षा के लिए ऐप्स की संख्या दिखाते हैं)
• उन्नत फ़िल्टर Nextcloud स्थिति, PHP स्थिति, समग्र स्थिति, चालू Docker इमेज और टेक्स्ट खोज द्वारा
• आधिकारिक संस्करण स्वचालित रूप से Nextcloud स्रोतों से लाए गए
• रिलीज़ शेड्यूल आने वाले संस्करण तिथियों के साथ
• FR / EN / DE इंटरफ़ेस (ऊपरी दाएँ कोने में भाषा स्विचर)

प्रशासन

• प्रशासन इंटरफ़ेस संस्करण नियमों को कॉन्फ़िगर करने के लिए
• शीर्ष पर प्रोब मोड सारांश तालिका: तीन संग्रह विधियों (बेसिक, विस्तारित, पुश) को एक नज़र में समझाती है
• वेब UI के माध्यम से सर्वर प्रबंधन कार्ड लेआउट के साथ: दो अलग प्रोब ज़ोन (serverinfo / push), मास्क किए गए टोकन रिवील के साथ, इनलाइन डिलीट
• प्रति सर्वर "Configure probes" बटन टोकन ज़ोन को टॉगल करने के लिए, स्थिति localStorage में सहेजी गई
• रियल-टाइम सर्वर खोज एक्सेंट-असंवेदनशील मिलान के साथ
• Push स्क्रिप्ट जनरेटर: दूरस्थ Nextcloud इंस्टेंस के लिए एक उपयोग के लिए तैयार bash cron स्क्रिप्ट (chmod 700) उत्पन्न करता है, विकल्प बदलने पर स्वचालित रूप से अपडेट होता है
• डैशबोर्ड पर "Trigger Push" बटन: सभी कॉन्फ़िगर किए गए पुश सर्वरों को एक पुश अनुरोध भेजता है (केवल तब दृश्य जब कम से कम एक पुश सर्वर मौजूद हो, 5 मिनट का कूलडाउन)
• लचीला कॉन्फ़िगरेशन प्रति Nextcloud शाखा सुरक्षा थ्रेसहोल्ड का

🏗️ आर्किटेक्चर```

ncstatuscheck/ ├── Frontend │ ├── index.php # Main entry point │ ├── template.html # HTML template (dashboard) │ ├── admin.html # Administration interface │ ├── detail.php # Server detail page │ ├── audit.php # Server-audit script distribution page (nc-audit.sh) │ ├── troubleshooting.php # Probe troubleshooting guide │ ├── app.js / admin.js / detail.js / audit.js / troubleshooting.js │ └── style*.css # One stylesheet per page family ├── APIs (HTTP) │ ├── api.php # Main monitoring API │ ├── detail-api.php # Detail page API (serverinfo + warnings + acks + availability) │ ├── push-api.php # Push reception + trigger + audit-report reception │ ├── ack-api.php # Warning acknowledge / unmute │ ├── admin-api.php # Version configuration routing │ ├── servers-admin-api.php # Server list management │ ├── nextcloud-versions-api.php # Official version scraping │ ├── nextcloud-apps-api.php # App store catalog (slim cache) for the apps audit │ ├── php-versions-api.php # PHP branch support data │ └── apps-warnings-api.php # Manual app warnings (known-bug list) CRUD ├── Shared modules (lib/) │ ├── auth.php # Auth + CSRF + URL redaction (defense in depth) │ ├── csrf-client.js # Auto-inject X-CSRF-Token in fetch() │ ├── nextcloud-client.php # Centralized HTTP client → remote Nextclouds │ ├── servers-store.php # Single source of truth for servers.json │ ├── uptime-state.php # Up/down state machine + transition journal + availability │ ├── alerts.php # Proactive alert dispatch: webhook + email digest │ ├── alerts-checks.php # Slow-signal alerts (SSL/version/push/audit/apps) + dedup state │ ├── smtp-mailer.php # SMTP transport adapter over vendored PHPMailer │ ├── phpmailer/ # Vendored PHPMailer (3 files + LICENSE, pinned in VERSION) │ ├── apps-warnings-manager.php # Manual app warnings storage │ ├── ui-common.js # NcUI: notify / confirm / prompt + shared app-audit messages │ ├── url-guard.php # Anti-SSRF (loopback, RFC1918, link-local…) │ ├── json-cache.php # Locked JSON read/write helpers │ └── version-config-manager.php # Version rules CRUD ├── Business logic │ ├── version-rules.php # NC / PHP status analysis engine │ ├── warnings-rules.php # Configuration warning engine │ ├── apps-rules.php # Installed-apps audit engine (store catalog cross-check) │ ├── cron-update.php # Full collection script, CLI only (twice a day) │ └── cron-ping.php # Lightweight up/down probe, CLI only (every 5 min) ├── Tools (never web-served — blocked by nginx/.htaccess) │ ├── tools/nc-audit.sh # Standalone server audit script (root, read-only) │ └── tools/ncstatuscheck-push-core.sh # Generic Push probe core (fleet-shared) ├── Tests │ └── tests/run.php # Plain-PHP test suite (no framework): php tests/run.php ├── Configuration │ ├── config.php # Central configuration (git-ignored) │ └── servers.json # Server list with tokens (git-ignored) └── Cache ├── servers_data.json # All server data ├── serverinfo_.json # Raw per-server cache (Extended) ├── push_.json # Last push payload per server ├── ack_.json # Acknowledged warnings per server ├── audit_.json # Last nc-audit.sh report per server ├── version-config.json # Version configuration ├── uptime_state.json # Up/down state per server (mini uptime) ├── uptime_history.json # Bounded up/down transition journal (availability % + incidents) ├── alerts_state.json # "Already alerted" memory of the check alerts ├── nextcloud_versions.json # Official NC versions ├── nextcloud_apps.json # App store slim catalog (apps audit) ├── apps-warnings.json # Manual app warnings (admin-curated) ├── .csrf_secret # CSRF HMAC secret (binary, 0600) └── *.log # Activity logs

deploy/ansible/ # Fleet deployment of the Push core (Ansible / scp) deploy/docker/ # Container packaging of the monitor itself

## 🔌 संग्रह मोड

मोड परस्पर अनन्य नहीं हैं — एक सर्वर एक साथ विस्तारित और पुश हो सकता है।

| मोड | बैज | स्रोत | एकत्रित डेटा |
|------|-------|--------|----------------|
| **मूल** | *(कोई नहीं)* | `/status.php` + HTTP हेडर | Nextcloud संस्करण (PHP/वेबसर्वर यदि उजागर हो) |
| **विस्तारित** | `⚡ Extended` (त्रुटि/पुराना होने पर बैंगनी → नारंगी) | `/ocs/v2.php/apps/serverinfo/api/v1/info` with `NC-Token` | NC संस्करण, PHP, वेब सर्वर, OPcache, Redis, DB, सक्रिय उपयोगकर्ता… |
| **पुश** | `📡 Push` (त्रुटि/पुराना होने पर नीला → नारंगी) | POST to `push-api.php` | रिमोट NC इंस्टेंस द्वारा क्रॉन स्क्रिप्ट के माध्यम से धकेला गया डेटा |

**serverinfo NC-Token** **Nextcloud सेटिंग्स → प्रशासन → सिस्टम** में उपलब्ध है।

**पुश टोकन** प्रशासन इंटरफ़ेस से उत्पन्न होता है; व्यवस्थापक निगरानी किए गए इंस्टेंस पर तैनात करने के लिए एक उपयोग-के-लिए-तैयार bash क्रॉन स्क्रिप्ट (`chmod 700`) प्रदान करता है।

विस्तारित मोड डेटा [nextcloud/serverinfo](https://github.com/nextcloud/serverinfo) ऐप द्वारा प्रदान किया जाता है, जिसे निगरानी किए गए इंस्टेंस पर स्थापित और सक्षम होना चाहिए।

**फ़ॉलबैक व्यवहार**: यदि विस्तारित API अप्राप्य है (कनेक्शन त्रुटि, अमान्य टोकन, ऐप स्थापित नहीं), तो NcStatusCheck स्वचालित रूप से कम से कम Nextcloud संस्करण प्राप्त करने के लिए `/status.php` पर वापस आ जाता है।

**पुश पुरानापन सीमा**: यदि `auto_push_interval + 30 मिनट` के भीतर कोई डेटा प्राप्त नहीं हुआ है तो पुश सर्वर को पुराना माना जाता है। डिफ़ॉल्ट पुश अंतराल 12 घंटे है।

### डैशबोर्ड तालिका स्तंभ

मुख्य डैशबोर्ड 5 स्तंभ दिखाता है: **सर्वर** | **NC संस्करण** | **PHP** | **प्रोब** | **स्वास्थ्य**

प्रोब स्तंभ प्रत्येक सर्वर के लिए सक्रिय संग्रह मोड प्रदर्शित करता है:
- `⚡ Extended` बैज (बैंगनी, कनेक्शन त्रुटि या पुराने डेटा पर नारंगी हो जाता है)
- `📡 Push` बैज (नीला, सीमा के भीतर कोई डेटा प्राप्त न होने पर नारंगी हो जाता है)
- यदि दोनों मोड सक्रिय हैं तो दोनों बैज एक साथ दिखाई दे सकते हैं
- कोई बैज नहीं = केवल मूल मोड

### स्वास्थ्य स्तंभ

स्वास्थ्य स्तंभ तभी कुछ दिखाता है जब कार्रवाई करने की आवश्यकता हो:

| संकेतक | बैज | अर्थ |
|-----------|-------|---------|
| ऑफ़लाइन | `🔴 Offline` | इंस्टेंस अप्राप्य (HTTP प्रोब विफल), 'X के लिए ऑफ़लाइन' के साथ |
| सक्रिय चेतावनियाँ | `⚠️ N` | N कॉन्फ़िगरेशन समस्याएँ |
| ऐप्स ऑडिट | `📦 N` | N स्थापित ऐप्स समीक्षा के लिए (अपग्रेड-अवरोधक/असंगत) |
| SSL समाप्ति | `🔒 N d` | प्रमाणपत्र जल्द समाप्त हो रहा है — नारंगी `< 15d`, लाल `< 7d` या समाप्त |
| Docker अपडेट | `🔄 M` | M कंटेनर अपडेट उपलब्ध |
| सब ठीक | *(खाली)* | रिपोर्ट करने के लिए कुछ नहीं |
| कोई डेटा नहीं | `?` | बिना पुश डेटा के मूल मोड |

#### अप/डाउन और SSL समाप्ति

NcStatusCheck प्रति सर्वर एक **न्यूनतम** अप/डाउन स्थिति रखता है (केवल वर्तमान स्थिति + अंतिम परिवर्तन तिथि — कोई समय श्रृंखला, कोई इतिहास पृष्ठ नहीं)। 'अप' का अर्थ है कि आउटबाउंड HTTPS प्रोब इंस्टेंस तक पहुँच गया; एक लाल **Offline** बैज केवल डाउन होने पर दिखाई देता है। उसी HTTPS प्रोब के दौरान, **SSL प्रमाणपत्र समाप्ति** मुफ्त में पढ़ी जाती है (`CURLOPT_CERTINFO`) और जब वह निकट आती है तो सामने लाई जाती है। दोनों विस्तृत पृष्ठ पर पूरी तरह दिखाई देते हैं। *नोट: ये आउटबाउंड जाँचें केवल-पुश इंस्टेंस पर लागू नहीं होती हैं जिनसे मॉनिटर कभी संपर्क नहीं करता।*

#### ऐप्स ऑडिट (`📦`)

जब कोई पुश सर्वर अपने स्थापित ऐप्स (`occ app:list`, पुश स्क्रिप्ट v3+) की रिपोर्ट करता है, तो NcStatusCheck उन्हें Nextcloud ऐप स्टोर कैटलॉग के विरुद्ध क्रॉस-चेक करता है और समीक्षा योग्य ऐप्स को फ़्लैग करता है। **केवल संकेतन** — उपकरण कभी कुछ अक्षम नहीं करता; यह उम्मीदवारों को सामने लाता है (यह नहीं जान सकता कि कोई ऐप वास्तव में उपयोग किया जाता है या नहीं)। केवल **तथ्यात्मक, द्विआधारी** संकेतों का उपयोग किया जाता है। `📦 N` बैज अवरोधक निष्कर्षों की गणना करता है (वर्तमान NC संस्करण के लिए कोई संगत रिलीज़ नहीं, NC N+1 के लिए कोई रिलीज़ नहीं → अपग्रेड को अवरुद्ध करता है, या उत्पादन में सक्षम छोड़ा गया परीक्षण/देव ऐप)। सूचनात्मक निष्कर्ष (इंस्टेंस पर ऐप पुराना, अपस्ट्रीम द्वारा छोड़ा गया, PHP असंगत) केवल विस्तृत पृष्ठ पर दिखाए जाते हैं। चेतावनियों के समान स्वीकार तंत्र के माध्यम से निष्कर्षों को म्यूट किया जा सकता है।

### `servers.json` प्रारूप```json
[
  {"url": "https://cloud.example.com"},
  {"url": "https://cloud2.example.com", "serverinfo_token": "abc123def456"},
  {"url": "https://cloud3.example.com", "serverinfo_token": "...", "push_token": "xyz789"}
]

🚀 स्थापना

पूर्वापेक्षाएँ

• PHP 8.1+ with cURL and JSON extensions — वह सिंटैक्स फ़्लोर है जिसके खिलाफ CI परीक्षण करता है, तैनाती अनुशंसा नहीं: 8.1 और 8.2 दोनों पहले ही अपनी सुरक्षा-समर्थन समाप्ति तिथि पार कर चुके हैं, इंटरनेट-सामना करने वाली किसी भी चीज़ के लिए वर्तमान में समर्थित संस्करण (इस लेखन के अनुसार 8.3+) का उपयोग करें
• वेब सर्वर nginx या Apache HTTPS के साथ
• नेटवर्क पहुंच निगरानी के लिए Nextcloud सर्वरों तक

वेब सर्वर कॉन्फ़िगरेशन (nginx)```nginx

server { server_name monitoring.your-domain.com; root /var/www/ncstatuscheck; index index.php;

# HTTP Basic Authentication
auth_basic "Monitoring Access";
auth_basic_user_file /etc/nginx/.htpasswd;

# Protect sensitive files/dirs (tests/run.php has no CLI-only guard — it must
# never be reachable over HTTP; same blocklist as deploy/docker/nginx.conf)
location ~ ^/(cache/|\.git|deploy/|tools/|tests/) {
    deny all;
    return 404;
}

# .txt covers servers.txt (legacy server list — real monitored URLs)
location ~* \.(log|json|txt)$ {
    deny all;
    return 404;
}

# Security headers for static HTML pages (admin.html, template.html).
# PHP pages (index.php, detail.php) send the same headers themselves
# via send_security_headers() in lib/auth.php.
location ~* \.html$ {
    add_header X-Content-Type-Options nosniff always;
    add_header X-Frame-Options DENY always;
    add_header Referrer-Policy no-referrer always;
    add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; connect-src 'self'; frame-ancestors 'none'; base-uri 'self'" always;
    try_files $uri =404;
}

# Standard PHP configuration (adjust the socket to your PHP version —
# use a security-supported one: 8.2 has been EOL since December 2025)
location ~ \.php$ {
    fastcgi_pass unix:/run/php/php8.4-fpm.sock;
    fastcgi_index index.php;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

location / {
    try_files $uri $uri/ =404;
}

}

> **Apache**: रिपॉजिटरी में `.htaccess` फ़ाइलें शामिल हैं जो उपरोक्त `deny` नियमों को दर्शाती हैं (रूट: `*.log`/`*.json`/`*.txt` और `.git` को ब्लॉक करती हैं; `cache/`, `tools/`, `deploy/`, `tests/`: `Require all denied`)। ये केवल तभी काम करती हैं जब vhost `AllowOverride FileInfo AuthConfig` (या `All`) सेट करता है — `/var/www` के लिए Debian का डिफ़ॉल्ट `AllowOverride None` है, ऐसी स्थिति में नियमों को सीधे vhost में दोहराएं। HTTP बेसिक प्रमाणीकरण को किसी भी स्थिति में vhost में कॉन्फ़िगर करना होगा।

### परिनियोजन

1. **रिपॉजिटरी को क्लोन करें**```bash
git clone https://gitlab.com/jp.louvel/ncstatuscheck.git
cd ncstatuscheck

2. कॉन्फ़िगरेशन अपना कॉन्फ़िगरेशन फ़ाइल टेम्पलेट से बनाएं:```bash cp config-example.php config.php

`config.php` को संपादित करें और अपने वातावरण के लिए पथ और URL को समायोजित करें:```php
define('MONITOR_PATH', '/var/www/ncstatuscheck');
define('MONITOR_URL', 'https://monitoring.your-domain.com'); // your public URL
define('CACHE_DIR', MONITOR_PATH . '/cache');

3. सर्वर जोड़ें

सर्वर सीधे प्रशासन इंटरफ़ेस (⚙️ एडमिन बटन) से प्रबंधित किए जाते हैं। आप मैन्युअल रूप से servers.json भी बना सकते हैं:```json [ {"url": "https://cloud.example.com"}, {"url": "https://nextcloud.mycompany.org", "serverinfo_token": "your_token_here"} ]

> **`servers.txt` से माइग्रेशन**: यदि `servers.txt` फ़ाइल मौजूद है, तो पहली बार एक्सेस करने पर यह स्वचालित रूप से `servers.json` में बदल जाती है। इसके बाद आप `servers.txt` को हटा सकते हैं।

4. **अनुमतियाँ सेट करें**

nginx/PHP-FPM अपने स्वयं के उपयोगकर्ता के रूप में चलते हैं (डेबियन/उबंटू पर `www-data`, RHEL-परिवार पर `nginx`/`apache` — नीचे समायोजित करें) — यदि आपने अपने लॉगिन उपयोगकर्ता के रूप में क्लोन किया है, तो वह उपयोगकर्ता लगभग निश्चित रूप से `www-data` या इसके समूह में नहीं होगा, इसलिए अकेला `chmod` वेब सर्वर को **बिल्कुल भी पहुंच नहीं** देता, पढ़ने की भी नहीं (हर अनुरोध 403/404 देता है):```bash
chown -R www-data:www-data /var/www/ncstatuscheck   # adjust the user:group to your distro

chmod 750 /var/www/ncstatuscheck
chmod 750 cache img

chmod 640 *.php *.html *.js *.css *.md
chmod 600 config.php servers.json servers.txt   # secrets / serverinfo & push tokens
chmod 660 cache/*.json cache/*.log

यदि servers.json अभी तक मौजूद नहीं है (आप इसे मैन्युअल चरण के बजाय एडमिन UI के माध्यम से बनाने दे रहे हैं), तो उपरोक्त chmod 600 का कार्य करने के लिए कुछ नहीं है — यह ठीक है: ServersStore::save() प्रत्येक लिखने पर फ़ाइल को स्वयं 0600 पर chmod करता है, इसलिए एडमिन UI के माध्यम से (पुनः) बनाया गया servers.json कभी भी सर्वर जानकारी/पुश टोकन के साथ समूह/विश्व-पठनीय नहीं रहता।

5. HTTP प्रमाणीकरण```bash htpasswd -c /etc/nginx/.htpasswd admin

6. **निर्धारित कार्य (वैकल्पिक)**

दो पूरक क्रॉन — दोनों को **एक ही `crontab -` कॉल में** स्थापित करें:
`crontab -` stdin से एक पूरी नई क्रॉनटैब स्थापित करता है, यह जोड़ता नहीं है, इसलिए
इसे दो बार (एक बार प्रति पंक्ति) चलाने पर केवल *दूसरा* कार्य बचता है — पहला
चुपचाप गायब हो जाता है, कोई त्रुटि नहीं। यह आपकी क्रॉनटैब में पहले से मौजूद किसी भी चीज़ को भी संरक्षित करता है (`crontab -l` को पहले पाइप किया गया) बजाय इसे मिटाने के:```bash
(crontab -l 2>/dev/null; cat <<'EOF'
# Full collection (NC/PHP versions, serverinfo, app-store catalog) — twice a day
0 6,18 * * * cd /var/www/ncstatuscheck && php cron-update.php
# Lightweight reachability probe (status.php only -> up/down state) — every 5 min
*/5 * * * * cd /var/www/ncstatuscheck && php cron-ping.php
EOF
) | crontab -

Re-running this appends duplicates if these lines are already present — check with crontab -l first if unsure.

cron-ping.php जानबूझकर न्यूनतम है: यह केवल प्रत्येक इंस्टेंस के status.php को जांचता है और अप/डाउन स्थिति (cache/uptime_state.json) को अपडेट करता है, ताकि यह बिना लोड के बार-बार चल सके। एक इंस्टेंस को केवल तब डाउन चिह्नित किया जाता है जब UPTIME_FAIL_THRESHOLD लगातार विफल प्रोब (डिफ़ॉल्ट 2 → 5 मिनट की कैडेंस के साथ ~10 मिनट) हों; अप में पुनर्प्राप्ति तत्काल होती है। बाकी सब के लिए पूर्ण cron-update.php अपरिवर्तित रहता है।

Docker (बेयर-मेटल के विकल्प के रूप में)

उपरोक्त चरण 1–6 के बजाय, NcStatusCheck एक छोटे docker compose स्टैक (PHP-FPM + nginx + एक क्रॉन कंटेनर) के रूप में भी चल सकता है — रिपॉजिट्री बाइंड-माउंटेड है जैसे-का-तैसा, कोई बिल्ड स्टेप या कम्पोज़र नहीं, इसलिए यह बेयर-मेटल लेआउट को बिल्कुल दर्पण करता है, बस कंटेनरीकृत है। केवल सादा HTTP (डिफ़ॉल्ट रूप से पोर्ट 8080) प्रदान करता है — इसके सामने अपना स्वयं का TLS-समाप्त करने वाला रिवर्स प्रॉक्सी रखें।

पूर्ण सेटअप — कॉन्फ़िगरेशन, अनुमतियों की समस्याएँ (uid 82, servers.json पूर्व-निर्माण), HTTP बेसिक ऑथ, क्रॉन, अपडेट और बैकअप — पूरी तरह से deploy/docker/README.md में रहता है। वहाँ से शुरू करें; यह खंड जानबूझकर केवल एक संकेत है, ताकि एक ही चरणों की दो प्रतियाँ सिंक में रखने से बचा जा सके।

📋 उपयोग

मुख्य इंटरफ़ेस

• https://monitoring.your-domain.com पर जाएँ
• अपने सभी सर्वरों की स्थिति के साथ डैशबोर्ड देखें
• स्थिति या खोज के अनुसार फ़िल्टर करने के लिए फ़िल्टर का उपयोग करें
• आधिकारिक संस्करण और रिलीज़ शेड्यूल देखें

प्रशासन

• "⚙️ प्रशासन" बटन के माध्यम से प्रशासन इंटरफ़ेस खोलें
• पृष्ठ के शीर्ष पर एक प्रोब मोड सारांश तालिका बुनियादी, विस्तारित और पुश संग्रह विधियों के बीच अंतर बताती है
• सर्वर प्रबंधन: प्रत्येक सर्वर को दो संकुचित प्रोब ज़ोन वाले कार्ड के रूप में प्रदर्शित किया जाता है:
  • सर्वरइन्फो ज़ोन: रीड टोकन कॉन्फ़िगर करें (NC → NcStatusCheck पुल)
  • पुश ज़ोन: पुश टोकन उत्पन्न करें और रिमोट इंस्टेंस के लिए उपयोग-के-लिए-तैयार क्रॉन स्क्रिप्ट डाउनलोड करें
• नेक्स्टक्लाउड कॉन्फ़िगरेशन: प्रति शाखा न्यूनतम सुरक्षित संस्करण सेट करें (पंक्तियों पर होवर प्रभाव)
• PHP कॉन्फ़िगरेशन: प्रति संस्करण अनुशंसित/समर्थित स्थिति सेट करें

विवरण पृष्ठ

किसी भी सर्वर नाम या उसके स्वास्थ्य संकेतक पर क्लिक करके पहुँचा जा सकता है।

बुनियादी सर्वरों के लिए (बिना विस्तारित या पुश प्रोब के), एक सरलीकृत पृष्ठ उपलब्ध डेटा (NC संस्करण, वेब सर्वर, HTTP प्रोटोकॉल) एक सूचना और प्रोब सक्षम करने के सुझाव के साथ दिखाता है।

विस्तारित / पुश सर्वरों के लिए, पूर्ण विवरण पृष्ठ अलग-अलग अनुभाग प्रदर्शित करता है:

API

NcStatusCheck कई REST एंडपॉइंट प्रकट करता है:

मुख्य API (api.php)

• GET ?action=get_data — डेटा लाएँ (कैश या रिफ्रेश)
• POST ?action=refresh_data — सभी सर्वरों का बलपूर्वक अपडेट

पुश API (push-api.php)

• push_token हेडर के साथ POST — रिमोट NC इंस्टेंस से पुश डेटा प्राप्त करें
• POST ?action=request_push_all — सभी कॉन्फ़िगर किए गए पुश सर्वरों से तत्काल पुश का अनुरोध करें (रिमोट क्रॉन स्क्रिप्ट द्वारा उपभोग किए जाने वाले ट्रिगर फ़्लैग को सेट करता है)

प्रशासन UI द्वारा उत्पन्न क्रॉन स्क्रिप्ट दो भागों में विभाजित है: एक सामान्य कोर /usr/local/bin/ncstatuscheck-push.sh — प्रत्येक सर्वर पर समान (सभी तर्क) जो एक छोटे प्रति-इंस्टेंस कॉन्फ़िग /etc/ncstatuscheck/<slug>.conf (SERVER_URL, SLUG, OCC_CMD, DOCKER_ENABLED, SKOPEO_ENABLED) द्वारा संचालित होता है। इसे ncstatuscheck-push.sh /etc/ncstatuscheck/<slug>.conf [--test] के रूप में लागू किया जाता है। कोर समूह/विश्व-लेखन योग्य कॉन्फ़िग (एंटी कोड-इंजेक्शन) को स्रोत करने से इनकार करता है।

यह मल्टी-टार्गेट (फैन-आउट) है: डेटा एक बार एकत्र किया जाता है और /etc/ncstatuscheck/targets-<slug>.conf (प्रति मॉनिटर एक url|push_token[|http_user|http_pass] पंक्ति) में सूचीबद्ध प्रत्येक मॉनिटर पर पुश किया जाता है। प्रत्येक मॉनिटर का प्रशासन स्वयं को पंजीकृत करने के लिए एक आइडेम्पोटेंट कमांड जारी करता है।

एक होस्ट पर कई नेक्स्टक्लाउड इंस्टेंस: प्रति-इंस्टेंस पथ मॉनिटर किए गए URL से व्युत्पन्न (जैसे → ) द्वारा प्रत्ययित होते हैं: , , , , स्थिति । केवल कोर साझा किया जाता है, इसलिए सह-स्थित इंस्टेंस कभी टकराते नहीं हैं।

विवरण API (detail-api.php)

• GET ?server=<url> — एक विस्तारित/पुश सर्वर के लिए पूर्ण सर्वरइन्फो डेटा + गणना की गई चेतावनियाँ

प्रशासन API

• admin-api.php — संस्करण कॉन्फ़िगरेशन
• servers-admin-api.php — सर्वर प्रबंधन (get_servers, add_server, remove_server, update_server_token, generate_push_token, remove_push_token)
• nextcloud-versions-api.php — आधिकारिक संस्करण

🩺 सर्वर ऑडिट (nc-audit.sh)

निगरानी से एक अलग उप-प्रणाली: एक स्टैंडअलोन, रीड-ओनली बैश स्क्रिप्ट (tools/nc-audit.sh) जो किसी नेक्स्टक्लाउड सर्वर पर रूट के रूप में एक-बार / मासिक वेब + PHP + डेटाबेस ट्यूनिंग के ऑडिट के लिए चलाई जाती है, जो मशीन की भौतिक क्षमता (RAM, CPU, डिस्क प्रकार) के विरुद्ध क्रॉस-चेक की जाती है। एक प्रबंधित-पर्यवेक्षण ऑफ़र के उद्देश्य से: ग्राहक इसे स्थापित करता है, मॉनिटर केवल रिपोर्ट प्राप्त करता है — कोई मशीन/नेटवर्क एक्सेस आवश्यक नहीं। स्क्रिप्ट केवल कॉन्फ़िगरेशन पढ़ती है (कोई परिवर्तन नहीं), एक रंगीन रिपोर्ट प्रिंट करती है और एक प्रतिलिपि /tmp में लिखती है।

यह क्या जाँचता है: सर्वर क्षमता (RAM/CPU/SSD-HDD, स्वैपपिनेस, साझा-सर्वर का पता लगाना) · नेक्स्टक्लाउड (संस्करण, क्रॉन, कैश, Redis रनटाइम, DB प्रकार, लॉग) · PHP/PHP-FPM (वास्तविक सर्विंग SAPI, OPcache रनटाइम, मल्टी-पूल मेमोरी) · Apache (MPM-जागरूक वर्कर मेमोरी) · Nginx · PostgreSQL · MariaDB · सुरक्षा स्वच्छता (fail2ban या CrowdSec + बाउंसर + समुदाय ब्लॉकलिस्ट; लंबित अपडेट / रिबूट / पुरानी लाइब्रेरी पर सेवाएँ) · RAM बजट समाधान (InnoDB + FPM + Apache बनाम वास्तविक RAM) · वैकल्पिक उपकरणों के साथ गहन विश्लेषण यदि पहले से मौजूद हों (mysqltuner, pt-variable-advisor, apache2buddy, sar/iostat)।```bash

Download (the page distributes it; the repo raw URL is public)

curl -fsSL https://gitlab.com/jp.louvel/ncstatuscheck/-/raw/master/tools/nc-audit.sh -o /usr/local/bin/nc-audit.sh chmod 700 /usr/local/bin/nc-audit.sh

sudo nc-audit.sh # auto-detect, dedicated server sudo nc-audit.sh /var/www/nextcloud # explicit path (or NC_PATH=…) sudo NC_RAM_BUDGET_PCT=50 nc-audit.sh # shared host: size to 50% of RAM

**मल्टी-इंस्टेंस होस्ट** (कई Nextclouds + एक साझा डेटाबेस). `NC_RAM_BUDGET_PCT`
तब **कुल** स्टैक बजट है; `NC_PHP_SHARE_PCT`% इसका (डिफ़ॉल्ट 60, शेष
DB + वेब + OS को कवर करता है — DB-भारी सर्वरों पर इसे कम करें) PHP हिस्सा है, जो
FPM पूल में **वजन** (एक सापेक्ष महत्व — प्रतिशत नहीं, MB नहीं) के अनुसार विभाजित होता है ताकि
प्रति पूल `pm.max_children` का लक्ष्य मिल सके:```
target = PHP_share × (weight / Σ weights) / ~50 MB per process

लक्ष्य एक सीमा है जो बजट अनुमति देता है, कोई मान नहीं जिसे आपको सेट करना है (केवल उस पूल को बढ़ाएं जो वास्तव में संतृप्त होता है)। भार आपका निर्णय है — उपकरण उनका कभी अनुमान नहीं लगाता।```bash

Weights you provide (a human judgment — the tool never guesses them):

sudo NC_RAM_BUDGET_PCT=70 NC_INSTANCES="poolA:4,poolB:2,poolC:1" nc-audit.sh

Interactive helper (terminal only): lists the pools, asks a weight for each,

prints the targets + a reusable NC_INSTANCES line:

sudo NC_RAM_BUDGET_PCT=70 nc-audit.sh --tune-fpm

**रिपोर्ट पुश-बैक** (वैकल्पिक, पुश इंफ्रास्ट्रक्चर का पुन: उपयोग करता है): `nc-audit.sh --push
/etc/ncstatuscheck/<slug>.conf` ऑडिट चलाता है और रिपोर्ट को मॉनिटर(मॉनिटर्स) पर POST करता है, जो इसे संग्रहीत करते हैं और सर्वर के विवरण पृष्ठ ("🩺 सर्वर ऑडिट" अनुभाग) पर दिखाते हैं। आमतौर पर मासिक क्रॉन। वेब पेज (एडमिन, बीटा) `audit.php` पर स्क्रिप्ट (डाउनलोड + इनलाइन + GitLab वन-लाइनर) वितरित करता है और इसका संस्करण दिखाता है।

> **गहन विश्लेषण उपकरण कभी स्थापित नहीं किए जाते** स्क्रिप्ट द्वारा — वे केवल तभी चलते हैं जब पहले से मौजूद हों (कोई `curl | bash` नहीं, कोई स्वचालित स्थापना नहीं), प्रत्येक `timeout` द्वारा सीमित।

## 🔧 उन्नत कॉन्फ़िगरेशन

### संस्करण नियम अनुकूलन

मूल्यांकन नियम प्रशासन इंटरफ़ेस के माध्यम से कॉन्फ़िगर करने योग्य हैं:

**Nextcloud स्थितियाँ:**
- `dev` — डेवलपमेंट संस्करण
- `stable` — वर्तमान स्थिर संस्करण
- `oldstable` — पिछला समर्थित स्थिर संस्करण
- `deprecated` — अप्रचलित संस्करण

**PHP स्थितियाँ:**
- `recommended` — अनुशंसित संस्करण
- `supported` — समर्थित संस्करण
- `deprecated` — अप्रचलित संस्करण

### कॉन्फ़िगरेशन चर

कॉन्फ़िगरेशन को अनुकूलित करने के लिए `config.php` को संपादित करें:```php
// Environment: 'dev' or 'prod'
define('ENV', 'prod');

// Paths and URLs
define('MONITOR_PATH', '/var/www/ncstatuscheck');
define('MONITOR_URL', 'https://monitoring.your-domain.com');

// Main server cache duration
define('CACHE_MAX_AGE', 86400); // 24 hours

// Official Nextcloud versions cache duration
define('VERSIONS_CACHE_AGE', 86400);

// Consecutive failed probes before a server is marked "down" (min 1)
define('UPTIME_FAIL_THRESHOLD', 2);

// Proactive alerts — webhook on a confirmed up/down state change.
// Empty URL = disabled. Format: 'slack' (default, also Mattermost/Google Chat),
// 'discord', or 'raw' (structured JSON). The URL usually carries a secret, so it
// is never logged in full — see config-example.php for details.
define('ALERT_WEBHOOK_URL', '');
define('ALERT_WEBHOOK_FORMAT', 'slack');

// Check alerts on top of up/down (cron-update cadence, 2×/day): SSL expiry
// tiers, vulnerable (below min_secure) or deprecated Nextcloud version, stale
// Push data, critical audit report, blocking apps-audit finding. Edge-triggered with a persisted state
// (cache/alerts_state.json): one alert per NEW condition, no reminders, re-arms
// when resolved (renewed cert, fixed/acked app…). First run arms silently.
define('ALERT_CHECKS', 'ssl,version,push_stale,audit,apps'); // '' = up/down only
define('ALERT_SSL_DAYS', '30,14,7');                          // days-left tiers

// Email channel, independent of the webhook (either one arms the alerting).
// One digest mail per batch. Recommended transport: direct SMTP submission to
// your mail server (vendored PHPMailer, lib/phpmailer/ — nothing to set up on
// the host). Without ALERT_SMTP_HOST it falls back to PHP mail() (local MTA).
define('ALERT_EMAIL_TO', '');    // comma list of recipients, '' = off
define('ALERT_EMAIL_FROM', '');  // default: ncstatuscheck@<hostname>
define('ALERT_SMTP_HOST', '');   // e.g. 'mail.example.org', '' = mail() fallback
define('ALERT_SMTP_PORT', 587);
define('ALERT_SMTP_SECURITY', 'starttls'); // 'starttls' | 'tls' | 'none'
define('ALERT_SMTP_USER', '');
define('ALERT_SMTP_PASS', '');

विकल्पों ( DEMO_MODE और PUSH_SCRIPT_VERSION सहित) की पूर्ण, टिप्पणी-सहित सूची के लिए config-example.php देखें।

🛡️ सुरक्षा

लागू किए गए उपाय

• अनिवार्य HTTP बेसिक प्रमाणीकरण, प्रत्येक एडमिन एंडपॉइंट पर एक एप्लिकेशन-स्तरीय प्रमाणीकरण जाँच द्वारा दोहराया गया (गहराई में सुरक्षा)
• CSRF सुरक्षा: प्रत्येक परिवर्तन अनुरोध पर HMAC टोकन स्वचालित रूप से इंजेक्ट किया गया (lib/csrf-client.js + csrf_require())
• प्रत्येक ऑपरेटर-आपूर्ति URL पर एंटी-SSRF गार्ड (लूपबैक, RFC1918, लिंक-लोकल अस्वीकृत; केवल HTTPS रीडायरेक्ट; कनेक्ट के बाद IP जाँच)
• Let's Encrypt प्रमाणपत्रों के साथ HTTPS आवश्यक
• डेटा फ़ाइलों और लॉग का संरक्षण: nginx नियम (ऊपर देखें) Apache के लिए शिप किए गए .htaccess फ़ाइलों द्वारा दर्पणित; servers.json स्वचालित रूप से 0600 chmod किया गया (अंदर टोकन)
• सुरक्षा हेडर (CSP, X-Frame-Options, nosniff, Referrer-Policy) प्रत्येक PHP-सेवित पृष्ठ पर
• सभी इनपुट पर सख्त URL सत्यापन
• रूट द्वारा चलाए गए क्लाइंट स्क्रिप्ट: इंस्टेंस कॉन्फ़िगरेशन रूट के रूप में स्रोत किया जाता है और टार्गेट फ़ाइल तय करती है कि एकत्रित डेटा कहाँ भेजा जाए — दोनों को तब तक अस्वीकार कर दिया जाता है जब तक वे न तो समूह/विश्व-लेखन योग्य हों और न ही किसी तीसरे पक्ष के स्वामित्व में हों
• निगरानी किए गए इंस्टेंस के बीच पृथक्करण: एक पुश तभी स्वीकार किया जाता है जब बॉडी में URL किसी प्रविष्टि से मेल खाता है और hash_equals() उस के टोकन पर पास होता है, ताकि एक समझौता किया गया निगरानी सर्वर किसी अन्य के डेटा को न तो पढ़ सके और न ही अधिलेखित कर सके। / एडमिन प्रमाणीकरण + CSRF के पीछे बैठता है। समझौता किए गए क्लाइंट परिदृश्य के विरुद्ध अंत-से-अंत सत्यापित

अनुशंसाएँ

• HTTP प्रमाणीकरण के लिए मजबूत पासवर्ड का उपयोग करें
• ज्ञात पतों तक पहुँच प्रतिबंधित करें — एडमिन IP फ़िल्टरिंग टैब आपके लिए नियम उत्पन्न करता है (नीचे देखें)
• घुसपैठ के प्रयासों के लिए लॉग की निगरानी करें
• PHP और सिस्टम निर्भरताओं को अद्यतित रखें

config.php स्वास्थ्य बैनर (एडमिन)

config.php gitignored है और प्रति सर्वर हाथ से संपादित किया जाता है, इसलिए यह बह जाता है — चुपचाप, क्योंकि लगभग हर स्थिरांक में कोड में एक फ़ॉलबैक होता है। एडमिन पृष्ठ के शीर्ष पर एक बैनर रिपोर्ट करता है कि वास्तव में क्या गलत है, और केवल तभी जब कुछ गलत हो: एक बंप द्वारा पीछे छोड़ा गया PUSH_SCRIPT_VERSION, कोई अलर्ट ट्रांसपोर्ट बिल्कुल कॉन्फ़िगर नहीं किया गया, एक अनुगामी क्लोजिंग टैग जो किसी header() से पहले एक बाइट उत्सर्जित करता है, एक अलिखनीय कैश निर्देशिका, अनुपस्थित स्थिरांक चुपचाप डिफ़ॉल्ट पर वापस आ जाते हैं।

डिज़ाइन द्वारा केवल-पढ़ने योग्य और कोई सेव क्रिया नहीं, उसी कारण से जैसे नोटिफिकेशन टैब: config.php रूट के स्वामित्व में है और इसमें रहस्य हैं। फ़ाइल सामग्री कभी यात्रा नहीं करती — केवल उसके बारे में तथ्य — और कोई रहस्य नहीं पढ़ा जाता।

IP फ़िल्टरिंग (एडमिन टैब)

ऊपर सब कुछ एप्लिकेशन-स्तरीय है: इंटरनेट पर कोई भी अभी भी मॉनिटर तक पहुँच सकता है और उसकी जाँच कर सकता है, और केवल पासवर्ड उन्हें रोकता है। IP फ़िल्टरिंग टैब उन नियमों को उत्पन्न करता है जो ऐप के सामने एक अनुमति सूची रखते हैं, ताकि अज्ञात होस्ट उससे बिल्कुल बात न कर सकें। यह गहराई में सुरक्षा है, बेसिक ऑथ या पुश टोकन का प्रतिस्थापन नहीं — और यह केवल समीक्षा और पेस्ट करने के लिए टेक्स्ट उत्पन्न करता है, यह कभी वेब सर्वर या फ़ायरवॉल कॉन्फ़िगरेशन नहीं लिखता।

दो वर्ग के स्रोत, जानबूझकर असमान, ताकि एक समझौता किया गया निगरानी सर्वर एडमिन तक नहीं पहुँच सके:

बेसिक/एक्सटेंडेड मोड में पोल किए गए इंस्टेंस कोई इनबाउंड कनेक्शन नहीं खोलते हैं और उन्हें कोई अनुमति सूची प्रविष्टि नहीं मिलती।

पते दो स्रोतों से आते हैं, और अंतर मायने रखता है: एक निगरानी किए गए डोमेन का DNS रिकॉर्ड उसका इनग्रेस पता है, जबकि इसका पुश उसके एग्रेस से निकलता है। जहाँ वे भिन्न होते हैं, केवल दूसरा काम करता है। push-api.php इसलिए प्रत्येक पुश के वास्तविक स्रोत पते को रिकॉर्ड करता है (source_ip पुश कैश में), और टैब उसे अनुमति सूची में जोड़ता है, अंतर की रिपोर्ट करता है। जब तक कोई सर्वर एक बार पुश नहीं करता, यह DNS A+AAAA पर वापस आ जाता है और ऐसा कहता है।

तीन आउटपुट:

• nginx (अनुशंसित) — एक स्व-निहित conf.d फ़ाइल (geo + map) साथ ही vhost में एक एकल if ($ncsc_forbidden) { return 403; } पंक्ति। fastcgi ब्लॉक को डुप्लिकेट करने की आवश्यकता नहीं है, स्थिर फ़ाइलें भी कवर हो जाती हैं (admin.html उनमें से एक है), और /.well-known/acme-challenge/ खुला रहता है ताकि प्रमाणपत्र नवीनीकरण चुपचाप टूट न सके।
• Apache 2.4 — नकारात्मक लुकअहेड के साथ <LocationMatch> और पुश एंडपॉइंट के लिए एक <Location>, ताकि दो खंड ओवरलैप न हो सकें और कुछ भी Apache के मर्ज क्रम पर निर्भर न हो। एक नियम के सभी पते एक Require ip पंक्ति पर जाते हैं: <RequireAll> के अंदर कई पंक्तियाँ AND की जाती हैं, जिसे कोई भी संतुष्ट नहीं कर सकता।
• ufw — स्वभाव से मोटा (पैकेट फ़िल्टर URL नहीं, बल्कि पोर्ट देखता है), इसलिए यह पुश/एडमिन विभाजन को व्यक्त नहीं कर सकता। इसे केवल बाहरी परत के रूप में उपयोग करें।

जनरेटर तब कुछ भी उत्सर्जित करने से इनकार करता है जब कोई प्रशासन पता नहीं दिया जाता है, चेतावनी देता है जब ऑपरेटर का अपना पता कवर नहीं किया जाता है, और चेतावनी देता है जब अनुरोध किसी प्रॉक्सी के माध्यम से आया है (दोनों geo और Require ip ट्रांसपोर्ट पीयर पढ़ते हैं, इसलिए प्रॉक्सी के पीछे हर क्लाइंट एक जैसा दिखता है)। उत्पन्न ufw स्निपेट SSH नियम को पहले रखता है, HTTP-01 चैलेंज के लिए पोर्ट 80 खुला रखता है, और IPv6 जाल को स्पष्ट करता है: nginx के विपरीत, जो एक अनसूचीबद्ध v6 पते को अस्वीकार करता है, ufw v6 को बिल्कुल फ़िल्टर नहीं करता जब तक कि IPV6=yes सेट न हो — एक दोहरे-स्टैक होस्ट अन्यथा IPv6 पर पूरी तरह से खुला होगा।

ज्ञात सीमा, पृष्ठ पर ही उजागर: एक बार नियम लागू होने के बाद, यह टैब कुछ भी नया खोज नहीं पाता। एक अस्वीकृत पुश वेब सर्वर द्वारा PHP तक पहुँचने से पहले ही अस्वीकार कर दिया जाता है, इसलिए रिकॉर्ड किया गया पता वही रहता है जो अंतिम बार पास हुआ था — और फिर भी सत्यापित दिखता है। दो परिणाम: एक पुश सर्वर जोड़ने का मतलब है नियमों को पुनर्जीवित करना और पुनः लागू करना, अन्यथा इसका पहला पुश अस्वीकार कर दिया जाता है; और यदि किसी इंस्टेंस का पता बदलता है, तो नया पता केवल वेब सर्वर एक्सेस लॉग में पढ़ा जा सकता है (grep 'push-api.php' access.log | grep ' 403 ')। इसलिए टैब प्रत्येक देखे गए पते की अंतिम-देखी तिथि दिखाता है और एक बार जब यह एक पूर्ण छूटे हुए पुश चक्र से अधिक पुराना हो जाता है तो उसे चिह्नित करता है — वही सीमा जो push_stale अलर्ट के समान है, जो दूसरी तरफ से उसी अंध स्थान को कवर करता है।

फ़िल्टरिंग समस्या को किसी अन्य से अलग बताना: पुश एंडपॉइंट पर एक नंगे GET को चलाने से परतों को साफ-साफ अलग किया जा सकता है, बिना किसी दुष्प्रभाव और बिना किसी टोकन की आवश्यकता के — इसे संबंधित मशीन से चलाएँ, क्योंकि जो आंका जाता है वह उस मशीन का आउटगोइंग पता है:```bash curl -sS -o /dev/null -w '%{http_code}\n' https://your-monitor/push-api.php

| उत्तर | अर्थ |
|---|---|
| `403` | IP फ़िल्टरिंग द्वारा अवरुद्ध |
| `401` | फ़िल्टरिंग पारित, बेसिक auth उत्तर दे रहा है — समस्या कहीं और है |
| `405` | अनुरोध एप्लिकेशन तक पहुंच गया (वहाँ GET स्वीकृत विधि नहीं है) |
| कुछ नहीं / टाइमआउट | फ़िल्टरिंग नहीं: एक फ़िल्टर उत्तर देता है, वह चुप नहीं रहता |

`403` पर संदेह दूर करने के लिए `-u user:password` के साथ पुनः चलाएँ: यदि कोड नहीं बदलता, तो यह वास्तव में फ़िल्टरिंग है। nginx और Apache दोनों पर सत्यापित ( `Require valid-user` सक्षम होने पर भी), फ़िल्टर प्रमाणीकरण *से पहले* उत्तर देता है — और एप्लिकेशन से आने वाला `403` हमेशा बॉडी में JSON लेकर आता है।

स्निपेट तर्क `lib/hardening-rules.php` में रहता है, जो शुद्ध है और `tests/run.php` द्वारा कवर किया गया है: यहाँ स्निपेट ही उत्पाद हैं, और गलत स्निपेट या तो ऑपरेटर को लॉक कर देता है या छेद छोड़ देता है। nginx और Apache दोनों के आउटपुट को व्यवहारिक रूप से सत्यापित किया गया है (वास्तविक सर्वर, वास्तविक स्रोत पते, `push` वर्ग से पथ-ट्रैवर्सल प्रयासों सहित)।

### स्वचालित विश्लेषण (CI `security` चरण)

निर्भरता स्कैनिंग (`npm/pnpm audit`, Snyk Open Source, Dependabot) यहाँ कोई काम नहीं करती: कोई `package.json` और कोई `composer.json` नहीं है — स्कैन करने के लिए कुछ नहीं। जोखिम कस्टम कोड (~15k PHP की पंक्तियाँ, ~6k JS की) और उन शेल स्क्रिप्ट्स में है जो निगरानी किए गए इंस्टेंस पर **रूट के रूप में** चलती हैं (`tools/*.sh`)। पाइपलाइन वहाँ लक्षित है:

| कार्य | उपकरण | अवरोधक | दायरा |
|---|---|---|---|
| `secrets_scan` | gitleaks | हाँ | कमिट किए गए रहस्य (कार्यशील ट्री) |
| `sast_semgrep` | semgrep (`p/php`, `p/javascript`, `p/owasp-top-ten`) | हाँ | SSRF, लापता authz/CSRF, XSS |
| `shellcheck` | shellcheck (`--severity=warning`) | हाँ | `tools/*.sh` — क्लाइंट होस्ट पर रूट |
| `dockerfile_misconfig` | trivy misconfig | हाँ | `deploy/docker/` |
| `container_cve` | trivy image | नहीं (`allow_failure`) | `deploy/docker` द्वारा बनाई गई इमेज, साथ ही `nginx:alpine` |
| `ui_tests` | node (कोई निर्भरता नहीं) | हाँ | `lib/ui-common.js` के एस्केपिंग अपरिवर्तनीय (पिछली दोनों XSS प्रतिगमन) |
| `phpmailer_freshness` | GitHub API | नहीं (`allow_failure`) | विक्रेता पिन बनाम अपस्ट्रीम रिलीज़ |
| `deploy_selfcheck` | nc-selfcheck.sh | हाँ | शिप किए गए nginx नियमसेट (अस्वीकार नियम + सुरक्षा हेडर) को एक डिस्पोजेबल कंटेनर में खड़ा किया गया |

सभी अवरोधक कार्यों का **शून्य-खोज आधार रेखा** है, इसलिए कोई भी नई चेतावनी वास्तविक संकेत है। दो जानबूझकर कॉल, `.gitlab-ci.yml` में इनलाइन दस्तावेजीकृत:

- **`php.lang.security.injection.echoed-request` को बाहर रखा गया है** semgrep से: यह हर `echo json_encode()` को XSS के रूप में चिह्नित करता है, जो यहाँ हर API एंडपॉइंट वैध रूप से करता है (JSON प्रतिक्रियाएँ, HTML नहीं)। पहले रन पर 10 में से 10 निष्कर्ष इसी के थे, सभी गलत सकारात्मक। इसे रखने से सभी को कार्य को अनदेखा करने की आदत हो जाएगी।
- **दो `allow_failure` कार्य अपस्ट्रीम तथ्यों की रिपोर्ट करते हैं** (`nginx:alpine` में CVE या जिसका फिक्स अभी तक Alpine शाखा तक नहीं पहुंचा, एक नया PHPMailer रिलीज़) जिसे मर्ज अनुरोध ठीक नहीं कर सकता। लाल-लेकिन-सहनीय सटीक संकेत है — "पुनर्निर्माण / विक्रय को ताज़ा करने का समय" — असंबंधित कार्य को अवरुद्ध करने का कारण नहीं। `phpmailer_freshness` अप्राप्य या दर-सीमित GitHub API को *छोड़ें* के रूप में रिपोर्ट करता है, कभी "पुराना" नहीं।
- **`container_cve` वह इमेज स्कैन करता है जो वह बनाता है, `FROM` टैग नहीं।** Dockerfile `apk --no-cache upgrade` के साथ आधार को मजबूत करता है (आधिकारिक PHP इमेज Alpine रिपॉजिटरी से पीछे है — इसने c-ares 1.34.6-r0 भेजा जबकि 1.34.8-r0, CVE-2026-33630 को ठीक करते हुए, पहले ही प्रकाशित हो चुका था)। आधार टैग को स्कैन करने से उन CVE की रिपोर्ट होगी जो शिप की गई इमेज में अब नहीं हैं: एक स्थायी रूप से नारंगी कार्य जिसे कोई नहीं पढ़ता।

अनुमति सूचियाँ जानबूझकर संकीर्ण हैं: `.gitleaks.toml` **शाब्दिक** प्लेसहोल्डर स्ट्रिंग्स को माफ करता है, कभी पूरी दस्तावेज़ फ़ाइलों को नहीं ( `README.md` को अनुमति सूची में डालने से स्कैन उस दिन अंधा हो जाएगा जब उसमें एक वास्तविक रहस्य चिपकाया जाएगा) — इसलिए दस्तावेज़ों में एक नया उदाहरण टोकन वहाँ जोड़ा जाना चाहिए। `.trivyignore` में एक ही प्रविष्टि है, `DS-0002`, फ़ाइल में तर्क दिया गया: php-fpm मास्टर को अपने वर्कर्स को `www-data` (uid 82) पर गिराने के लिए रूट के रूप में शुरू होना चाहिए।

### परिनियोजन-पश्चात सत्यापन (`nc-selfcheck.sh`)

CI *शिप* किए गए कॉन्फ़िगरेशन को लॉक कर सकता है (उपरोक्त `deploy_selfcheck` कार्य nginx नियमसेट को एक कंटेनर में खड़ा करता है और उसकी जाँच करता है), लेकिन यह उस सर्वर को सत्यापित नहीं कर सकता जिस पर आपने वास्तव में परिनियोजित किया — अलग होस्ट, बेसिक-ऑथ क्रेडेंशियल, फ़ाइलसिस्टम अनुमतियाँ। `tools/nc-selfcheck.sh` उस अंतर को बंद करता है। यह एक स्वतंत्र, केवल-पढ़ने योग्य bash स्क्रिप्ट है ( `nc-audit.sh` के समान मॉडल) जिसे आप प्रत्येक परिनियोजन के बाद चलाते हैं:```bash
# Black-box, no credentials: confirms Basic auth is enforced (401) and that
# sensitive files are blocked (cache/, servers.*, .git, config.php source).
bash tools/nc-selfcheck.sh https://monitoring.example.com

# + security headers behind Basic auth:
bash tools/nc-selfcheck.sh -u user:pass https://monitoring.example.com

# + filesystem checks (run ON the host): servers.json / config.php / CSRF-secret
# permissions, and a stray closing "?>" in config.php.
bash tools/nc-selfcheck.sh --webroot /var/www/ncstatuscheck https://monitoring.example.com

यह किसी भी महत्वपूर्ण खोज (स्रोत रिसाव, अनब्लॉक किया गया गुप्त फ़ाइल, विश्व-पठनीय टोकन स्टोर, गायब बेसिक प्रमाणीकरण) पर गैर-शून्य निकास कोड देता है, इसलिए यह एक रोलआउट को गेट कर सकता है — इसे अपने सिंक/डिप्लॉय स्क्रिप्ट में पोस्ट-स्टेप के रूप में जोड़ें। WARN/INFO कभी रन को विफल नहीं करते।

🧪 परीक्षण और विकास

विकास मोड```php

// In config.php define('ENV', 'dev');

डेवलपमेंट मोड में, अतिरिक्त जानकारी प्रदर्शित होती है (PHP संस्करण, वेब सर्वर).

### सर्वर परीक्षण
प्रशासन इंटरफ़ेस का उपयोग करके URL द्वारा एक सर्वर जोड़ें। अगले डेटा रिफ्रेश पर सर्वर की जाँच की जाएगी।

### डीबग लॉग
`cache/` में लॉग फाइलों की जाँच करें:
- `monitor.log` — सामान्य अनुप्रयोग लॉग
- `cron.log` — पूर्ण संग्रह स्क्रिप्ट लॉग (`cron-update.php`)
- `ping.log` — हल्का अप/डाउन प्रोब लॉग (`cron-ping.php`)
- `alerts.log` — सक्रिय अलर्ट प्रेषण (वेबहुक/ईमेल), कभी भी वेबहुक रहस्य या SMTP क्रेडेंशियल्स लॉग नहीं करता

### परीक्षण सूट```bash
php tests/run.php   # plain-PHP assertions, no framework — exit 0 = all green

Covers the pure business logic (version/apps rules, warnings, uptime state machine and availability, alert dedup/re-arm state machine, email builders).

🤝 योगदान

बग रिपोर्ट करना

एक नया मुद्दा खोलें जिसमें शामिल हो:

• समस्या का विस्तृत विवरण
• पुनरुत्पादन के चरण
• यदि उपलब्ध हो तो त्रुटि लॉग
• आपका पर्यावरण कॉन्फ़िगरेशन

सुधार प्रस्तावित करना

1. अपने विचार पर चर्चा करने के लिए एक मुद्दा खोलें
2. प्रोजेक्ट को फोर्क करें
3. अपनी सुविधा के लिए एक शाखा बनाएँ
4. दस्तावेज़ीकरण के साथ कार्यान्वित करें
5. मर्ज अनुरोध सबमिट करें

📝 लाइसेंस

यह प्रोजेक्ट GNU AGPL v3 के तहत लाइसेंस प्राप्त है।

👥 श्रेय

NcStatusCheck को ézéo द्वारा विकसित किया गया है, जो ओपन सोर्स समाधानों में विशेषज्ञता रखने वाली एक डिजिटल सहकारी संस्था है।

योगदानकर्ता

• ézéo टीम — प्रारंभिक विकास और रखरखाव

मदद चाहिए? मुद्दे देखें या ézéo टीम से संपर्क करें।