66 on alpine linux

pramodvu

Alpine's boot@ module is almost ready.
Where is 66-dbus-launch?
Plz add it in subpackages=(),
and the appropriate build options to build it.
It depends on basu [or elogind which I don't recommend.], which is already in the alpine repos.

It is the ONLY way to run dbus-broker, which is better than dbus-daemon.

Also, integrating login session management with 66-boot-user@ would remove the need for utlogd, which I don't recommend.

And no need oblog, which is just 66-yeller. [Do ln -s 66-yeller $BIN/oblog]

I suggest you to see into obsysusers, which would help in system-user-management in Alpine.

pramodvu

Due to a mistake, I accidentally ran a curl | sh from reddit which ran rm -rf /mnt; On the LiveUSB when a few libs were broken.

Sorry, all work gone...

But I am again telling that most of the required alpine scripts are already implemented for Obarun... There's no need to reimplement them without valid reasons...

pramodvu

https://git.obarun.org/66-service/arch/boot

I will be back by trying this itself directly on alpine...

pramodvu

pramodvu Sorry, but for some reason make install fails...
I guess it's because alpine's make isn't GNU make...

Edit: make itself runs make install;
It also detects whether the installation is already done, and doesn't re-install if so... [It successfully overwrites as if it wan't installed, after a fresh git clone of the repo and re-running the commands...]

Will now further try it... whether it works, what improvements needed...

Edit: It requires basic variables like TZ etc... [I was trying it in a cobbled-up unshare -fmuipC -R . /bin/ash chroot...; Now over to the VM...]

pramodvu

Making progress...

Am also writing gentoo ebuilds for 66, oblibs, 66-tools etc... [But making things like TTY optional; I want to support running 66 under sysvinit, via a line similar to ::respawn:66 scandir start in /etc/inittab... Makes switching much easier]

pramodvu

Sorry, was fixing some issues with boot@ on gentoo; BTW it doesn't respect DESTDIR and that breaks the buildscript...

pramodvu

UPDATE: I have written the core busybox services, in the Alpine Linux 66-service group: https://git.obarun.org/66-service/alpine/busybox-daemons/

I wrote them for gentoo, but they are more useful in alpine right now (can be used in gentoo as-is).

A ./configure, a Makefile, some %%BINDIR%% uses instead of directly /bin/busybox for basic build-time configurability, etc... would be appreciated...
I am busy with other parts of gentoo regarding supporting 66 so I can't do it myself now, sorry...

I'll add the rest of the services in busybox soon...

pramodvu

Remaining daemons

acpid
ftpd
getty
httpd
nbd-client (instantiated service mostly)
telnetd
tftpd
udhcpd, udhcpc6, udhcpc

Will be included in the repo soon

Kindly inform me if I've missed something

pramodvu

I have made significant progress in packaging for gentoo, many frontends from Arch are already packaged.

I will start packaging for alpine too.
I am here to ask on the policy of packaging, if I am right if I do:

