Matthias Lüscher

This would be a cool "selling feature": `edi lxc scan CONTAINER_NAME` or `edi target scan IP_ADDRESS` I did not know about debsecan - it looks like a useful tool.

Furthermore, the entire Ansible setup could be reduced to one single playbook pulling in a bunch of roles.

There was so far no need for customization in that phase of the image/container generation process.

The warning or error could also be shown during the playbook execution.

`sudo mmdebstrap --include=python3,python3-apt,sudo,netbase,net-tools,iputils-ping,isc-dhcp-client,systemd,systemd-sysv,gnupg,dumb-init --arch=arm64 --variant=minbase bookworm minbase.tar` will give a comparable root file system.

Rootless container build: ``` #!/bin/bash set -o nounset set -o errexit set -o pipefail newcontainer=$(buildah from scratch) buildah unshare --mount container_root=${newcontainer} bash -c 'mmdebstrap --mode=unshare --include=python3,python3-apt,sudo,netbase,net-tools,iputils-ping,isc-dhcp-client,systemd,systemd-sysv,gnupg,dumb-init --variant=minbase bookworm ${container_root}' echo...

Good point! Just curious - did this cause any issue? Or does mkimage just use this parameter to "document" the stuff? Instead of writing two tasks we could also do...

There are also other places where we need to map the Debian architecture: Example 1, qemu: ``` def _get_qemu_binary_name(self): arch_dict = {'amd64': 'x86_64', 'arm64': 'aarch64', 'armel': 'arm', 'armhf': 'arm', 'i386':...

I agree that an additional layer might make sense. [Currently we have](https://docs.get-edi.io/en/latest/config_management/overlays.html): base -> global -> HOST -> USER What about extending it: base -> somegoodname -> global -> HOST...

At the moment I prefer "local". Then the user can decide what he wants to put into the overlay.