slides(tappaas): the session builds the merged podman module

Podman and Portainer are one module now — engine plus GUI — so the deck follows:
podman.json, vmid 812, both sockets on the update.sh slide, and the console at
https://lab1.makerfloss.eu because --proxyDomain makes the module the
environment's gateway rather than podman.lab1.makerfloss.eu.

All commands verified against a live install on lab1.

slides/tappaas/how-to/new-module/index.md

@@ -4,7 +4,7 @@ theme: gaia
 class: invert
 paginate: true
 title: How to implement a TAPPaaS module
-description: Live build of a Portainer module — OrangeMaker, 24 August
+description: Live build of the podman module — OrangeMaker, 24 August
 ---
 
 <style>
@@ -27,7 +27,7 @@ section.diagram h2 { margin-bottom: 0.1em; }
 
 # Getting a module onto TAPPaaS
 
-Live build of a **Portainer** container console
+Live build of a **container host** — Podman, with a console
 
 OrangeMaker · 24 August
 
@@ -42,7 +42,7 @@ counterpart — keep the deck moving and spend the time in the shell.
 
 1. **What TAPPaaS is** — a few diagrams, ten minutes, no deeper
 2. **What a module actually is** — a json contract and three scripts
-3. **Build one live** — the `lab1` environment, then `portainer` into it
+3. **Build one live** — the `lab1` environment, then `podman` into it
 4. **Prove it works** — tests, then the web console
 5. **You get a login** — your own identity on this system
 
@@ -69,7 +69,7 @@ flowchart LR
     ha["home-assistant"]
   end
   subgraph z2["lab1 · zone lab1"]
-    pod["portainer — today"]
+    pod["podman — today"]
   end
   sat --> net
   cicd --> nc
