This routine provides a structured method for detecting configuration drift on a DirectAdmin-managed VPS. It focuses on identifying unintended or gradual changes to system, service, or DirectAdmin configuration that can introduce instability over time.
Scope and intent
- Detect unintended configuration changes
- Identify divergence from known-good baselines
- Support proactive maintenance before failures occur
- Reduce risk caused by silent or incremental drift
When to run this routine
- After updates or repeated maintenance activity
- When behavior changes without an obvious cause
- After incident recovery or emergency fixes
- As part of periodic operational review
Prerequisites
- Root or administrative shell access
- Awareness of expected baseline configuration for this VPS
- Access to DirectAdmin
1. Establish the comparison baseline
- Identify the last known stable state of the server
- Reference documentation, notes, or prior verification results
- Confirm which components are expected to be unchanged
2. Review DirectAdmin configuration changes
- Check for changes in DirectAdmin settings or templates
- Review user, domain, and service-level configuration
- Confirm defaults have not been unintentionally overridden
3. Review service configuration files
- Inspect web server, mail, and database configuration files
- Look for manual edits, timestamp changes, or unexpected values
- Confirm configuration aligns with expected service behavior
4. Check system-level configuration
- Review firewall rules, cron jobs, and scheduled tasks
- Confirm system limits, paths, and permissions are unchanged
- Look for configuration artifacts left behind by troubleshooting
5. Correlate with logs and system behavior
- Compare configuration findings with recent log entries
- Confirm drift aligns with warnings, errors, or subtle anomalies
- Avoid attributing normal variance to drift without evidence
6. Classify detected drift
- Intentional: known, documented changes
- Benign: differences with no operational impact
- Risky: undocumented or harmful deviations requiring correction
7. Decide on remediation approach
- Document intentional changes to establish a new baseline
- Revert risky drift using known-good configuration
- Plan corrective action rather than making ad-hoc changes
8. Record findings
- Document what drift was detected and where
- Record remediation steps or decisions taken
- Update baseline references if appropriate
Completion criteria
- Configuration drift has been identified or ruled out
- All risky deviations are documented or addressed
- A clear baseline state is re-established
Next step — based on your current state:
- If drift caused instability, proceed to Incident Recovery Sanity Check.
- If drift followed recent updates, consider After Server Update Verification Checklist.
- If configuration appears stable, return to normal operations or your maintenance cadence.