MicroOS short on utils-package from the default pattern installation
Hello, i am fascinated on MicroOS and on the concept of transactional-update, this got 1000% of the juice of the concept of hier on Linux/GNULinux. Now i am creating this thread to see if is possible the devs do the next change on the images: On my opinion these packages need to be installed on the podman mode of microOS: - Apparmor pattern - the selection of packages are incomplete: - Packages Installed * apparmor-parser * apparmor-profiles * patterns-microOS-apparmor - Packages Not-Installed (but have to be installed by defaul) * apparmor-utils (the most basic one and is not installed). This package bring the apparmor control of the rules, i have a podman rootfless and the php-fpm pod is not working because i cant change the profile of this app. * apparmor-docs - Yast2 - Packages need to come by default * yast2-storage-ng * yast2-apparmor - Firewall - Packages that need come by defaul * firewalld - transactional-updates - Packages that must come installed by default * inotify-tools (how a module is out but not bring the dependencies, if this package is not install --do-not-change wont work) - Others packages * git * man * wget * docker and that's my opinion. thank you for the hard work
On Fri, 2021-02-26 at 23:41 +0000, Walddys Emmanuel Dorrejo Céspedes wrote:
Hello,
Hey, Hi! BTW, should this discussion be moved to the Kubic mailing list? That's usually where we talk about things like these.
i am fascinated on MicroOS and on the concept of transactional- update, this got 1000% of the juice of the concept of hier on Linux/GNULinux.
Yep, I think that too. :-)
Now i am creating this thread to see if is possible the devs do the next change on the images:
On my opinion these packages need to be installed on the podman mode of microOS:
In fact, I wanted to ask abut what kind of flavor of MicroOS you are interested in and proposing changes to. Since you say "the podman mode", I think you mean the MicroOS Container Host?
- Apparmor pattern - the selection of packages are incomplete:
- Packages Not-Installed (but have to be installed by defaul) * apparmor-utils (the most basic one and is not installed). This package bring the apparmor control of the rules, i have a podman rootfless and the php-fpm pod is not working because i cant change the profile of this app.
Mmm... not an apparmor user or experts, so I don't know.
* apparmor-docs
Well, the're no doc whatsoever in MicroOS (we even remove the doc files from package that we install). Why don't you install this and keep it in a (user) toolbox ?
- Yast2 - Packages need to come by default * yast2-storage-ng * yast2-apparmor Mmm... that's also not something that I see very likely to be added to MicroOS by default.
- Firewall - Packages that need come by defaul * firewalld This one, I definitely want to propose it as an addition to the desktop patterns. I'm not sure about the container host one, although...
- transactional-updates - Packages that must come installed by default * inotify-tools (how a module is out but not bring the dependencies, if this package is not install --do-not-change wont work)
- Others packages * git * man * wget * docker Mmm... maybe wget. git and man (especially git), use a toolbox for
Yes, this is something I also think it really should be there. those. It's _literally_ the reason why we have one. $ toolbox -u # or `toolbox enter`, if you have a recent enough # version of the package $> sudo zyppeer install git-core <...> <...> Regards -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <<This happens because _I_ choose it to happen!>> (Raistlin Majere)
Hello, Dario thanks for the quick opinion, before i continue with my opinion, how can i change of mail-list an existing thread?
On 27/02/2021 06.15, Walddys Emmanuel Dorrejo Céspedes wrote:
Hello, Dario thanks for the quick opinion, before i continue with my opinion, how can i change of mail-list an existing thread?
You can not. You have to: - subscribe there, if not yet subscribed - start a new thread there. - or, in one of the posts here, you add a "reply-to" header set to the other mail list - or, you forward the first mail to the other mail list. - you could also post one of the emails to both lists (crosspost), but very probably the thread will then continue on both lists. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Hi, On Fri, Feb 26, Walddys Emmanuel Dorrejo Céspedes wrote:
Hello, i am fascinated on MicroOS and on the concept of transactional-update, this got 1000% of the juice of the concept of hier on Linux/GNULinux.
Now i am creating this thread to see if is possible the devs do the next change on the images:
On my opinion these packages need to be installed on the podman mode of microOS:
I will answer from the "Container Host" System Role view, not the plain MicroOS or MicroOS Desktop view.
- Apparmor pattern - the selection of packages are incomplete:
- Packages Installed * apparmor-parser * apparmor-profiles * patterns-microOS-apparmor
We are running our workload as Container and thus use SELinux, not AppArmor.
- Packages Not-Installed (but have to be installed by defaul) * apparmor-utils (the most basic one and is not installed). This package bring the apparmor control of the rules, i have a podman rootfless and the php-fpm pod is not working because i cant change the profile of this app. * apparmor-docs
Since we use SELinux we don't need them.
- Yast2
- Packages need to come by default * yast2-storage-ng * yast2-apparmor
MicroOS does not use YaST as local system management tool, as most modules don't work on a read-only root filesystem. We have/are working on Cockpit.
- Firewall - Packages that need come by defaul * firewalld
Firewall and container together is a really bad idea. Since the container runtime and firewalld are using iptables, there are very fast conflicts and either the one or the other get's broken. Better be careful on which services you run and which ports are open. If there are no open ports, you need no firewall. And if there are only open ports you would open in the firewall anyways, the firewall does not help, too. Don't forget: workloads are running in container, and if there is something opening a port you don't want, the container runtime will hide this port from outside.
- transactional-updates - Packages that must come installed by default * inotify-tools (how a module is out but not bring the dependencies, if this package is not install --do-not-change wont work)
If there are wrong dependencies, please open a bug.
- Others packages * git
What's the usecase? But you could also put that into a container.
* man
We have no docu, else: "busybox man"
* wget
MicroOS should be as small as possible. So as something requires already curl, we are using curl and not wget. Else there is still "busybox wget".
* docker
We are using podman. Thorsten
and that's my opinion.
thank you for the hard work
-- 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)
I will answer from the "Container Host" System Role view, not the plain MicroOS or MicroOS Desktop view.
We are running our workload as Container and thus use SELinux, not AppArmor. Ok, but on default MicroOS Container Host system role, the pattern AppArmor is selected by default.
Packages installed by default of the pattern AppArmor: - Apparmor-abstraction - Apparmor-parser - Apparmor-profiles - libapparmor1 But one of the more important packages, Apparmor-utils is not selected by default, which bring aa-logprof to watch and set the permission of a restrain app or packages, aa-complain to change from enforce to complain mode on a command/packages, and so on.
MicroOS does not use YaST as local system management tool, as most modules don't work on a read-only root filesystem.
We have/are working on Cockpit.
At least yast2-storage-ng can be use, because only modify /etc/fstab and can be use to internally manage LVM partition. "the user will/have to learn that modifying the read-only partition will break the system."
Firewall and container together is a really bad idea. Since the container runtime and firewalld are using iptables, there are very fast conflicts and either the one or the other get's broken. Better be careful on which services you run and which ports are open. If there are no open ports, you need no firewall. And if there are only open ports you would open in the firewall anyways, the firewall does not help, too. Don't forget: workloads are running in container, and if there is something opening a port you don't want, the container runtime will hide this port from outside.
i am not a some advance user to manages IPTABLES, i always use firewalld or susefirewall (on it's time), i change ssh default port, so have i to open the port manually with iptables?, because i dont see any ssh rules on the iptables.
- transactional-updates - Packages that must come installed by default * inotify-tools (how a module is out but not bring the dependencies, if this package is not install --do-not-change wont work) If there are wrong dependencies, please open a bug.
- Others packages * git
What's the usecase? But you could also put that into a container.
good point.
* man
We have no docu, else: "busybox man"
what do you mean with "busybox man"?
* wget
MicroOS should be as small as possible. So as something requires already curl, we are using curl and not wget. Else there is still "busybox wget".
what bring this busybox? and where is documented more about of the hidden capabilites of microOS?
* docker We are using podman.
i know we are using podman, but since microOS haven't update to podman 3.0 and podman-compose, i am a little limited to this.
On 3/1/21 1:38 AM, Walddys Emmanuel Dorrejo Céspedes wrote:
I will answer from the "Container Host" System Role view, not the
* man
We have no docu, else: "busybox man"
what do you mean with "busybox man"?
* wget
MicroOS should be as small as possible. So as something requires already curl, we are using curl and not wget. Else there is still "busybox wget".
what bring this busybox? and where is documented more about of the hidden capabilites of microOS?
Busybox https://busybox.net/ is a binary we ship that has reimplementations of a large number of commands, that are useful for debugging, diagnosing and recovering systems when something goes wrong, generally its provided as one static binary which is far more efficient then shipping say each of the GNU binaries as such it has been very popular in the embedded world where many Embedded linux systems will just ship busybox. These days it should be shipped on all Tumbleweed / Leap systems and you can see the available commands by running "busybox-static --help" It should be noted that sometimes some of the more advanced features of some commands aren't always supported. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
MicroOS does not use YaST as local system management tool, as most modules don't work on a read-only root filesystem.
We have/are working on Cockpit.
At least yast2-storage-ng can be use, because only modify /etc/fstab and can be use to internally manage LVM partition. "the user will/have to learn that modifying the read-only partition will break the system." I have not tried, but my gut feelings tell me that using the YaST Partitioner in a transactional system will result in some things working
On 2/28/21 4:08 PM, Walddys Emmanuel Dorrejo Céspedes wrote: perfectly and others not working at all, with every Partitioner operation being in a different point of that spectrum. If that's the case, including it in MicroOS would be more confusing than helpful. Not to mention the dependencies yast2-storage-ng would drag in (specially Ruby). Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions
On Fri, Mar 5, 2021 at 9:26 AM Ancor Gonzalez Sosa <ancor@suse.de> wrote:
MicroOS does not use YaST as local system management tool, as most modules don't work on a read-only root filesystem.
We have/are working on Cockpit.
At least yast2-storage-ng can be use, because only modify /etc/fstab and can be use to internally manage LVM partition. "the user will/have to learn that modifying the read-only partition will break the system." I have not tried, but my gut feelings tell me that using the YaST Partitioner in a transactional system will result in some things working
On 2/28/21 4:08 PM, Walddys Emmanuel Dorrejo Céspedes wrote: perfectly and others not working at all, with every Partitioner operation being in a different point of that spectrum. If that's the case, including it in MicroOS would be more confusing than helpful.
Not to mention the dependencies yast2-storage-ng would drag in (specially Ruby).
It makes sense to focus on improving Cockpit, as the individual MicroOS nodes can avoid interpreter runtimes and such. That gives us updates management (through PackageKit with my txnupd plugin for the DNF backend), storage management (through UDisks2), network management (through NetworkManager), service management and logging (through systemd), simple container management (through Podman), and the ability to extend things with our own Cockpit modules later. -- 真実はいつも一つ！/ Always, there's only one truth!
participants (7)
-
Ancor Gonzalez Sosa -
Carlos E. R. -
Dario Faggioli -
Neal Gompa -
Simon Lees -
Thorsten Kukuk -
Walddys Emmanuel Dorrejo Céspedes