🧭 Camelot II Exploration & VM Launch Plan

🎺 And thus begins the Day of Exploration in Camelot II...

Where Frodo gazes across the LAN, sshes to Camelot, and begins conjuring VMs like spells in a scroll — all while thinking “Wasn’t I working on some access crap too?”

Let’s sort this adventure with a High-Level To-Do List, one that lets you both explore libvirt/KVM and not lose track of the greater quest: building a functional VM for your real work, possibly including the TransferDepot 🗂️🚪🌀.

🧭 Camelot II Exploration & VM Launch Plan

🧑‍💻 0. Prep Work (Now from Frodo)

•  ✅ SSH into Camelot
• ✅ Verify messages from Merlin were transferred successfully: /file-transfer-integrity-check-updated-for-merlins-sound-bytes
• ✅ Ensure Camelot has internet or repo access (for package installs)

🏗️ 1. Set Up libvirt + KVM Stack on Camelot

# Ensure KVM and libvirt are ready
sudo dnf install -y @virtualization virt-install libvirt-daemon libvirt-daemon-config-network bridge-utils

# Start and enable libvirtd
sudo systemctl enable --now libvirtd

# Add your user (e.g., 'frodo') to libvirt group
sudo usermod -aG libvirt $(whoami)

Optional GUI (if you have GUI on Camelot):

sudo dnf install virt-manager

🧱 2. Build Your First VM (Manually)

•  ✅ Place ISO in /var/lib/libvirt/images/ or mount from Frodo
• ✅ Create storage volume for VM
• ✅ Run virt-install

Example:

virt-install \
  --name wormhole-dev \
  --ram 4096 \
  --vcpus=2 \
  --os-variant=fedora40 \
  --cdrom /var/lib/libvirt/images/Fedora-Server-netinst.iso \
  --disk size=20 \
  --network bridge=virbr0 \
  --graphics none \
  --console pty,target_type=serial

🌀 3. The New Wormhole Project (Access-related work)

You mentioned working on:

"some access crap... new wormhole..."

That was likely the index.php/Special:Wormhole page you were configuring in MediaWiki, possibly connected to secure file access or a shortcut UI for privileged users like causer2.
You were:

• Managing Access Control (possibly via Nginx rules + MediaWiki groups)
• Using Wormhole as a UI gateway to services behind a reverse proxy
• Mentioning file transfer to/from the TransferDepot

Does that ring a bell? 👇
✅ Related items:

• MediaWiki access workflow (ApprovedRevs, roles)
• Reverse proxy ACLs for old *zilla and MediaWiki systems
• Possibly making wormhole a smart redirect or jump page

📦 4. TransferDepot Planning (File Movement for Olde Folkes)

If we are building the TransferDepot, that means:

•  ✅ A VM or container dedicated to holding uploaded files
• ✅ Logical folder structure (e.g., /holding, /north_download, etc.)
• ✅ Access permissions based on user/role/location
• ✅ Web interface (TinyFileManager?) or scp/rsync target  <-- teach the people cli (  )
• ✅ Sync mechanism between TransferDepot and other VMs/services

 

🗂️ TL;DR High-Level ToDo List

| Priority | Task                                                                 |
| -------- | -------------------------------------------------------------------- |
| 🔥       | SSH to Camelot and verify ISO/file transfers                         |
| 🧱       | Set up KVM/libvirt (install packages, enable service)                |
| 🧙‍♂️       | Create 1st VM (for wormhole or TransferDepot testbed)                |
| 🌀       | Revisit Wormhole project (MediaWiki access shortcut?)                |
| 🗃️       | Decide on TransferDepot location: new VM or existing service         |
| 🧪       | Test file push/pull from Frodo and causer2 to TransferDepot          |
| 🚪       | Consider DNS or `/etc/hosts` for LAN naming (so `ssh camelot` works) |

 

🏰