Conversation
Prior to this commit, env_wrapper's 'setup_lima' command would only work for Linux because it uses the 'nproc' and 'free' shell commands, which do not exist on Mac. Now, the script detects the platform and uses the appropriate shell commands
…mands fix: fix setup_lima when run on a mac
(move snippets around to the right places)
0x416e746f6e
force-pushed
the
trunk/l2-merge-main
branch
from
e2327db to
042cd03
Compare
alexhulbert
left a comment
alexhulbert
left a comment
There was a problem hiding this comment.
Have some questions about a few things, I also made a PR with some additional changes at #121
modules/l2/_common/mkosi.extra/etc/systemd/system/systemd-networkd.service.d/override.conf
Show resolved
Hide resolved
|
|
||
| # Create users and groups | ||
| mkosi-chroot groupadd -g 1000 debian || true | ||
| mkosi-chroot useradd -u 1000 -g debian -m -s /bin/bash debian || true | ||
|
|
||
| cat <<EOF > "$BUILDROOT/etc/sudoers.d/debian" | ||
| debian ALL=(ALL) NOPASSWD:ALL | ||
| EOF | ||
| mkosi-chroot chmod 0440 /etc/sudoers.d/debian | ||
|
|
||
| mkosi-chroot mkdir -p /home/debian/.ssh | ||
| mkosi-chroot chmod 0750 /home/debian/.ssh | ||
| mkosi-chroot chown debian:debian /home/debian/.ssh | ||
|
|
||
| mkosi-chroot touch /home/debian/.ssh/authorized_keys | ||
| mkosi-chroot chmod 0600 /home/debian/.ssh/authorized_keys | ||
| mkosi-chroot chown debian:debian /home/debian/.ssh/authorized_keys |
There was a problem hiding this comment.
Can you elaborate on the purpose of this change?
There was a problem hiding this comment.
we run dev images in actual infra (not just in quemu).
this means that having serial console enabled by default w/o any authentication is not acceptable.
allowing root logins is also not acceptable.
still, we need to be able to login to (non-prod) instances for debug purposes.
hence the need for a non-root user with pre-seeded authorised ssh keys to allow limited set of users to login.
this diff enables that.
There was a problem hiding this comment.
i see the point of disabling the serial console on staging images and locking the images down to a predefined set of authorized keys, but if the debian user has full NOPASSWD sudo privileges, why is that any better than just allowing root login?
There was a problem hiding this comment.
debian user has full NOPASSWD sudo privileges, why is that any better than just allowing root login?
marginally better in the sense that they hit for root account most of time, not debian.
but I get your point: so, what would you suggest as an improvement?
There was a problem hiding this comment.
since password-based auth and serial console are pretty sketchy, i think we should disable them and go all in on a root authorized_keys file, similar to how we did it in yocto, like so:
- disable serial console by default but allow it to be enabled with SERIAL_CONSOLE=true or smth in the make command
- have either a
.gitignored authorized keys file in the devtools folder, or an env var like Yocto did, or both for convenience in both automated and local dev scenarios
does that satisfy all your use cases?
There was a problem hiding this comment.
well, that's probably way out of scope of this PR.
here I just need a non-root user to be available on the VM so that I could inject ssh keys there
There was a problem hiding this comment.
Made a simpler version of what I described above that accounts for the issues you explained.
0x416e746f6e
force-pushed
the
trunk/l2-merge-main
branch
from
9f103d2 to
af44ebf
Compare
0x416e746f6e
force-pushed
the
trunk/l2-merge-main
branch
3 times, most recently
from
7d04009 to
8d429a4
Compare
measured boot scripts are hardcoded at that size
0x416e746f6e
force-pushed
the
trunk/l2-merge-main
branch
from
8d429a4 to
da3446b
Compare
6 participants
this PR merges l2 images scripts into
main, namely:op-rbuilder+simulatoradditional notable changes:
debianuser with deterministic1000:1000uid/gidmanifest.mdlisting major components that went into the image and their versionssystemd-user-sessions.serviceso that non-root users could login (dev images only)