I will package each frontend (or multiple frontends in the same repo in 66-service/Arch) in a separate package.
Anything requiring Alpine-specific changes will be forked into 66-service/Alpine.
I will fork boot@; It ideally works exclusively with busybox (and s6 utils). (I don't think I can do it right now...)
I know Alpine's apk has something called install_if which I can use to pull the appropriate frontend package(s) automatically if any package is (un)installed. IDK how it works yet, help will be appreciated...

eric

Many thanks for your hard work on that.

pramodvu

In gentoo, (almost) all the work is done; The only thing left is to fully complete the metapackage, it's metadata etc... and package the few remaining low-priority frontends...

I'll start Alpine's work now. Slowly.

But 1st, there needs to be some kind of 66-initial-setup script to take care of things at the first time post-install boot...

grep '^uuid-regex-by-....-dots' /etc/machine-id | wc -l confirm if there's a valid UUID (and only 1 line) otherwise overwrite the file with a new one.
Some core system symlinks... like /bin -> /usr/bin on usr-merged systems.
Enable the core boot@.
Ensure /proc /sys etc... are mountable.
What else?
I'll start a new post for this anyways...

pramodvu

@vixalien Are you already planning for something similar? Will I be stepping on your toes?

BTW, I didn't find any documentation on install_if...
I want to make sure that for every $package on the system with daemons, just like $package-openrc is also installed, but only if openrc itself is installed, I want to do for 66

vixalien

Sorry, I'm not working on anything similar. My preferred approach would be to just port over the default services present in a base alpine install instead of doing everything from scratch, but it's okay.

If you add install_if="66", then that (sub)package will be automatically installed when 66 is installed.

vixalien

thanks on your work btw

pramodvu

I plan to,

Create APKBUILDs for every 66 frontend available... (or a set of frontends for a package)
In the APKBUILDs, for every package daemon-66 I will add install_if="daemon 66" e.g. dhcpcd-66 will have install_if="dhcpcd 66"
This will match the behaviour of the (many) daemon-openrc packages...

vixalien thanks on your work btw

I'm extremely sorry to inform that I am having personal setbacks... I might not be able to do everything as soon as expected... But I'll try my best...

pramodvu

maintainer="@MAINTAINER@"
pkgname=@DAEMON@-66
pkgver=@VERSION@
pkgrel=1
_packagefordaemon="${pkgname%-*}"
_suffix="${pkgname#*-}"
pkgdesc="66 frontend for package $_packagefordaemon"
url="https://web.obarun.org/software/66-service/Arch/$_packagefordaemon"
arch="all"
license="0BSD"
install_if="$_suffix $_packagefordaemon"
source="$pkgname-$pkgver.tar.gz::https://git.obarun.org/66-service/Arch/$_packagefordaemon/-/archive/$pkgver/66-$pkgver.tar.gz"
#options="!check"
#install="$pkgname.pre-install $pkgname.pre-upgrade"

build() {
	./configure \
		--prefix=/usr \
	make
}

package() {
	make DESTDIR="$pkgdir" install
}

sha512sums="@SHA512SUMS@"

Kindly append to 66's optional dependenies (need to be pulled automatically similar to install_if dependenies) the packages like s6-networking s6-portable-utils 66-tools to ensure that every frontend will have these really basic tools available without pulling a dependency. Of course, they should be maskable via apk add !s6-linux-utils if someone uses 66 without needing them...

I am away from any computer for quite a few days, sorry... Kindly proceed... Good Luck

Regards,
Pramod V U

pramodvu

I will start packaging. Soon.

As to what frontends excatly to package, what are needed, etc... I am referring https://pkgs.alpinelinux.org/packages?name=*openrc*

As required I'll add new frontends to (sub)repos under 66-service/Alpine...

vixalien

Hello @eric

I have updated the on suite in https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/85062.

Maybe you can check if it makes sense for the switch to meson. Notably weird is that docs and tests are not built by default with meson.

eric

vixalien

Just found a bug with the meson build system, the 66-shutdownd program is installed to /usr/libexec path instead of /usr/bin which create crash at boot and shut down time.
I'm currently managing it creating a hot fix release (0.8.2.1).

vixalien Maybe you can check if it makes sense for the switch to meson. Notably weird is that docs and tests are not built by default with meson.

I will not follow skarnet on this: https://github.com/skarnet/s6/commit/7dda4a124069438acb19a419a088f5c1ab9b4670
adding more and more sh script to maintain and debug.
Meson is clean, widely used, easy to maintain, to debug and easier for vendor concerning cross compilation. So for me it make perfect sense. It's just a matter of choice.

Notably weird is that docs and tests are not built by default with meson.

It's a matter of choice too. Maybe i'm wrong for this one....

vixalien

Hey the switch to Meson is actually really great. It's much more familiar and predictable.

It's a matter of choice too. Maybe i'm wrong for this one....

I think tests should be built by default. Docs is another topic, but maybe it should be built automatically when lowdown is installed

« Previous Page