With the merge of the pi-5-support branch in the debian-12 repository,
we're now including everything we need from the Raspberry OS repository,
via the pirogue-3rd-party part of our PPA.
This should give us peace of mind regarding further package updates.
Link: https://github.com/PiRogueToolSuite/pirogue-images/issues/2
Link: ef742a961f
Even if those prompts and the associated answers are already documented
in “Beginner guide - How to setup a PiRogue”, it's a bit annoying to
have to go through them every time a new PiRogue is set up.
Let's pick the right answers (moving away from the default every time),
and mark those questions as seen (i.e. asked and answered):
- Save current IPv4 rules? Yes → No
- Save current IPv6 rules? Yes → No
- Should non-superusers be able to capture packets? No → Yes
Link: https://github.com/PiRogueToolSuite/pirogue-images/issues/3
Another way could be to install the Raspberry Pi kernel first, compare
the contents of the initramfses for the Debian and the Raspberry Pi
kernels, and fix the missing files in the latter. Duplicating hook and
script seems a little more straightforward.
For the time being, let's keep both Pi 3/Pi 4 and Pi 5 recipes separate,
making it easy to modify the latter freely. Later on, it will probably
make sense to have a common section.
Let's *disable* ssh.service to make sure it doesn't start too soon, and
modify the rpi-generate-ssh-host-keys.service unit (that triggers the
generation during the first boot) to enable+start ssh.service when
everything is ready.
See: https://salsa.debian.org/raspi-team/image-specs/-/issues/72
The original image leads to repeated failures to start for sshd.service
since there are no host keys initially. Make sure the unit in charge of
getting those keys generated runs before sshd.
The following block gets repeated otherwise:
systemd[1]: Starting ssh.service - OpenBSD Secure Shell server...
sshd[795]: sshd: no hostkeys available -- exiting.
systemd[1]: ssh.service: Control process exited, code=exited, status=1/FAILURE
systemd[1]: ssh.service: Failed with result 'exit-code'.
systemd[1]: Failed to start ssh.service - OpenBSD Secure Shell server.
systemd[1]: ssh.service: Scheduled restart job, restart counter is at 1.
systemd[1]: Stopped ssh.service - OpenBSD Secure Shell server.
It's a matter of habit more than an absolute technical requirement.
Quoting the useradd manpage:
useradd is a low level utility for adding users. On Debian,
administrators should usually use adduser(8) instead.
The default SSH configuration is Debian 12 is as follows:
#PermitRootLogin prohibit-password
#PermitEmptyPasswords no
(The default values are commented out, ready to be tweaked by local
admins.)
It's pretty standard to have 127.0.0.1 match localhost while the actual
machine's name (FQDN and hostname) matches 127.0.1.1 instead.
We would be happy to be told if something similar exists for IPv6!
