Kaburu Wiki

# kaburusvr

Primary managed hosting server. All client sites, tools, and services run here.

## Specs

## Access

- SSH: `ssh [email protected]` or via Hetzner MCP tools - CyberPanel: https://kaburusvr.uk:8090 - MainWP: https://kaburusvr.uk/wp-admin

## Key paths

## Key services

- cyberpanel — hosting control panel - litespeed — web server - mainwp — WordPress network management - matomo — analytics - fusion-invoice — billing

## Firewall (UFW — added 2026-08-05)

UFW active, default deny incoming. Only public services exposed; all admin/management ports restricted to Tailscale (100.64.0.0/10).

Notes: - Rules live in `/etc/ufw/user.rules`; DOCKER-USER rule for :3001 in `/etc/ufw/after.rules` (Docker bypasses INPUT via FORWARD — ufw route rules don't cover published ports). - Do NOT install `iptables-persistent` on this box — it conflicts with ufw and *removes* it (happened 2026-08-05). UFW persists its own rules. - Access CyberPanel/LiteSpeed admin via Tailscale (box is 100.112.54.2), not the public IP. - SSH is Tailscale-only** (100.64.0.0/10). All automation (MCP `hetzner_shell`, cron scripts, backups) already uses `[email protected]` — zero impact. Hetzner rescue is unaffected: the rescue system is a separate OS without these UFW rules, and the web console (KVM) is out-of-band at the hypervisor level. If Tailscale itself is down, use the Hetzner web console to fix it. - DOCKER-USER chain (Uptime Kuma :3001 Tailscale-only): Added systemd service `/etc/systemd/system/ufw-docker-3001.service` (enabled) that runs after Docker and inserts iptables rule. UFW after.rules no longer contains the rule (was causing boot failure — `iptables-restore: line 34 failed` because DOCKER-USER chain doesn't exist at UFW boot time). Added 2026-08-11. - SSH, SMTP (25), and DNS (53) are reachable on the public IP — verified via hairpin test 2026-08-05. LAN-side tests from Z840 for 25/53 fail because OPNsense filters outbound probing, not the server.

## Database

MariaDB 10.11. Root access via mysql CLI. max_allowed_packet = 64MB (set 2026-05-11)

## Known quirks

- Server connects to Cloudflare API over IPv6 (2a01:4f8:1c18:91ab::1) — CF tokens must allow this IP - CyberPanel CLI creates vhosts with wrong PHP path (lsphpPHP83) — always verify after creating sites - New sites created via CLI are not registered in CyberPanel DB — must INSERT manually or use CyberPanel UI - New sites need .user.ini created in public_html with open_basedir setting - public_html must be chmod 755 for LiteSpeed to serve files

## CyberPanel site registration (manual fix)

If a site shows 404/403 after CLI creation: ```sql INSERT INTO cyberpanel.websiteFunctions_websites (domain, adminEmail, phpSelection, ssl, state, externalApp, config, BackupLock, admin_id, package_id) VALUES ('domain.com', 'email', 'PHP 8.3', 1, 1, 'linuxuser', '', 0, 1, 1); ```

## Freenet node

- URL: https://freenet.kaburu.co (Cloudflare proxied → 49.13.202.144) - Binary: `/opt/freenet/freenet` - Service: `freenet.service` (systemd, active) - Listens on: `localhost:7509` - OLS vhost: `/usr/local/lsws/conf/vhosts/freenet.kaburu.co/vhost.conf` — proxy `/*` → `localhost:7509` - SSL: LE cert via acme.sh (DNS-01, Cloudflare API), certs at `/usr/local/lsws/conf/ssl/freenet.kaburu.co/` - acme.sh cert dir: `/root/.acme.sh/freenet.kaburu.co_ecc/` - Vhost docroot: `/home/freenet.kaburu.co/public_html/` (minimal, just for OLS) - Vhost registered in httpd_config.conf as `virtualHost freenet.kaburu.co` - Listener maps: `freenet.kaburu.co` in both SSL (port 443) and HTTP (port 80) listeners - Note: NOT a CyberPanel-managed domain — manual vhost config. No vhconf.xml, no CyberPanel DB entry.

## Swap

- File: `/cyberpanel.swap` - Size: 4GB (increased from 2GB on 2026-05-27 — was sitting at 60% used, Hermes flagging low swap) - Type: swapfile, priority -2 - fstab: already configured, no changes needed