MicroOS, busybox and the Desktop
Hi, currently, MicroOS is drifting in two directions: 1. "Container Host" and embedded/Edge 2. Desktop While this wasn't a problem until now, I see that we are now running into conflicts. The next step for MicroOS is, to replace as many tools with smaller variants, especially busybox, to get the system itself even smaller and concentrate on the few really needed tools to boot the system and start a container. But the desktop RPMs are requiring a lot of packages for "comfort". As example: to create sysem users, busybux-adduser or systemd-sysusers are enough (Ok, it requires quite some more work before systemd-sysusers becomes really useable, but we are working on that), but many "desktop" related RPMs require "shadow" to create the systems users. And there are many more similar cases. Any idea how to solve that? Using two different base patterns for MicroOS? That's something I would like to avoid. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
Moin, Am Mittwoch, 27. Januar 2021, 10:09:53 CET schrieb Thorsten Kukuk:
Hi,
currently, MicroOS is drifting in two directions: 1. "Container Host" and embedded/Edge 2. Desktop
While this wasn't a problem until now, I see that we are now running into conflicts.
The next step for MicroOS is, to replace as many tools with smaller variants, especially busybox, to get the system itself even smaller and concentrate on the few really needed tools to boot the system and start a container.
But the desktop RPMs are requiring a lot of packages for "comfort".
As example: to create sysem users, busybux-adduser or systemd-sysusers are enough (Ok, it requires quite some more work before systemd-sysusers becomes really useable, but we are working on that), but many "desktop" related RPMs require "shadow" to create the systems users. And there are many more similar cases.
Any idea how to solve that?
Is this currently an issue? If all packages state correctly whether they are fine with the busybox variant or need the full one, the correct option should be chosen automatically during installation. To prefer the busybox variant if possible, just add a "Suggests" or even "Recommends" to the pattern. The only problem is that installing or upgrading packages which then need the full variant and thus require replacement of busybox on the system currently leads to a nasty zypper conflict message which needs manual intervention. That's not new though.
Using two different base patterns for MicroOS? That's something I would like to avoid.
If special treatment of the desktop variant is needed, then the -desktop-common pattern could just have conflicts or require the full variant. Cheers, Fabian
Thorsten
On Wed, Jan 27, Fabian Vogt wrote:
Is this currently an issue?
The base pattern currently requires shadow, but busybox-adduser would be enough. Many desktop related RPMs require shadow.
If all packages state correctly whether they are fine with the busybox variant or need the full one, the correct option should be chosen automatically during installation. To prefer the busybox variant if possible, just add a "Suggests" or even "Recommends" to the pattern.
Recommends are ignored. I'm not sure how far Suggests really work.
The only problem is that installing or upgrading packages which then need the full variant and thus require replacement of busybox on the system currently leads to a nasty zypper conflict message which needs manual intervention. That's not new though.
But is much more difficult with transactional-update. But yes, looks like the base pattern has to e.g. require /usr/bin/gzip and suggests "busybox-gzip". Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
Moin, Am Mittwoch, 27. Januar 2021, 10:31:56 CET schrieb Thorsten Kukuk:
On Wed, Jan 27, Fabian Vogt wrote:
Is this currently an issue?
The base pattern currently requires shadow, but busybox-adduser would be enough. Many desktop related RPMs require shadow.
It could use a file dependency instead, or even (busybox-adduser or shadow).
If all packages state correctly whether they are fine with the busybox variant or need the full one, the correct option should be chosen automatically during installation. To prefer the busybox variant if possible, just add a "Suggests" or even "Recommends" to the pattern.
Recommends are ignored. I'm not sure how far Suggests really work.
They're not installed, but should still affect "multiple choice" resolution. If they don't, that would be a bug AFAIK.
The only problem is that installing or upgrading packages which then need the full variant and thus require replacement of busybox on the system currently leads to a nasty zypper conflict message which needs manual intervention. That's not new though.
But is much more difficult with transactional-update.
But yes, looks like the base pattern has to e.g. require /usr/bin/gzip and suggests "busybox-gzip".
Yep, and the non-MicroOS patterns could do the opposite and Suggest (or even Require) gzip. Cheers, Fabian
Thorsten
On Wed, Jan 27, Fabian Vogt wrote:
Moin,
Am Mittwoch, 27. Januar 2021, 10:31:56 CET schrieb Thorsten Kukuk:
On Wed, Jan 27, Fabian Vogt wrote:
Is this currently an issue?
The base pattern currently requires shadow, but busybox-adduser would be enough. Many desktop related RPMs require shadow.
It could use a file dependency instead, or even (busybox-adduser or shadow).
shadow uses /usr/sbin/useradd, and the packages requiring shadow are calling /usr/sbin/useradd. busybox-adduser contains /usr/sbin/adduser. So you would need to adjust all of this packages to use our sysusers-tools. In this case, adduser, useradd and systemd-sysusers would work. This solution would be the preferred one, but is a huge amount of work. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
Hi, On Wed, Jan 27, 2021, at 10:44, Thorsten Kukuk wrote:
On Wed, Jan 27, Fabian Vogt wrote:
Moin,
Am Mittwoch, 27. Januar 2021, 10:31:56 CET schrieb Thorsten Kukuk:
On Wed, Jan 27, Fabian Vogt wrote:
Is this currently an issue?
The base pattern currently requires shadow, but busybox-adduser would be enough. Many desktop related RPMs require shadow.
It could use a file dependency instead, or even (busybox-adduser or shadow).
shadow uses /usr/sbin/useradd, and the packages requiring shadow are calling /usr/sbin/useradd.
busybox-adduser contains /usr/sbin/adduser. So you would need to adjust all of this packages to use our sysusers-tools. In this case, adduser, useradd and systemd-sysusers would work. This solution would be the preferred one, but is a huge amount of work.
What about adding shadow to desktop-common and busybox to microos-minimal (as a newly to be made pattern for minimal server installs) /Syds
Thorsten
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
On Wed, Jan 27, Syds Bearda wrote:
On Wed, Jan 27, 2021, at 10:44, Thorsten Kukuk wrote:
busybox-adduser contains /usr/sbin/adduser. So you would need to adjust all of this packages to use our sysusers-tools. In this case, adduser, useradd and systemd-sysusers would work. This solution would be the preferred one, but is a huge amount of work.
What about adding shadow to desktop-common and busybox to microos-minimal (as a newly to be made pattern for minimal server installs)
You cannot install busybox-adduser and shadow at the same time, they have conflicts. So this would end in what I wrote at the beginning: different base patterns for "Container Host" and "Desktop". Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
hi, On Wed, Jan 27, 2021, at 11:05, Thorsten Kukuk wrote:
On Wed, Jan 27, Syds Bearda wrote:
On Wed, Jan 27, 2021, at 10:44, Thorsten Kukuk wrote:
busybox-adduser contains /usr/sbin/adduser. So you would need to adjust all of this packages to use our sysusers-tools. In this case, adduser, useradd and systemd-sysusers would work. This solution would be the preferred one, but is a huge amount of work.
What about adding shadow to desktop-common and busybox to microos-minimal (as a newly to be made pattern for minimal server installs)
You cannot install busybox-adduser and shadow at the same time, they have conflicts. So this would end in what I wrote at the beginning: different base patterns for "Container Host" and "Desktop".
But having different patterns is not weird though. Some packages/patterns are used for the server, some packages/patterns are for desktop. That a package that is normally in the base pattern to be different in the server-common or desktop-common patterns is not an issue in my eyes. /Syds
Thorsten
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
Moin, Am Mittwoch, 27. Januar 2021, 10:44:50 CET schrieb Thorsten Kukuk:
On Wed, Jan 27, Fabian Vogt wrote:
Moin,
Am Mittwoch, 27. Januar 2021, 10:31:56 CET schrieb Thorsten Kukuk:
On Wed, Jan 27, Fabian Vogt wrote:
Is this currently an issue?
The base pattern currently requires shadow, but busybox-adduser would be enough. Many desktop related RPMs require shadow.
It could use a file dependency instead, or even (busybox-adduser or shadow).
shadow uses /usr/sbin/useradd, and the packages requiring shadow are calling /usr/sbin/useradd.
Yes, which means that if you install a package which requires shadow, it will get shadow.
busybox-adduser contains /usr/sbin/adduser. So you would need to adjust all of this packages to use our sysusers-tools.
Only if all packages on the system are fine with busybox-adduser, busybox-adduser will be used instead. So there's no split between non-Desktop and Desktop, but simply between "systems which can use busybox" and "systems which need shadow". MicroOS with the usual server selections meets the former category, while others might not.
In this case, adduser, useradd and systemd-sysusers would work. This solution would be the preferred one, but is a huge amount of work.
As long as we don't have packages which only work with busybox, the current way should work just fine. Cheers, Fabian
Thorsten
On Wed, Jan 27, 2021 at 4:09 AM Thorsten Kukuk
Hi,
currently, MicroOS is drifting in two directions: 1. "Container Host" and embedded/Edge 2. Desktop
While this wasn't a problem until now, I see that we are now running into conflicts.
The next step for MicroOS is, to replace as many tools with smaller variants, especially busybox, to get the system itself even smaller and concentrate on the few really needed tools to boot the system and start a container.
But the desktop RPMs are requiring a lot of packages for "comfort".
As example: to create sysem users, busybux-adduser or systemd-sysusers are enough (Ok, it requires quite some more work before systemd-sysusers becomes really useable, but we are working on that), but many "desktop" related RPMs require "shadow" to create the systems users. And there are many more similar cases.
Any idea how to solve that? Using two different base patterns for MicroOS? That's something I would like to avoid.
I guess I should ask: why do you want to use busybox for the container host? That seems like a step too far... -- 真実はいつも一つ！/ Always, there's only one truth!
On Wed, Jan 27, Neal Gompa wrote:
I guess I should ask: why do you want to use busybox for the container host? That seems like a step too far...
MicroOS is not just only a container host, there are many more use cases where you never login to a shell on the machine. And why make the OS bigger than necessary in this cases? But even on a container host, if you use it for .e.g kubernetes, you don't need a full blown shadow package if systemd-sysusers would be enough and is always there. And if you need more features, you use busybox adduser. Between, for some tools, MicroOS is already using the busybox applet if dependency wise possible, and nobody noticed until today. But by pure accident, not design. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
On Wed, Jan 27, 2021 at 8:17 AM Thorsten Kukuk
On Wed, Jan 27, Neal Gompa wrote:
I guess I should ask: why do you want to use busybox for the container host? That seems like a step too far...
MicroOS is not just only a container host, there are many more use cases where you never login to a shell on the machine. And why make the OS bigger than necessary in this cases? But even on a container host, if you use it for .e.g kubernetes, you don't need a full blown shadow package if systemd-sysusers would be enough and is always there. And if you need more features, you use busybox adduser. Between, for some tools, MicroOS is already using the busybox applet if dependency wise possible, and nobody noticed until today. But by pure accident, not design.
Well, if you want to go in that direction, then as others have suggested, Suggests are still respected, even with installation of weak dependencies turned off. At least, they are with DNF. I would be shocked if Zypper messed that one up. In the minimal base, use conditional Suggests: Suggests: (coreutils if patterns-microos-desktop else busybox) -- 真実はいつも一つ！/ Always, there's only one truth!
participants (4)
-
Fabian Vogt -
Neal Gompa -
Syds Bearda -
Thorsten Kukuk