91 lines
2.7 KiB
Markdown
91 lines
2.7 KiB
Markdown
|
Ah, yes — you’re right! The previous summary focused on ASL, PEL, domains, and blocks, but we also discussed **building an ASL-AUTH-HOST ISO and bootable USB workflow**. Here’s a compact recap integrated with your overall architecture:
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# Bootable ASL-AUTH-HOST / USB Summary
|
|||
|
|
|
|||
|
|
## 1. Environment
|
|||
|
|
|
|||
|
|
* Start from a **minimal Debian root** (via `debootstrap`) inside a container.
|
|||
|
|
* Set up:
|
|||
|
|
|
|||
|
|
* `$WORKDIR/iso_root` → ISO root filesystem
|
|||
|
|
* `$WORKDIR/overlay` → ASL binaries, scripts, and configuration
|
|||
|
|
|
|||
|
|
## 2. Overlay contents
|
|||
|
|
|
|||
|
|
* `bin/` → `asl-auth-host`, `asl-rescue`, helper scripts
|
|||
|
|
* `usr/local/bin/` → optional local tools
|
|||
|
|
* `var/lib/asl/` → datasets, pools, personal/common directories
|
|||
|
|
* `var/log/` → logs
|
|||
|
|
* Bootloader configs (`isolinux/`)
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 3. Bootable ISO creation
|
|||
|
|
|
|||
|
|
* Copy overlay into `$ISO_ROOT`
|
|||
|
|
* Create ZFS-like dataset directories:
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
var/lib/asl/{common,personal,pools}
|
|||
|
|
```
|
|||
|
|
* Generate ISO via `xorriso` (or `mkisofs`) with minimal bootloader
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 4. ASL Capture Integration
|
|||
|
|
|
|||
|
|
* **`asl-capture`** can wrap shell or program execution
|
|||
|
|
* Capture occurs **during image creation**:
|
|||
|
|
|
|||
|
|
* Can log everything in the host root during debootstrap + `apt-get install`
|
|||
|
|
* Produces artifacts (executed commands, receipts)
|
|||
|
|
* Early capture allows **provenance from the very birth of the image**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 5. USB boot workflow
|
|||
|
|
|
|||
|
|
1. Build ISO (`build_asl_auth_host_iso.sh`)
|
|||
|
|
2. Write ISO to USB (`dd` or `rufus`/`balenaEtcher`)
|
|||
|
|
3. Boot machine → `init-asl-host.sh` (custom init script)
|
|||
|
|
|
|||
|
|
* Mount ZFS or overlay store
|
|||
|
|
* Initialize domains (Common, personal, rescue)
|
|||
|
|
* Enforce witness authority / DAM at boot
|
|||
|
|
* Run ASL capture to log host state
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 6. Storage & persistence on USB
|
|||
|
|
|
|||
|
|
* Personal domain: local USB store
|
|||
|
|
* Root.alice or Common: mounted network or local store
|
|||
|
|
* Snapshot management ensures deterministic state
|
|||
|
|
* Blocks and artifacts are packed according to store policy
|
|||
|
|
* Index/log replay reconstructs current state at boot
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 7. Key insights from discussion
|
|||
|
|
|
|||
|
|
* You **can capture the host from first boot** to have full provenance.
|
|||
|
|
* Witness authority (DAM) is enforced **before userspace programs run**, even for Common.
|
|||
|
|
* Blocks remain storage-level; artifacts remain semantic and authoritative.
|
|||
|
|
* Publishing to Common happens **via root.alice**; private artifacts remain in `alice` domain.
|
|||
|
|
* Bootable USB + ASL capture = deterministic, auditable host for rescue and auth purposes.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
If you want, I can **draw a full flow diagram** that shows:
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
debootstrap → overlay → ISO → USB → boot → init-asl-host → domains → ASL capture → artifacts/logs
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
…including where **root.alice, Common, and personal domains** live, and how **blocks, artifacts, and logs** interact during boot.
|
|||
|
|
|
|||
|
|
Do you want me to do that diagram next?
|
|||
|
|
|