# Site Provisioning Checklist — kaburu.uk Carnage (2026-08-08)
Date: 2026-08-08 Site: kaburu.uk Reporter: Steve (user) — “site is in as bad condition as the site I just left” Model note: An earlier KAT/agent report claimed “no database exists” — that was WRONG. The physical DB existed all along with 54 tables; the real issue was CyberPanel's tracking registry. Always check `information_schema.tables` before claiming a DB is missing.
## Issues Found (corrected after live verification)
### 1. Database not registered in CyberPanel — CRITICAL 🔴 (NOT missing!) - Symptom: CyberPanel UI showed “0 of 5 databases used”; wp-config referenced `kabur3698_wp` - Actual root cause: The database `kabur3698_wp` existed (54 tables: Wordfence, Rank Math, Complianz, MainWP, etc.) and user `kabur3698_usr` had `ALL PRIVILEGES ON kabur3698_wp.*` — but there was no row in `cyberpanel.databases_databases` linking it to the website (id 41). CyberPanel's UI counts registered DBs, not actual ones. - Evidence:
```sql -- physical DB exists: SELECT COUNT(*) FROM information_schema.tables WHERE table_schema='kabur3698_wp'; -- 54 SHOW GRANTS FOR 'kabur3698_usr'@'localhost'; -- ALL PRIVILEGES on kabur3698_wp.* -- CyberPanel registry missing: SELECT * FROM databases_databases WHERE dbName='kabur3698_wp'; -- empty ```
- Fix (applied):
```sql
INSERT INTO databases_databases (dbName, dbUser, website_id) VALUES ('kabur3698_wp', 'kabur3698_usr', 41);
INSERT INTO databases_databasesusers (username, owner_id) VALUES ('kabur3698_usr', 25);
-- NOTE: owner_id is a FK to databases_databases.id (25), NOT website_id (41)
```
Panel now shows **1 of 5 databases**. Site was never actually down — wp-config connected fine throughout.
### 2. SSL — FALSE ALARM ✅ (no change needed) - Symptom: Panel seemed to show no SSL assigned - Verified: DB `websiteFunctions_websites` shows `ssl=1` for kaburu.uk (id 41); cert valid Aug 7 → Nov 5 2026 at `/etc/letsencrypt/live/kaburu.uk/`; vhost `vhssl` block points correctly; HTTPS serves HTTP/2 200 with valid cert (openssl verify clean). Nothing to fix.
### 3. PHP limits — REAL, fixed via vhost.conf (NOT .user.ini!) 🟡 - Symptom: CyberPanel health check: “cURL Timeout >=300s → 60 Warning”, “WordPress Memory Limit >=64M → 40M Warning” - Root cause — two distinct bugs:
1. **LiteSpeed does NOT apply `.user.ini` for these directives** (PHP CLI mode ignores per-dir ini). The vhost.conf `php_value` directives are the source of truth. kaburu.uk's vhost.conf had only `php_admin_value open_basedir`, so PHP fell back to compiled defaults: `memory_limit=256M`, `max_execution_time=30`, `default_socket_timeout=60`. Compare jafricasafari.com which has explicit `php_value` lines.
2. `curl.timeout` is **not a real PHP directive** — `ini_get('curl.timeout')` returns empty on every site, including jafricasafari.com (its .user.ini says "; Increase cURL Timeout" with nothing after it). The actual control is `default_socket_timeout`. The panel's "cURL Timeout" check is checking a setting that doesn't exist in PHP's ini.
- Fix (applied):
```ini
# /usr/local/lsws/conf/vhosts/kaburu.uk/vhost.conf — inside phpIniOverride block:
php_value memory_limit 1024M
php_value max_execution_time 1500
php_value max_input_time 1500
php_value default_socket_timeout 300
php_value upload_max_filesize 1024M
php_value post_max_size 1024M
```
Plus in wp-config.php (fixes the WP "40M" reading — WP's own constant, not ini):
```php
define('WP_MEMORY_LIMIT', '1024M');
define('WP_MAX_MEMORY_LIMIT', '1024M');
```
Verified via PHP probe served through LiteSpeed: `MEM=1024M, SOCK=300, EXEC=1500, UPLOAD=1024M`. Also removed the bogus `curl.timeout = 300` line from .user.ini (non-functional).
- Note: The panel warning may persist in the UI until it re-reads; actual runtime values are verified correct.
### 4. File Ownership — CLEAN ✅ - Zero root-owned files, zero nobody-owned files. All `kabur3698:kabur3698`. False alarm.
## Provisioning Root Cause
Site was created via CyberPanel/CyberPanel CLI path (2026-08-07) but the CyberPanel DB registry was never populated — the DB itself was created, WP was installed and working, but the `databases_databases` link row was missing. The PHP vhost also lacked the standard `php_value` limits block that other sites carry.
## Prevention Checklist (Future Sites)
When provisioning a new site via `kaburu-provision.sh`:
```bash # 1. Verify DB EXISTS AND is registered in CyberPanel (both!) mysql -u cyberpanel -pIz0FGDtvJ2jcfb -e “SHOW DATABASES LIKE 'kabur%';” mysql -u cyberpanel -pIz0FGDtvJ2jcfb cyberpanel -e “SELECT id, dbName, website_id FROM databases_databases WHERE website_id=(SELECT id FROM websiteFunctions_websites WHERE domain='<site>');”
# 2. Verify user grants mysql -u cyberpanel -pIz0FGDtvJ2jcfb -e “SHOW GRANTS FOR '<user>'@'localhost';”
# 3. Verify SSL registered mysql -u cyberpanel -pIz0FGDtvJ2jcfb cyberpanel -e “SELECT domain, ssl FROM websiteFunctions_websites WHERE domain='<site>';”
# 4. Verify PHP limits via vhost.conf php_value block (NOT .user.ini) grep 'php_value' /usr/local/lsws/conf/vhosts/<site>/vhost.conf
# 5. Verify file ownership find /home/<site>/public_html -user root -not -path '*/cache/*' | wc -l
# 6. Verify WP_MEMORY_LIMIT in wp-config.php grep WP_MEMORY_LIMIT /home/<site>/public_html/wp-config.php ```
## Related
- `references/litespeed-gotchas.md` — LiteSpeed/php.ini pitfalls - `references/litespeed-domain-aliasing.md` — SSL cert setup - wiki `infrastructure/wordpress-sites.md` — Site user mapping