PROBLEM: Live monitor showed static CT_LIMIT="100" recommendation
- No analysis of actual site traffic
- No consideration of legitimate high-connection users
- Could block CDNs, bots, or legitimate traffic spikes
- No way to know what's safe for the specific server
SOLUTION: Created comprehensive CT_LIMIT optimizer script
NEW SCRIPT: modules/security/optimize-ct-limit.sh
WHAT IT DOES:
1. Analyzes Apache logs (last 24 hours by default)
- Parses all domain logs in /var/log/apache2/domlogs/
- Tracks max concurrent connections per IP per domain
- Identifies user agents and behavior patterns
2. Classifies IP behavior using bot-signatures.sh
- Legitimate bots (Googlebot, Bingbot, etc.)
- AI crawlers (GPT, Claude, etc.)
- CDNs (Cloudflare, Akamai, etc.)
- Normal users vs high-traffic users
- Potential scrapers
3. Analyzes current active connections
- Uses ss or netstat to check real-time connections
- Identifies current highest connection counts
4. Calculates statistics
- 95th percentile of legitimate user connections
- 99th percentile for headroom
- Max concurrent from single legitimate IP
- Separates bot/CDN traffic from user traffic
5. Provides 3 recommendations:
a) CONSERVATIVE (max_legit + 20) - For high-traffic sites
b) BALANCED (max_legit + 10) - Recommended for most ⭐
c) AGGRESSIVE (max_legit + 5) - Only during active attack
6. Whitelist recommendations
- Identifies bots/CDNs exceeding recommended limit
- Suggests specific IPs to whitelist in CSF
- Prevents blocking Googlebot, monitoring services, etc.
7. One-command application
- Backs up csf.conf automatically
- Updates CT_LIMIT to recommended value
- Enables SYNFLOOD protection
- Restarts CSF
- Provides monitoring command
EXAMPLE OUTPUT:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Connection Analysis Summary:
Total unique IPs analyzed: 1,247
Legitimate users: 1,180
Bots/CDNs/Crawlers: 67
Legitimate User Connection Patterns:
Max concurrent from single IP: 45
95th percentile: 12 concurrent connections
99th percentile: 28 concurrent connections
Current Active Connections:
Highest right now: 8 connections from 1.2.3.4
Current CSF Configuration:
CT_LIMIT = 150
📊 RECOMMENDED CT_LIMIT VALUES
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. CONSERVATIVE: CT_LIMIT = 65
• Allows headroom for traffic spikes
• Won't block legitimate users
2. BALANCED: CT_LIMIT = 55 ⭐
• Based on 99th percentile + buffer
• Blocks most attack traffic
3. AGGRESSIVE: CT_LIMIT = 50
• Maximum DDoS protection
• May affect some legitimate users
⚠️ WHITELIST RECOMMENDATIONS
Found bots/crawlers with high connection counts:
• 66.249.72.38 (Googlebot) 82 connections
• 40.77.167.88 (Bingbot) 65 connections
• 157.55.39.183 (UptimeRobot) 48 connections
To whitelist: csf -a <IP>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
INTEGRATION WITH LIVE MONITOR:
- Press 'c' during live monitoring to run optimizer
- Recommendation updates based on detected DDoS/SYN floods
- Quick Actions panel shows: "Press 'c' to run CT_LIMIT optimizer"
- Help screen updated with 'c' key
USAGE:
1. Standalone: modules/security/optimize-ct-limit.sh
2. From live monitor: Press 'c' during monitoring
3. With custom period: optimize-ct-limit.sh 48 (48 hours)
SAFETY:
- Automatic backup of csf.conf before changes
- Minimum thresholds (50/80/100) prevent too-aggressive limits
- Option to apply or just view recommendations
- Full report saved to /tmp for review
INTELLIGENCE:
- Uses actual traffic data, not guesses
- Accounts for legitimate high-connection sources
- Prevents blocking search engines and monitoring
- Adapts to each server's unique traffic patterns
FILES MODIFIED:
- modules/security/optimize-ct-limit.sh (NEW - 650 lines)
- modules/security/live-attack-monitor.sh
- Added 'c' key handler (line 1019-1024)
- Updated Quick Actions recommendation (line 438)
- Updated help screen (line 1045)
- Updated footer keys (line 457)
PROBLEM: Live monitor detected attacks but didn't provide actionable
recommendations for firewall configuration (CT_LIMIT, SYNFLOOD, etc.)
BEFORE:
Quick Actions panel only showed:
- Number of IPs ready to block
- Press 'b' to block
No guidance on:
- What to do about SYN floods
- How to enable SYNFLOOD protection
- When to adjust CT_LIMIT
- How to strengthen SSH against bruteforce
AFTER:
Quick Actions now provides intelligent recommendations based on detected attacks:
1. DDoS/SYN Flood Detection:
⚠️ DDoS/SYN Flood Detected - Firewall Protection Recommended
→ Enable SYNFLOOD protection: csf -e SYNFLOOD
→ Set CT_LIMIT: Edit /etc/csf/csf.conf → CT_LIMIT="100"
→ Apply changes: csf -r
2. SSH Bruteforce Detection (>5 attempts):
⚠️ SSH Bruteforce (X attempts) - Strengthen SSH Security
→ Lower LF_SSHD trigger: Edit /etc/csf/csf.conf → LF_SSHD="3"
→ Enable PortKnocking or change SSH port
3. IP Blocking (score >= 60):
⚠️ X high-threat IPs ready to block
→ Press 'b' to open blocking menu
INTELLIGENCE:
- Monitors IP_DATA for DDOS attacks
- Counts HIGH_CONN_COUNT events (>20 SYN_RECV)
- Counts SSH_BRUTEFORCE attempts in feed
- Only shows recommendations when threats detected
- Provides exact commands to run
PANEL RENAMED:
"QUICK ACTIONS" → "QUICK ACTIONS & RECOMMENDATIONS"
USER BENEFIT:
- Know exactly what to do when SYN flood happens
- Get firewall config commands immediately
- Proactive security hardening suggestions
- No need to remember CSF syntax
NAVIGATION VERIFIED:
✅ All menu back buttons (0) return properly
✅ Cleanup trap handles Ctrl+C correctly
✅ Keyboard controls work (b, s, r, h, q)
✅ Blocking menu has cancel option
FILES MODIFIED:
- modules/security/live-attack-monitor.sh
- Enhanced draw_quick_actions() (lines 393-460)
- Added attack pattern detection
- Added firewall recommendation logic
- Panel title updated
- Changed from 'score >= 40' to 'score > 0 OR has attacks OR suspicious bot'
- Now shows ALL interesting traffic, not just high-scoring threats
- Added bot type display for suspicious/AI bots
- Users will see much more activity in the feed
This fixes the issue where legitimate attacks weren't showing because
they hadn't accumulated enough score yet.
Changes:
- Fixed incorrect scan result retrieval (was getting oldest scan instead of newest)
- Changed tail -1 to tail -n +2 | head -1 (skip header, get most recent scan)
- Fixed field number from 0 to 1 (TOTAL files scanned)
- Extract TOTAL_MALICIOUS from scan result directly (field 12)
- Added number validation to ImunifyAV, ClamAV, and Maldet parsers
- Now correctly reports realistic file counts (e.g., 3997 files in 69s, not millions)
Tested:
✓ ImunifyAV parsing verified with actual output
✓ Syntax check passed
Bug reference: BUG_014 in REFDB_FORMAT.txt
Added reference database building to enable fast user/domain selection:
1. Added to show_scan_menu() (lines 1447-1452):
- Builds reference database once when menu loads
- Caches all user and domain data for quick lookups
- Clears screen after building to show clean menu
- Only runs if build_reference_database function is available
2. User/Domain selection now uses cached data:
- select_user_interactive (line 1167) - uses cached user list
- Domain lookup (line 1195+) - can reference cached domain data
- Docroot matching (lines 1176-1180) - fast array lookups
Benefits:
- Fast user selection with pre-cached data
- Quick domain lookups without repeated parsing
- Efficient scanning when selecting specific users/domains
- No repeated file system queries for user information
- Consistent with other modules that use reference database
The reference database includes:
- All system users
- User domain mappings
- Docroot paths
- User metadata (disk usage, etc.)
Added safeguards for scanning entire filesystem from /:
1. Updated menu text (line 1127):
- Changed from "Entire server (all docroots)"
- To: "Entire server (scan from / - WARNING: may take several hours)"
- Provides immediate visibility of scan duration
2. Added confirmation prompt (lines 1142-1157):
- Shows yellow WARNING message
- Lists what will be scanned (user dirs, system files, app files)
- Warns about duration and resource usage
- Requires explicit "yes" to proceed
- Allows cancellation without starting scan
Benefits:
- Prevents accidental full server scans
- Sets proper expectations for scan duration
- User can choose to scan specific paths instead
- No surprise multi-hour scans
Three critical fixes to improve malware scanner usability:
1. Entire Server Scan Scope (line 1132):
- Changed from scanning only cPanel docroots to scanning entire filesystem
- scan_paths=("/") instead of scan_paths=("${sanitized_docroot[@]}")
- Updated display message: "Scan scope: Entire server from /"
- Fixes issue where "Entire server" option only scanned user directories
2. Screen Session Persistence (line 917):
- Added 'exec bash' at end of scan script to keep screen session alive
- User now has time to review summary and answer cleanup prompt
- Screen won't auto-close when script finishes
- Provides option to open interactive shell or detach (Ctrl+A then D)
- Fixes premature session termination issue
3. Selective Cleanup (lines 883-899):
- Changed cleanup to only delete scan.sh script
- Logs and results are always preserved at /opt/malware-*/
- New prompt: "Delete scan script? (Logs and results will be preserved)"
- Only removes scan.sh when user answers "yes"
- User can manually delete entire directory if needed: rm -rf $SCAN_DIR
- Moved RKHunter cleanup before user prompt (lines 870-880)
Benefits:
- Full server scanning actually scans from / root
- User can review results before screen closes
- Scan scripts are cleaned up for security
- Logs/results preserved for later review
- No accidental data loss
Added comprehensive summary table showing what each scanner found,
making it easy to see all results at a glance.
New Summary Section:
- Consolidated results table for all scanners
- Shows counts: threats, infected files, warnings
- Formatted table with aligned columns
- Scanner-specific result types
- Log file locations for detailed review
Example Output:
SCANNER RESULTS SUMMARY:
----------------------------------------
ImunifyAV: 2 threats detected
ClamAV: 0 infected files
Maldet: Scan complete (check logs)
Rootkit Hunter: 3 warnings
----------------------------------------
Improvements:
- Quick overview without reading all logs
- Clear indication if threats found
- Easy comparison across scanners
- Shows which scanners ran
- Provides log paths for deeper investigation
Clean presentation with:
- ✓ checkmark for clean scans
- ⚠️ warning icon for infected files
- Action-oriented messaging
- Helpful next steps
Changed ImunifyAV from asynchronous queue mode to synchronous scan mode
to ensure scanners run sequentially and each completes before the next starts.
Problem:
- Used "malware on-demand queue put" which queues asynchronously
- Scanner immediately moved to next scanner without waiting
- Broke sequential scanning requirement
- Output showed "scans queued" but scan was still running
Solution:
- Changed to "malware on-demand start --path" (synchronous)
- Blocks until scan completes
- Shows progress: "→ Scanning: /path"
- Extracts infected count from malicious list
- Now properly sequential: ImunifyAV → ClamAV → Maldet → RKHunter
Result:
- All 4 scanners now run completely sequentially
- Each scanner waits for previous to finish
- Proper "scan complete" reporting for ImunifyAV
- Infected file counts tracked correctly
Ensures scan integrity and proper resource management.
Changed rkhunter from permanent installation to temporary session-based use,
aligning with toolkit's "Download, Run, Fix, Delete" philosophy.
Behavior:
- Standalone scanner checks if rkhunter is installed
- If NOT found: Auto-installs temporarily with EPEL
- Updates definitions and initializes baseline
- Runs the scan
- Auto-removes rkhunter at end of scan session
- Tracks installation with RKHUNTER_TEMP_INSTALLED flag
Benefits:
- No permanent footprint on server
- Automatic cleanup after use
- Still available in "Install All Scanners" for users who want it permanent
- Standalone scans are truly self-contained and temporary
Implementation:
- Added RKHUNTER_TEMP_INSTALLED tracking variable
- Auto-install logic before scanner detection
- Silent installation (yum &>/dev/null)
- Auto-removal after scan completes
- Logged in session.log for transparency
RKHunter is system-level (checks binaries/kernel) not file-level,
so it doesn't need to persist - perfect candidate for temp install.
Integrated rkhunter for comprehensive rootkit/backdoor/exploit detection
alongside existing ImunifyAV, ClamAV, and Maldet scanners.
Features:
- Detection: is_rkhunter_installed() checks for installation
- Installation: Auto-enables EPEL, installs rkhunter, updates definitions
- Baseline: Initializes property database with --propupd
- Scanning: Uses --check --skip-keypress --report-warnings-only
- Reporting: Tracks warnings and detected rootkits
- Documentation: Added to installation guide with full instructions
Integration points:
- detect_scanners(): Added rkhunter to available scanners list
- show_scanner_installation_guide(): Added installation instructions
- install_all_scanners(): Added [4/4] installation with EPEL setup
- Standalone scanner: Added rkhunter detection and scan case
Scan behavior:
- Updates rootkit definitions before each scan
- Runs comprehensive system checks (no user interaction)
- Reports warnings count in summary
- Extracts found rootkits to infected_list
- Runs sequentially with other scanners
Research: Based on 2024-2025 best practices from rkhunter documentation
- Version: 1.4.6 (current stable)
- Free and open source
- Available in EPEL repository
The docroot extraction from /etc/userdatadomains was completely broken,
causing scans to target invalid paths like "main" instead of actual
document roots like /home/user/public_html.
Problem:
- Used `cut -d= -f5` which treats EVERY = as delimiter
- File format uses == as delimiter: user==owner==main==domain==docroot==...
- This caused field 5 to be "main" instead of the docroot path
- Result: Scanners scanned zero files and completed in seconds
Solution:
- Use `awk -F'==' '{print $5}'` to properly parse == delimited fields
- Extract field after colon, then split by ==
- Added -d check to ensure docroot exists before adding
- Fixed both detect_control_panel() and get_user_docroots()
Impact:
- Malware scans now actually scan real document roots
- Full server scans will take appropriate time (not 10 seconds!)
- Users will see actual file counts and scan progress
- Added missing source for reference-db.sh library in malware-scanner.sh:15
- Created store_reference() and get_reference() functions in reference-db.sh
- Functions use REF|key|value format in .sysref database
- Fixes "store_reference: command not found" errors at lines 816-817
Changes:
- Show 'please wait' message for long installation
- Display installation progress from deployment script
- Clean up any existing deployment script first
- Show relevant output: Installing/Installed/Complete/Error
- Remove suppression of all output
This should make ImunifyAV installation more visible and debuggable.
Scanner Detection Improvements:
- Created dedicated detection functions for each scanner
- is_imunify_installed(): Checks command and /usr/bin location
- is_clamav_installed(): Checks command, cPanel path, and RPM
- is_maldet_installed(): Checks command and /usr/local/sbin
ClamAV Fixes:
- Now detects cPanel-installed ClamAV correctly
- Checks for cpanel-clamav RPM package
- Finds clamscan in /usr/local/cpanel/3rdparty/bin/
- Handles already-installed cPanel ClamAV gracefully
- Dynamically finds freshclam binary for updates
ImunifyAV Improvements:
- Better installation detection
- Finds binary dynamically for updates
- Handles various installation paths
Benefits:
- Scanners installed via cPanel are now detected
- No false "not installed" errors
- Better handling of non-standard install paths
- More robust binary finding for updates
User feedback addressed: Detection was failing for cPanel-installed
scanners that weren't in standard PATH locations.
Enhancements:
- All scanners now update signatures immediately after installation
- Signature updates are visible with progress messages
- Show relevant output from update commands
- Graceful fallback if update output parsing fails
Updates per scanner:
1. ClamAV:
- freshclam runs immediately post-install
- Shows "updated", "Downloaded", or "up-to-date" messages
- Confirms with green checkmark
2. Maldet:
- maldet -u runs immediately post-install
- Shows "update completed" or signature count
- Confirms with green checkmark
3. ImunifyAV:
- imunify-antivirus update runs immediately post-install
- Shows "updated", "Success", or "completed" messages
- Confirms with green checkmark
User feedback addressed: Signatures should update automatically
right after installation, not silently in background.
Architecture Changes:
- ALL scans now use standalone scanner (/opt deployment)
- Toolkit serves as monitor/manager, not executor
- Removed direct scanning from toolkit entirely
New Features:
- Bulk scanner installation (install all 3 at once)
- Scan status checker with live progress
- Session manager (delete individual or all completed scans)
- Enhanced menu structure with clear separation
Menu Organization:
1. Create New Scan (server/user/domain/custom) → generates standalone
2. Monitor & Manage (status/results/delete)
3. Configuration (install all/settings)
Removed Functions:
- scan_entire_server() - now via standalone
- scan_user_account() - now via standalone
- scan_domain() - now via standalone
- scan_custom_path() - now via standalone
- run_all_scanners() - embedded in standalone
- scan_imunify/clamav/maldet() - embedded in standalone
Benefits:
- Cleaner separation of concerns
- Consistent scan execution (all via standalone)
- Better resource management
- Toolkit can be deleted during scan
- Centralized scan monitoring
Enhancements:
- Auto-install screen when not available (yum/apt-get support)
- Nohup fallback option if user prefers no screen installation
- Enhanced view_scan_results to show standalone scanner sessions
- Display session status (running/completed) for standalone scans
- Show summary, infected files, and logs for each session
- Track PIDs for nohup-launched scans
Screen handling:
- Option 1: Auto-install screen (recommended)
- Option 2: Use nohup fallback (no dependencies)
- Option 3: Cancel operation
Results viewer improvements:
- Separate toolkit and standalone scan results
- List all /opt/malware-* sessions with status
- Show summary, infected files, and recent logs
- Provide commands to monitor ongoing scans
This ensures the standalone scanner works even on minimal
systems without screen pre-installed.
Features:
- Standalone scanner generator that runs independently in /opt
- Launch in screen session for background execution
- Self-contained script with no toolkit dependencies
- Self-cleanup with user confirmation after completion
- Scanner installation guide for ImunifyAV, ClamAV, and Maldet
- Menu option 5: Launch standalone scanner
- Complete scan scope selection (server/user/domain/custom path)
Implementation:
- Added show_scanner_installation_guide() function
- Added launch_standalone_scanner_menu() function
- Enhanced generate_standalone_scanner() with screen integration
- Integrated with main malware scanner menu
Use case: Long-running scans can be launched independently,
allowing toolkit deletion while scans continue in background.
New Features:
- 'All Available Scanners' option in all scan modes (server/user/domain/custom)
- Runs ImunifyAV, ClamAV, and Maldet sequentially with progress tracking
- Creates consolidated multi-scanner session reports
- Shows [1/3], [2/3], [3/3] progress indicators
- 3-second wait between scanners to prevent system overload
- Session reports saved to logs/malware-scans/multiscan_*.txt
- Stores session IDs in reference database for cross-module access
- New 'Compare scanner results' option (menu option 6)
- View consolidated reports from multiple scanners
Workflow:
1. Select any scan scope (server/user/domain/path)
2. Choose 'All Available Scanners' option
3. All installed scanners run automatically one after another
4. Single consolidated report with all results
5. Use option 6 to compare/view latest multi-scanner session
Much more automated - no need to run each scanner separately!
The bot analyzer was silently processing thousands of log files with no progress feedback, appearing to stall on large servers.
Changes:
• Added progress counter showing every 50 log files parsed
• Displays current domain being processed
• Shows format: "Parsed 150 log files... (current: domain.com)"
• Clears progress line when complete to avoid clutter
• Interval set to 50 files (adjustable via progress_interval variable)
Example output:
Parsing logs from: /var/log/apache2/domlogs
Parsed 50 log files... (current: example.com)
Parsed 100 log files... (current: another.com)
Logs parsed successfully (125432 entries)
This gives real-time feedback on servers with 1000+ log files without overwhelming the output.
The domain lookup was failing because it only searched for 'servername:' in /var/cpanel/userdata/*/main files, but cPanel stores domain information differently:
- main files use 'main_domain: domain.com' (YAML format)
- domain-specific files use 'servername: domain.com' (YAML format)
Changes:
• Added two-step domain lookup process
• Method 1: Check main_domain in /var/cpanel/userdata/*/main files
• Method 2: Fallback to search all domain files for servername
• Skip cache files (.cache, cache, cache.json) during search
• Applied fix to all three domain lookup locations (options 2, 5, 6)
This fixes the "WordPress installation not found for domain" error that occurred when domains weren't configured as main_domain.
Tested with pickledperil.com - lookup now works correctly.
Changes:
- Modified disable_wpcron_in_config() to place DISABLE_WP_CRON before "stop editing" comment
- This follows WordPress convention for custom constants
- Removes any existing DISABLE_WP_CRON lines first (clean placement)
- Falls back to after <?php if "stop editing" not found
Placement Logic:
1. Remove any existing DISABLE_WP_CRON (anywhere in file)
2. Add before "/* That's all, stop editing! */" comment (line ~93)
3. Fallback: Add after <?php if no "stop editing" found
Example Placement:
```
if ( ! defined( 'WP_DEBUG' ) ) {
define( 'WP_DEBUG', false );
}
define('DISABLE_WP_CRON', true); ← Added here
/* That's all, stop editing! Happy publishing. */
```
Benefits:
- Follows WordPress conventions
- Placed with other custom constants
- Clean, predictable location
- Easy to find for manual edits
https://claude.com/claude-code
Changes:
- Added "0) Cancel" option to all menu prompts
- Added "(or 0 to cancel)" to all text input prompts
- Ensures users can back out of any operation at any time
- Scripts affected:
- website-error-analyzer.sh (scope selection, time range)
- 500-error-tracker.sh (time range selection)
- wordpress-cron-manager.sh (all domain/user input prompts, status checks)
User Experience Improvements:
- No more being trapped in prompts
- Clear cancel instructions on every input
- Consistent "Operation cancelled" messaging
- Proper exit codes (0 for user cancellation)
Tested:
✓ website-error-analyzer.sh - cancel on scope selection
✓ 500-error-tracker.sh - cancel on time selection
✓ wordpress-cron-manager.sh - cancel on domain/user input
✓ All cancellations return cleanly to menu
https://claude.com/claude-code
Changes:
- Created modules/website/wordpress/ subdirectory for CMS-specific tools
- Moved wordpress-cron-manager.sh to new subdirectory
- Created wordpress-menu.sh submenu for WordPress tools
- Updated launcher.sh Website Management menu:
- Simplified to show general tools and CMS submenu options
- WordPress Management is now a submenu (option 3)
- Prepared structure for Joomla/Drupal/other CMS support
- Fixed script paths in wordpress-cron-manager.sh for new location
- Tested complete navigation: Main → Website → WordPress → Cron Manager
Menu Structure Now:
Website Management
├── Website Error Analyzer
├── 500 Error Tracker
└── WordPress Management (submenu)
└── WordPress Cron Manager
└── (All cron management options working)
https://claude.com/claude-code
New Revert Options:
- Option 6: Re-enable wp-cron for specific domain
- Option 7: Re-enable wp-cron for specific user (all sites)
- Option 8: Re-enable wp-cron server-wide (all sites)
Revert Function Features:
✅ Safely removes DISABLE_WP_CRON from wp-config.php
✅ Automatic backup before changes
✅ Verification of successful removal
✅ Auto-rollback on failure
✅ Removes cron jobs from user crontabs
✅ Batch processing for multiple sites
✅ Summary reporting
Menu Organization:
- Grouped options by function (Enable/Revert/Status)
- Color-coded sections (Green/Yellow/Cyan)
- Clear labeling of what each option does
Revert Process:
1. Backup wp-config.php
2. Remove DISABLE_WP_CRON line completely
3. Verify removal was successful
4. Remove wp-cron.php entries from user crontab
5. Provide feedback and summary
Safety Features:
- Won't break sites if DISABLE_WP_CRON not found
- Preserves other cron jobs when removing wp-cron entries
- Individual site failures don't stop batch operations
- Clear feedback on what was changed
Critical Safety Improvements:
- Prevent duplicate DISABLE_WP_CRON entries
- Detect and modify existing definitions (commented or not)
- Automatic rollback on failure
- Verification of changes before committing
Safety Function Features:
✅ Checks file exists and is writable before modification
✅ Detects existing DISABLE_WP_CRON (even if set to false)
✅ Modifies existing line instead of adding duplicate
✅ Ignores commented lines when detecting existing definitions
✅ Creates temporary backup (.wpbak) during modification
✅ Verifies change was successful after modification
✅ Automatically restores backup if verification fails
✅ Removes temporary backup only on success
Prevents Issues:
❌ No duplicate define() statements
❌ No syntax errors from malformed sed commands
❌ No broken wp-config.php files
❌ No accumulation of multiple entries on repeated runs
Error Handling:
- Returns 0 on success, 1 on failure
- Calling code can gracefully handle failures
- User feedback when modification fails
- Skips sites that fail instead of breaking entire batch
Features:
- Scan for all WordPress installations on server
- Disable wp-cron for specific domain, user, or server-wide
- Check wp-cron status for any domain or user
- Automatic wp-config.php backups before changes
- Intelligent cron job staggering to prevent load spikes
Load Distribution:
- Staggers cron times across 15-minute windows
- Example with 300 sites: distributes across minutes 0-14
- Site 1: runs at 0,15,30,45
- Site 2: runs at 1,16,31,46
- Site 3: runs at 2,17,32,47
- ...continues up to minute 14, then wraps
- Prevents all sites from running simultaneously
- Uses user crontabs (not system cron) for proper permissions
Technical Details:
- Adds DISABLE_WP_CRON to wp-config.php
- Creates user-specific crontab entries
- Prevents duplicate cron jobs
- Shows cron timing when adding jobs
- Handles multiple WP installations per user
- Add detection for when no CLI-managed plans exist
- Clarify that cloud-managed plans (web console) aren't visible via acrocmd
- Explain distinction between CLI-managed vs cloud-managed plans
- Provide guidance for both web console and CLI plan management
- Note that API credentials would be needed for cloud plan access
Simplified flow:
1. Shows available plans from acrocmd
2. Prompts user to enter plan name/ID directly
3. Press Enter to cancel and see web console instructions
4. Then proceeds to backup type and performance selection
Removed:
- Confusing numbered options (1,2,3)
- "Run all plans" option (too dangerous)
- Redundant web console option
Now more intuitive - users just type the plan name they see.
Enhanced backup trigger script with:
Backup Type Selection:
- Auto (use plan's default)
- Full backup (--backuptype=full)
- Incremental (--backuptype=incremental) - faster, changes only
- Differential (--backuptype=differential) - changes since last full
Performance Optimizations:
- Lower compression (--compression=normal) - faster, larger size
- High priority (--priority=high) - use more resources
- Both combined
Users can now choose backup type and optimization level per backup,
allowing CLI operations to be faster than web console when needed.
Improved "Cloud Connectivity Test" section:
- Now shows as dedicated section with bold header
- Displays full URL being tested (https://us5-cloud.acronis.com)
- Shows HTTP status code on success (e.g., "✓ Reachable (HTTP 200)")
- Provides troubleshooting steps on failure:
• Check internet connectivity
• Verify firewall allows HTTPS (port 443)
• Manual test command provided
This makes it easy to verify the agent can reach Acronis cloud
and diagnose connectivity issues.
Removed interactive Quick Actions (start/stop/restart/logs/version)
from agent status screen. These were redundant with existing menu
options and cluttered the status display.
Status screen now shows info and returns to menu immediately.
Log analysis will be handled in the troubleshoot script instead,
which will comprehensively check all Acronis logs for issues.
Cannot reliably determine total cloud storage quota via CLI.
Removed hardcoded 50GB assumption since plans vary.
Now shows:
- Available: 30.96 GB (accurate from acrocmd)
- Used: (Check web console for accurate usage)
This is the safest approach since:
- Total quota not exposed via acrocmd or config files
- acrocmd list licenses fails for cloud-managed agents
- Web console always has accurate real-time usage data
When acrocmd shows "Occupied: 0 GB" (agent sync issue), calculate
actual usage by subtracting available from 50GB total quota.
Now displays:
Used: ~19.04 GB (50GB - 30.96GB available)
This shows the real 19GB usage that appears in web console by
reverse-calculating from remaining quota (30.96 GB).
Added "Cloud Backup Storage" section showing:
- Vault name
- Used storage (occupied)
- Available storage (free quota)
Uses 'acrocmd list vaults' to query actual cloud storage usage
that was previously only visible in web console.
This will show the 19GB backup storage usage the user was asking about.
Changed "Storage Status" to "Local Storage Status" to clearly indicate
this shows agent data (130M cache/logs/config), not backup storage.
Added note directing users to Acronis web console for actual backup
storage usage (19GB cloud storage shown there).
Prevents confusion between:
- Local agent data: 130M (what script shows)
- Cloud backup storage: 19GB (shown in web interface)
Fixed Issues:
- Registration check now uses correct config file (user.config)
- Parses actual registration XML to verify cloud connection
- Shows registration URL and environment
Port Monitoring:
- Now detects actual Acronis listening ports via netstat
- Shows real local ports (9850 for MMS, dynamic ports for aakore)
- Identifies which service owns each port
- Tests actual cloud connectivity with timeout
Changes:
- Registration verified from /var/lib/Acronis/.../user.config
- Port 9850 (localhost): MMS management service
- Dynamic ports: aakore agent core
- Added cloud connectivity test to registration URL
Fixed error where 'local' keyword was used outside of a function in
the storage status section. Changed to regular variable declarations
and added null check for use_percent to prevent integer expression errors.
Completely rewrote acronis-update.sh to actually perform upgrades:
Features:
- Checks current version before upgrade
- Shows service status
- Two upgrade methods:
1. Automatic (web console instructions)
2. Manual (downloads and runs upgrade)
Manual Upgrade Process:
- Detects existing installation automatically
- Extracts cloud URL from /etc/Acronis/Global.config
- Downloads latest installer from correct region
- Runs installer in unattended mode (-a flag)
- Installer automatically upgrades over existing installation
- Preserves configuration and registration
- Shows version before/after upgrade
- Verifies services running after upgrade
- Offers to restart services if needed
- Cleans up download files
What Gets Preserved During Upgrade:
✓ Agent registration (stays connected to account)
✓ Backup plan configurations
✓ Connection settings
✓ Service configurations
Based on Acronis documentation research:
- Running installer over existing installation = automatic upgrade
- No uninstall needed
- No re-registration needed
Better approach per user suggestion:
- Downloads to: /root/server-toolkit/downloads/acronis-install-YYYYMMDD-HHMMSS/
- Keeps toolkit directory organized
- Avoids polluting /root
- Avoids /tmp noexec issues
- Added downloads/ to .gitignore
- Cleanup removes timestamped installation directory after completion
Benefits:
- All downloads in one place
- Easy to find if debugging needed
- Cleaner than scattered in /root
- Still allows execution (not in /tmp)
Root cause: /tmp is mounted with noexec flag preventing execution.
Changed TEMP_DIR from /tmp/acronis-install to /root/acronis-install
This allows the installer binary to execute properly.
Verified: mount shows /tmp with noexec option
Solution: Use /root which allows execution
cschantz