do5

Host Facts

These details have been confirmed via SSH login and read-only inventory.

Hosted Sites

Known web roots and applications currently present under /var/www.

Deliberate services (stack and apps)

Components intentionally installed or configured for hosting — distinct from generic OS services like SSH.

Stock / inherent

Expected on a typical server image — listed so they are not confused with migration scope.

• OpenSSH (sshd): Admin access; not a migration deliverable.
• systemd / base OS: Init, journal, udev — standard.
• chronyd, rsyslog: Time and logs.
• DigitalOcean agent: Cloud-only; N/A on phoebe.

Databases

MariaDB is active on the host. These are the databases and app mappings confirmed so far.

Services & Exposure (legacy combined list)

Original catch-all list (mixed deliberate and generic). Prefer Deliberate services and the migration tracker for accuracy.

• Apache / httpd with vhosts under /etc/httpd/sites-available and /etc/httpd/sites-enabled
• MariaDB 10.4.12
• Samba (smbd + nmbd) with a do5-www share exposing /var/www to the smbgrp group
• SSH on port 22

Risks & Legacy Signals

These are the reasons `do5` should be treated as a careful migration, not just a quick rsync target.

• CentOS 7 is legacy and should be treated as migration-priority infrastructure.
• MySQL appears to be listening on :::3306, so confirm whether it is intentionally internet-exposed.
• Samba ports 139/445 are open; confirm intended exposure and whether firewalling is still correct.
• Default /var/www/html contains adminer-4.7.5.php, pma.php, mariadb.php, info.php, and mail helper files.
• Multiple older human users remain on the host, including e3-juno and e3-circe.

Migration Readiness

The duplication target is `phoebe.lan`, but the inventory should support a cleaner rebuild than the current host shape. The next work items are:

1. Capture a fuller Apache inventory: enabled/disabled vhosts, rewrite rules, aliases, SSL cert paths, and any hidden include files.
2. Inspect each app root for code provenance, deployment method, and writable directories.
3. Deepen the MariaDB inventory: users, grants if readable, database sizes, dump/backup presence, and likely restore order.
4. Identify files and directories that must move to phoebe.lan separately from code, especially uploads, media, and custom runtime state.
5. Use du1 as the preferred jumpbox for remote-to-remote transfer work once extraction and restore steps are ready.
6. Design the replacement target as a cleaner, segmented service layout on phoebe.lan rather than blindly cloning every exposed surface.

Working strategy: use `du1` as the preferred jumpbox for any remote-to-remote extraction or transfer step once the source data, target layout, and cutover order are understood.

Operational notes from the deeper survey:

• No obvious SQL dumps or tarball backups were found in the first shallow scan of /var/www, /home/jd, /opt, or /root.
• do5.speakez.chat includes composer.json and a README describing a Ratchet/WebRTC chat stack that expects a websocket server to be started separately.
• The read-only check from do5 did not confirm key-based SSH access onward to du1, but from the local environment du1 SSH key access is confirmed.
• Git metadata exists in the Cardora and Speakez web roots, but the quick scan did not expose configured remotes or obvious branch metadata.
• Speakez includes multiple service-install notes for Ratchet, but no active user crontab or obvious running websocket process was seen during the latest read-only check.

Runtime & SSL Findings

These findings matter because a working duplicate on phoebe.lan will need compatible runtimes or a deliberate upgrade path.

• PHP CLI is 7.4.4 from Remi packages; the host also has several php74-* packages installed.
• Apache package is httpd-2.4.43 with mod_ssl installed.
• Certbot 1.3.0 is installed and SSL vhost files exist for do5.cardora.co, do5.speakez.chat, and do5-sgvm.storage.cardora.co.
• The localhost vhost still points at /var/www/html, where legacy admin and helper files remain present.
• The main Cardora codebase shows standard WordPress entrypoints and rewrite rules rather than CakePHP structure or CakePHP router fingerprints.

Writable Content to Preserve

The biggest migration risk is not just the code. It is the mutable content, uploads, and runtime state that sit beside it.

Database Detail

These are the concrete MariaDB signals captured so far using the recovered do5 database root credential.

Observed MariaDB users:

• card_admin@localhost
• wp1@localhost
• root@localhost
• mysql@localhost
• testuser@localhost

Cardora & WordPress Findings

The old Cardora site matters historically, but it does not appear to be a mysterious framework migration problem: it looks like a custom WordPress build rather than CakePHP.

• Cardora WordPress core version is 5.2.1.
• Active Cardora theme: cardora (template and stylesheet both set to cardora).
• Confirmed active Cardora plugins include Advanced Custom Fields, Classic Editor, speakez-audio-recorder-cardora, speakez-video-recorder-cardora, and tektonic-file-upload.
• Legacy wp1 is much lighter: active theme is twentytwenty and the only confirmed active plugin from the DB sample is ts-mail-tester.
• Cardora site URLs in the database are set to https://do5.cardora.co/ and wp1 is set to http://178.128.43.182/wp1.

Custom Code Signals

This host is not just stock WordPress content. It includes custom themes, plugins, and a websocket application that all need explicit treatment in the duplicate.

• Cardora theme: /var/www/cardora.co-do5/html/wp-content/themes/cardora
• Custom Cardora plugins: speakez-audio-recorder-cardora, speakez-video-recorder-cardora, tektonic-file-upload
• Legacy wp1 custom plugins: jd-plugin-01, ts-book-reviews, ts-custom-posttype, ts-mail-tester, ts-post-likes-counter
• Several custom plugins include composer metadata and bundled vendor trees, including AWS SDK and related PHP packages.
• The Speakez app includes ws/bin/server.php and service-setup notes for a Ratchet websocket process, implying an app component beyond plain Apache/PHP pages.

Ownership & Config Handoff

These findings shape how the copy/restore process should be executed on phoebe.lan.

• The main web roots and writable content paths checked so far are owned by apache:apache with 755 permissions.
• Key config files include wp-config.php for both WordPress installs, /etc/httpd/conf/httpd.conf, /etc/samba/smb.conf, /etc/my.cnf, and the Speakez websocket config files.
• SSL vhost files point at certificates for do5.cardora.co, do5.speakez.chat, and do5-sgvm.storage.cardora.co.

Preservation-First Archive Strategy

Because it may be hard to divine everything that matters on do5 in advance, the working recommendation is to preserve the host broadly on NAS and rebuild selectively on phoebe.

• Recommended approach: archive broadly, rebuild selectively.
• A full-preservation copy is feasible because the main archive scope currently looks modest: /var/www is about 1.3G, /var/lib/mysql about 185M, and the main /etc service config trees are tiny by comparison.
• The NAS safety net means the phoebe rebuild does not need to predict perfectly what matters on day one.
• Mounted NAS targets already exist locally, with /mnt/merlin-backups and /mnt/atrium-data/BACKUPS looking like the most plausible archive destinations to evaluate first.
• The first phoebe restore should focus on Cardora, wp1 if still wanted, and any Speakez/runtime pieces that are genuinely worth reviving; anything else can remain archived until needed.