@@ -156,8 +156,8 @@ We track **`main`**, not `stable` — this is a lab, we want the new things.
 ## A module is a contract and three scripts
 
 ```text
-portainer/
-├── portainer.json  # the contract — what it is, needs, provides
+podman/
+├── podman.json     # the contract — what it is, needs, provides
 ├── install.sh      # put the software in the VM        (once)
 ├── update.sh       # keep it patched                   (on schedule)
 ├── test.sh         # prove it still works              (gates updates)
@@ -173,12 +173,12 @@ That is the whole surface. Everything else is the platform's job.
 
 ```json
 {
-  "description": "Portainer CE — container console with TAPPaaS login",
-  "vmname": "portainer", "vmid": 813,
+  "description": "Podman host with a Portainer console, TAPPaaS login",
+  "vmname": "podman", "vmid": 812,
   "dependsOn": ["cluster:vm", "templates:debian", "backup:vm",
                 "network:proxy", "identity:identity"],
   "identity": { "oidcRedirectPaths": ["/"],
-                "secretsEnv": "/etc/secrets/portainer.env" },
+                "secretsEnv": "/etc/secrets/podman.env" },
   "config": {
     "cluster:vm": { "cores": 2, "memory": "2048", "diskSize": "32G",
                     "image": "debian-13-generic-amd64.qcow2" },
@@ -214,11 +214,11 @@ good `install.sh`.
 Runs on the **mothership**, not on the VM. It:
 
 1. finds the node hosting the VM via `pvesh`, resolves its IP through the **guest agent**
-2. `apt install podman`, then enables the **rootful** `podman.socket` — that socket
-   *is* the Docker-compatible API Portainer speaks
+2. `apt install podman`, then enables **both** sockets: the rootful one *is* the
+   Docker-compatible API Portainer speaks; the rootless one is for people who ssh in
 3. pulls `portainer-ce:lts` and runs it against the socket + a named volume
-4. creates a **break-glass admin**, password into `/etc/secrets/portainer-admin`
-5. reads `/etc/secrets/portainer.env`, fetches the OIDC **discovery document**,
+4. creates a **break-glass admin**, password into `/etc/secrets/podman-admin`
+5. reads `/etc/secrets/podman.env`, fetches the OIDC **discovery document**,
    and `PUT`s the three endpoints into `/api/settings` → login becomes OAuth
 
 Re-runnable throughout: the container is recreated only when the image digest
@@ -250,7 +250,7 @@ unattended updates are safe — that is the entire deal.
 - A VM — `cluster:vm` built it from the Debian 13 cloud image
 - OS prep — `templates:debian` did apt + guest agent
 - A VLAN, an interface, DHCP, firewall rules — the zone came with the environment
-- `https://portainer-lab1.lab1.makerfloss.eu`, valid cert — `network:proxy`
+- `https://lab1.makerfloss.eu`, valid cert — `network:proxy`
 - An OIDC application, a group binding and client credentials — `identity:identity`
 - Nightly backup to PBS, scheduled updates, health reporting
 
@@ -282,13 +282,14 @@ posture and DNS names — `lab1.makerfloss.eu` outside, `lab1.internal` inside.
 ```bash
 site-manager repository add forgejo.makerfloss.eu/TAPPaaS/makerfloss --branch main
 
-module-manager module add portainer --environment lab1
-module-manager module list                  # what is deployed
-module-manager module show portainer-lab1   # note the -lab1 suffix
+module-manager module add podman --environment lab1 \
+    --proxyDomain lab1.makerfloss.eu        # publish at the environment's own name
+module-manager module show podman-lab1      # note the -lab1 suffix
 ```
 
-Outside the default environment the module is **`portainer-lab1`** — `add` takes
-the base name, everything after it takes the effective one.
+Outside the default environment the module is **`podman-lab1`** — `add` takes the
+base name, everything after it takes the effective one. `--proxyDomain` makes it
+the environment's **gateway** instead of `podman.lab1.makerfloss.eu`.
 
 Watch the order: dependencies resolve first, then the VM, then the network, then
 `install.sh`. Install order is **computed** from every module's `dependsOn` — nobody
@@ -301,10 +302,10 @@ maintains a list.
 ## Demo 3 — prove it, then look at it
 
 ```bash
-module-manager module test portainer-lab1
+module-manager module test podman-lab1
 ```
 
-Then open **`https://portainer-lab1.lab1.makerfloss.eu`** and press **Sign in**.
+Then open **`https://lab1.makerfloss.eu`** and press **Sign in**.
 
 - No login form. You are already you — Authentik, via OIDC.
 - Not in `devops`? No console. The group binding **is** the access gate.
@@ -317,11 +318,11 @@ Create a container. Start it. Read its logs. From a browser, as yourself.
 ## Where this module lives
 
 ```text
-makerfloss/src/containers/portainer/
+makerfloss/src/containers/podman/
 ```
 
-Two siblings next to it: `podman/` (one host, local login) and `komodo/` (GPL,
-scripts still to write). Same job, three answers.
+One sibling next to it: `komodo/` — the GPL alternative, scripts still to write.
+Podman is the engine; Portainer is the GUI running *as a container on it*.
 
 Three homes for a module, all first-class:
 
@@ -329,7 +330,7 @@ Three homes for a module, all first-class:
 | --- | --- |
 | **TAPPaaS** repo, by pull request | modules the whole project should carry |
 | **Community** repo | yours, shared, no gatekeeping |
-| **Private** repo — `forgejo.makerfloss.eu/TAPPaaS/makerfloss` | ours, today's portainer |
+| **Private** repo — `forgejo.makerfloss.eu/TAPPaaS/makerfloss` | ours, today's podman |
 
 Adding a repository is one `site-manager repository add`.
 
@@ -348,7 +349,7 @@ authentik-manager user-recovery-link <you>   # one-time URL: set your own passwo
 
 One login per person, roles via groups. Nobody types a password into a chat window.
 
-<!-- Do these live, one per participant, while the portainer VM builds. -->
+<!-- Do these live, one per participant, while the podman VM builds. -->
 
 ---