[pmoust]

An external tester ran curl -fsSL brig.sh/install | sh on the Ubuntu 26.04 LTS cloud image as a normal user, and the user install stopped before the download with newuidmap is missing, setfacl is missing and a block of commands for root. They read it as a failure.

Reproduced on GCP (Ubuntu 26.04.1, kernel 7.0, nested KVM). The default user there has sudo without a password. The installer already makes the AppArmor profile, the udev rule and the vhost_vsock module with that sudo, but treated packages and a subuid range as root's alone, so a fresh image, which lacks uidmap and acl, stopped regardless. After running the printed block, the same install finished and booted Ubuntu 26.04, so nothing else on 26.04 is broken.

With sudo that needs no password, the installer now installs those packages and adds the subuid range before the download, checks the host again, and goes on. The rest stays with the rootless setup, as before. When sudo needs a password, a user in the sudo, admin or wheel group is asked for it once on the terminal, and the install goes on the same way. Under curl | sh stdin is the script, so the prompt reads /dev/tty. With no terminal, or for any other user, it stops as before, and now also names sudo -v (it did that only when no package was missing). A failed sudo step stops the install and says so.

Checked:

• On a fresh Ubuntu 26.04 VM, as the default user: one run of this install.sh installed uidmap and acl, installed rc20, brig doctor had no failing row, and brig sh ubuntu booted. As a user with no sudo: it stopped, printed the block, and named sudo -v. On a second fresh VM, as a user in the sudo group whose sudo needs a password, under a terminal with the script on stdin as curl | sh runs it: one password prompt, then the install finished, brig doctor had no failing row, and brig sh ubuntu booted.
• tests/install-preflight.sh has new cases: no sudo, sudo, a failed sudo step, the password prompt, and no prompt without a terminal or a sudo group. They pass in a Debian container as a normal user, and the first fails on the installer from main.
• shellcheck passes.

Run on five fresh GCP VMs (n2-standard-4, nested KVM), as the image's default user, with this branch's install.sh, then brig doctor and brig sh ubuntu:

Distribution	Before the install	Installed with sudo	Result
Ubuntu 26.04.1 LTS	no newuidmap, no setfacl, AppArmor restricts user namespaces	apt-get install -y uidmap acl	install ok, doctor clean, sandbox boots, guest DNS works
Debian 13	no newuidmap, no setfacl	apt-get install -y uidmap acl	same
RHEL 10.2, SELinux enforcing	no setfacl	dnf install -y acl	same
openSUSE Leap 16.0	no setfacl, no iptables	zypper --non-interactive install acl iptables	same
Arch Linux (current)	no subuid range	usermod --add-subuids ...	same

The first round found two more problems, now fixed here. The package step always ran apt-get, so RHEL and openSUSE stopped. It now uses the host's package manager (apt-get, dnf, yum, zypper or pacman) and its package names. And on openSUSE Leap 16, which ships nftables alone, every run failed in the network setup, since the CNI firewall plugin runs iptables (plugin type="firewall" failed (add): could not initialize iptables protocol 0: exec: "iptables": executable file not found). urunc showed it as failed to read from init socket: EOF, as in brig-sh/brig#541. A user install now installs iptables with the other packages (iptables-nft on the RHEL family). The check also looks in /usr/sbin, so Debian, which keeps it there, stops warning about an iptables it has.

Fedora is not in the table: GCP has only Fedora CoreOS images.

This reaches brig.sh/install once a bundle release carries it and brig's install.sh pins that release (it pins rc19 today).

[pmoust]

Ran this branch at 034d3e2 on five fresh GCP VMs, as each image's default user (sudo without a password): sh install.sh, then brig doctor, then brig sh ubuntu with a DNS lookup in the guest.

Distribution	Before the install	Installed with sudo	Result
Ubuntu 26.04.1 LTS	no newuidmap, no setfacl, AppArmor restricts user namespaces	apt-get install -y uidmap acl	install ok, doctor clean, sandbox boots, guest DNS works
Debian 13	no newuidmap, no setfacl	apt-get install -y uidmap acl	same
RHEL 10.2, SELinux enforcing	no setfacl	dnf install -y acl	same
openSUSE Leap 16.0	no setfacl, no iptables	zypper --non-interactive install acl iptables	same
Arch Linux (current)	no subuid range	usermod --add-subuids ...	same

Doctor had no failing line on any of them. The first round, at e115abf, failed on RHEL and openSUSE (apt-get only) and then on openSUSE's missing iptables. 034d3e2 fixes both. A user whose sudo asks for a password was checked earlier on Ubuntu 26.04: one prompt, then the same result.