[WIP] initial implementation of a udm-boot container for #46

[spali]

First test build for using a "udm-boot" container that should manage everything.

Note:
I commented out to delete the existing on_boot.sh and move the on_boot.d duringpostinst.
So dpkg -P udm-boot && dpkg -i udm-boot_1.0.2_all.deb should leave you with a working 1.0.2 again.

a quick test with starting the tusc/chrony-udm container inside the udm-boot container did work as expected. Didn't had to execute any additional script, the port was exposed on the udm's ip itself.
Just as a test (shouldn't be in integrated in the release version) I included cockpit in the container on port 9090 (user: root / password: udm-boot) as a kind of quick and dirty interface. Nice would be, if we could use this to manage the "addon" containers.

Open questions (for sure only if this is a suitable way to go for you):

• Currently not sure if we should create a legacy service that start's the "old" scripts in boot.d or if we should force the people to use systemd in the udm-boot container.
• not an expert, so not sure how we should handle the macvlan inside (or maybe outside?) the container. Would it work to create a macvlan for the udm-boot container so containers that want to be regular network clients could event get a dhcp address?
• due the container get's built during installation an working internet connection is required. Maybe include a fixed image in the package?

ToDo:

• optimize the storage used by udm-boot container (mount for persistence config and persist i.e. nested containers, images)
• support for use /mnt/data_ext on UDMP if available.
• maybe we should implement our own ssh_proxy (same as unifi-os) because on unifi-os restart, the port changes and as I know a bind mount of the file into the udm-boot wont be updated when the file is replaced. So worst case would be to copy this functionality from S95unifos.

ANY feedback is welcome!

[boostchicken]

Hey man,

I am a little confused on what the benefit is and what we are trying to achieve here. could we jump on a video call and discuss the benefits and pros and cons and how this would look in the future?

I am not saying anything negative, I am just trying to understand better. Can you join my slack or let me know what a good place is to get a hold of you?

[boostchicken]

Also, check out my package manager branch, I am writing an installer for a lot of the stuff here as well as going to add a way to start and stop those services easily.

[spali]

Also, check out my package manager branch, I am writing an installer for a lot of the stuff here as well as going to add a way to start and stop those services easily.

Didn't try it out, but I can guess what the goal of the package manager is. I think this can work with your vanilla solution and with the podman in podman solution.

I am not saying anything negative, I am just trying to understand better. Can you join my slack or let me know what a good place is to get a hold of you?

Sure, you can invite me to your slack with the mail from the changelog in the debian package or the commits here.
Or we create a gitter.in channel for this repo or whatever :)
Just remember, I'm in CEST here... so I think best would be really late in your night or really early.

[spali]

am a little confused on what the benefit is and what we are trying to achieve here. could we jump on a video call and discuss the benefits and pros and cons and how this would look in the future?

We can talk about this also later, just more explanation beforehand:
I know, my approach could be an overkill for UDM-Base, but I think on UDMP, where we can use the additional drive, this would get a mess with containers and scripts. That's why I wanted to separate this as much as possible to not interfere with the devices standard stuff. Because we have podman and it allows to run a full blown system inside (including systemd and nested podman), I think we can use this to our advantage. So we only minimal hock into the device by creating a single container where everything additional lives inside it.
Basically we can reuse existing tools or something you started with the package manager to control systemd units (service,timer,path etc) and podman with the containers with the plan that we can use any standard container that is already available.
So currently missing is a neat interface for managing systemd units and the podman containers. That's why I startet to take a look at the cockpit project, which can potentially support both.

[spali]

added a version that should be able to replace the current 1.0.2 version by moving on_boot.d and on_boot.sh to /mnt/data/udm-boot/... and start the scripts in on-boot.d as before.
Because I included the container image in the deb file, it's to big for keeping in the repo. I uploaded it as release in my fork if someone wants to test it: https://github.com/spali/udm-utilities/releases/v1.1.0-poc-1

[spali]

https://github.com/spali/udm-utilities/releases/v1.1.0-poc-2

Additionally for #43, did a short test creating a symlink from /mnt/data/udm-boot to /mnt/data_ext/udm-boot seems to work to have the data on the additional drive on UDMP.
Basically after installation:

unifi-os shell
systemctl stop udm-boot
exit
mv /mnt/data/udm-boot /mnt/data_ext/
ln -s /mnt/data_ext/udm-boot /mnt/data/udm-boot
unifi-os shell
systemctl start udm-boot

[spali]

small update: https://github.com/spali/udm-utilities/releases/tag/v1.1.0-poc-3

[spali]

just rebased on current master

[boostchicken]

Is this good to go?

[spali]

maybe we need to wait for #71 first, because I observe the same problem with this PR.
And currently missing is how we document or integrate the existing containers to it.

[spali]

updated release, rebased master changes and potential fix for #71

https://github.com/spali/udm-utilities/releases/tag/v1.1.0-poc-4

[ntkme]

@spali I have an implementation of this idea that's ready for use.

Instruction is at here: https://github.com/ntkme/unifi-systemd-units

A few highlights about my implementation:

• A systemd container image based on fedora-minimal: https://github.com/ntkme/container-systemd-podman
• A systemd service for unifi-os to manage the unifi-systemd container: https://github.com/ntkme/unifi-systemd
  • This also install a small helper command unifi-systemd which is similar to unifi-os command.
• A few ready to use services at: https://github.com/ntkme/unifi-systemd-units
  • A compatibility service for migrating from udm-boot: https://github.com/ntkme/unifi-systemd-units#migrating-from-udm-boot
  • A ssh key management service: https://github.com/ntkme/unifi-systemd-units/blob/main/docs/ssh-key-dir.md
  • And a few more...
• Most of the things are built by GitHub Actions.

Feel free to have a try. Feedback are welcome!