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.