On Sun, Mar 17, 2019 at 03:30:02PM +0100, Oliver Schad wrote:
> So in the end Slew was great to understand, how s6 could be integrated
> as a pattern. But the units/scripts itself didn't work for us.
I personally use Alpine for servers and Void for desktops, and so did
not know what problems distributer might encounter in Debian/Ubuntu. So
first of all I need to thank you for attempting to use slew on real-life
systems, which is exactly how the slew codebase can evolve to suit more
application scenarios.
> https://gitlab-2.asag.io/snippets/7
I constructed a slew-managed Ubuntu system with only essential services,
udhcpc on eth0, and sshd, reproducible with the following steps:
* Install Ubuntu on a VM with `ubuntu-18.04.2-server-amd64.iso'.
(Using the US keymap, and with SSH server enabled).
* Build static execline, s6 and s6-rc using attached `ska-build.sh' (as
root), and tailor slew for Ubuntu using attached `slew-build.sh'.
(Better done on an Alpine VM because Ubuntu does not use musl.)
* Transfer the `pkgs' directory (with its contents, all produced in the
step above) to the Ubuntu VM, run (as root) attached `slew-build.sh'
in the directory where `pkgs' reside.
I personally find the changes fairly minor, except for these issues:
* Debian/Ubuntu do not package eudev, so I used `/sbin/udevd' from
Devuan as a workaround; to ensure basic safety, you definitely need to
package this yourself for your customised Debian/Ubuntu systems.
* One other nuisance is that while the slew-managed system uses ~32M
memory after booting, the dracut-generated initramfs barely loads even
with 256M, which is an important reason for avoiding Ubuntu.
> So may I ask directly: is the plan to provide scripts/units for
> everyone, which works almost out of the box?
Linux distros are too diverse for slew to fully accomodate, but slew
has been designed from the beginning with flexibility in mind: once you
successfully customise it for the expected average case of a distro, the
user-level customisations would be fairly easy. And as you can see from
the attached scripts, the distro-level customisations are, while perhaps
non-trivial, quite manageable.
--
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C
Received on Mon Mar 18 2019 - 14:44:43 UTC