8.8 KiB
Dev Launcher - Platform Support Roadmap
Goal: Build comprehensive automatic platform detection that collects all system data during launcher startup and stores in reference database (.sysref.beta).
Key Principle: Launcher runs on startup, collects ALL data automatically, displays findings, stores in reference DB. No interactive menus - modules use the detected/stored data.
Phase 1: Comprehensive Automatic Detection (CURRENT)
Status: 🔄 In Progress
Step 1: System Detection at Startup ✅ DONE
- System info display at startup (show_system_overview)
- Control panel detection (cPanel, Plesk, InterWorx, Standalone)
- OS detection (CentOS, AlmaLinux, Rocky, CloudLinux, Ubuntu, Debian)
- Web server detection (Apache, Nginx, LiteSpeed, OpenLiteSpeed)
- Database detection (MySQL, MariaDB)
- PHP version detection (default + EA4 + Plesk + alt-php)
- Firewall detection (CSF, firewalld, UFW, iptables)
Step 2: Automatic Data Collection & Storage (NEXT)
-
Enhance reference-db.sh to collect platform compatibility data
- Add PLATFORM record type to .sysref:
PLATFORM|control_panel|cpanel|120.0|ok PLATFORM|os|almalinux|9|supported PLATFORM|web_server|apache|2.4.57|ok PLATFORM|php_version|8.1|available PLATFORM|compatibility|cpanel_almalinux|ok - Add health status for each component
- Add package status (installed/missing/conflict)
- Add PLATFORM record type to .sysref:
-
Enhance startup_detection() to:
- Run comprehensive detection automatically
- Call platform health checks (store results, don't display menu)
- Run OS compatibility checks (store results)
- Populate PLATFORM records in .sysref.beta
- Show summary at startup (what was detected, any issues)
Step 3: Store Platform Data in Reference DB
-
Extend .sysref format to include:
- Control panel status and features
- OS compatibility status
- Package installation status
- Service health status
- Known issues found
-
Create functions to query this data:
db_get_platform_status()- Get overall platform healthdb_get_compatibility_issues()- Get known incompatibilitiesdb_get_missing_packages()- Get required packages not installed
Step 4: Display Findings at Startup
- Show platform detection summary during initialization
- List any critical issues found
- List recommendations (upgrades, package installs, fixes)
- Cache expires with .sysref (1 hour)
Phase 2: Automatic OS Compatibility Detection
Status: ⏳ Planned
Auto-Collect for Each OS
- Package Manager State - YUM, DNF, or APT status
- Required Packages - Verify installed (httpd, apache2, mysql, etc.)
- Service Manager - Detect systemd vs init
- Apache Binary - Detect httpd vs apache2
- MySQL Socket - Detect correct socket path
- Firewall Type - Auto-detect running firewall
- PHP Installation - Detect all available PHP versions
- Repository Config - Detect EPEL, Remi, Ondrej PPAs
Store Results in .sysref
- Package installation status per OS
- Service availability status
- Path configuration status
- Version support timeline
- Known incompatibilities
Phase 3: Control Panel Feature Auto-Discovery
Status: ⏳ Planned
Auto-Detect & Store for Each Panel
cPanel:
- Installed EA4 modules
- Installed plugins (AutoSSL, Immuify, etc.)
- cPanel API version
- License status
Plesk:
- Installed extensions (Qmail, Nginx, etc.)
- Module status (mail, web, dns, etc.)
- License information
- Version-specific features
InterWorx:
- Installed modules
- NodeWorx API availability
- Custom plugins
CloudLinux:
- LVE limits per account
- alt-php selector availability
- CloudLinux tools availability
Store in .sysref as PLATFORM records
Phase 4: Database & PHP Auto-Discovery
Status: ⏳ Planned
Automatic Database Data Collection
- MySQL/MariaDB version and type
- Percona Server detection
- Database cluster detection (Galera)
- Replication status
- Backup tools detection (Acronis, Bacula)
- Store database inventory in .sysref (already have DB records)
Automatic PHP Detection (Already Partial)
- All installed PHP versions (default + EA4 + Plesk + alt-php)
- PHP module availability per version
- PHP-FPM pool detection
- OPcache status per version
- Per-domain PHP version mapping (query from configs)
Store PHP Data in .sysref
- PHP versions available
- Default PHP version
- PHP modules per version
- PHP-FPM pool count
Phase 5: Service Status Auto-Collection
Status: ⏳ Planned
Automatic Service Health Check
- Essential services (Apache/Nginx, MySQL, PHP-FPM, SSH)
- Control panel services (cpanel, sw-engine, iworx)
- Mail service (Exim/Postfix)
- Firewall service
- Store status in .sysref as SERVICE records:
SERVICE|apache|running|ok SERVICE|mysql|running|ok SERVICE|php-fpm|running|warning SERVICE|firewall|active|ok
Automatic Issue Detection
- Missing critical services
- Services that should be running but aren't
- Port conflicts (multiple web servers on port 80)
- Store findings as ISSUE records
Phase 6: Reference Database Queries
Status: ⏳ Planned
Add Query Functions to reference-db.sh
db_get_platform_info()- Get all platform datadb_get_compatibility_issues()- Get known issuesdb_get_service_status()- Get service statesdb_get_missing_packages()- Get uninstalled packagesdb_get_recommendations()- Get suggested actions
Modules Use These to Make Decisions
Instead of detecting themselves, modules query the data:
- Modules call
db_get_platform_info()to know the platform - Modules call
db_get_service_status()before running - Modules check
db_get_missing_packages()to suggest installs - Modules suggest actions based on
db_get_recommendations()
Implementation Priority
IMMEDIATE (Phase 1 - Step 2-4)
- ⏳ Enhance reference-db.sh to collect platform data automatically
- ⏳ Add PLATFORM record type to .sysref format
- ⏳ Update startup_detection() to run comprehensive checks
- ⏳ Display platform findings during initialization
NEAR TERM (Phase 2-3)
- ⏳ Add OS compatibility data collection to startup
- ⏳ Add control panel feature auto-discovery
- ⏳ Store all findings in .sysref.beta
MEDIUM TERM (Phase 4-5)
- ⏳ Database & PHP data collection
- ⏳ Service status auto-detection
- ⏳ Issue detection and storage
LONG TERM (Phase 6)
- ⏳ Query functions in reference-db.sh
- ⏳ Modules refactored to use cached data
Testing Strategy
By Control Panel
- Test on cPanel/RHEL
- Test on Plesk/Ubuntu
- Test on InterWorx/Rocky
- Test on Standalone/Debian
By OS
- CentOS 7/8/9
- AlmaLinux 8/9
- Rocky Linux 8/9
- CloudLinux 7/8/9
- Ubuntu 20.04/22.04/24.04
- Debian 11/12
Coverage Matrix
- All 4 control panels × 6 OSes = 24 test combinations
- Plus 4 web servers, 2 DB types, multiple PHP versions
Success Criteria
- ✅ Launcher detects all 4 control panels automatically
- ✅ Launcher detects all 6 OS types automatically
- ✅ All platform data stored in .sysref.beta on startup
- ✅ Platform summary displayed during initialization
- ✅ Critical issues flagged (missing packages, incompatibilities)
- ✅ Modules query cached data instead of re-detecting
- ✅ No interactive menus - launcher is pure data collection
Files to Create/Modify
Enhanced Files
lib/reference-db.sh- Add PLATFORM record collection and querieslib/system-detect.sh- Comprehensive automatic detectionlauncher.sh- Enhanced startup_detection() to store all findings
New Functions in reference-db.sh
collect_platform_data()- Gather all platform infodb_get_platform_info()- Query platform datadb_get_compatibility_issues()- Query issues founddb_get_service_status()- Query service statesdb_get_missing_packages()- Query missing packages
Standalone Diagnostic Modules (Optional)
modules/diagnostics/platform-health-check.sh- For manual health checksmodules/diagnostics/os-compatibility-check.sh- For manual compatibility checks- Note: These are optional modules for users to run manually, not part of launcher
Knowledge Base Integration
This roadmap uses the comprehensive knowledge base at /root/.claude/knowledge-base/:
control-panels/*/- Platform-specific implementation detailsoperating-systems/*/- OS-specific configuration and differencesdatabases/*/- Database detection and managementshared-systems/php-version-detection.md- PHP multi-version handling
Last Updated: 2026-03-19 Created By: Claude Code - Dev Session Status: Active Development