@coldboot you can install rpm’s, run files, edit config files, create config files it’s just not recommended… Have you used transactional-update shell (and all the other options?).
For example, I edit /etc/default/grub then run transactional-update grub.cfg (and reboot)?
I would recommend distrobox for compile/run…
A regular user with uid,gid=/>1000. My use case is network-related services; I use setfacl for access control on traditional systems, but it does not function on an immutable system.
The problems I’m having are: having to reboot after installing packages and missing custom rpms post install, changing the MAC at boot, and some sysctl values not remaining persistent. I don’t have access to MicroOS VM at the moment, but I’ll start a thread tomorrow.
@malcolmlewis Yes, I got it working to some extent, but I want normal users to be able to access particular mountpoints. I really liked MicroOS on a laptop; it’s a wonderful concept for office tasks.
I don’t mean this to be rude, but do you use anything that is unique about openSUSE? It seems like you spend a lot of effort turning it into Debian.
I moved to openSUSE primarily because it took a lot of what I was manually doing with Kubuntu out of the box, in a more sane way. (No more messing with fstab, btrfs handles everything I was bashing ext4 into doing, no more messing around with PPAs to get up to date packages, etc). So yeah, I get that you can do more or less anything with more or less any distro, but at the same time it just seems odd to basically undo so many of the choices of the distro you’re using to go with the defaults of another.
@coldboot from for example a flatpak application? If so install flatseal for tweaking…
Or do you have a specific example?
@malcolmlewis I require extra space in the directories /var, /var/log, and /var/log/audit. Some programs can fill up to 100GB of /var/log in a couple of hours. I don’t believe I can filter logs with rsyslog on an immutable system in order to purge the trash messages. I xz compress the logs, move them to another directory, and then upload audit, httpd, and wtmp to the cloud storage. I’ll deploy MicroOS on OVH for testing this week and see how it goes.
@malcolmlewis Yes, they are comparable. I must have overlooked the disk setup before to installing MicroOS. Need to run MicroOS on a dedicated server and keep an eye on things for about a week. I’ll assess the system’s suitability for use in light of various Open SCAP standards (I follow this profile Guide to the Secure Configuration of Red Hat Enterprise Linux 9).
@coldboot I used cockpit storage to add… but yes, the installer should give those options…
I suspect there may be some combustion foo as well to tweak…
@malcolmlewis Separate mount points should be allowed for /home, /srv, /opt, /usr, /usr/local, /var, /var/log, /var/log/audit, and /var/tmp. I attempted to create those during the virsh installation, but the system became unbootable. There would be no problem with the remaining compliance.
My preferred setup -
/dev/mapper/cr_root on / type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/mapper/cr_usr on /usr type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/sdd3 on /boot type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/sdd2 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
/dev/mapper/cr_var on /var type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/mapper/cr_usr_local on /usr/local type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/mapper/cr_var_log on /var/log type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/mapper/cr_srv on /srv type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/mapper/cr_tmp on /tmp type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/mapper/cr_home on /home type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/mapper/cr_var_log_audit on /var/log/audit type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/mapper/cr_opt on /opt type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/mapper/cr_var_tmp on /var/tmp type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/mapper/DATA on /home/tangent/DATA type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/mapper/DEVEL on /home/DEVEL type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
I cannot speak to what the various versions of MicroOS Server allow or don’t allow, as far as filesystems or mounting points. I can say, without exception that / has to be btrfs, or there is no MicroOS, it’s a fundamental building block of the whole immutable system.
Aeon and Kalpa are a different story. At least with the current installation images, you can if you wish, go in and do whatever screwy custom partitioning and filesystems you wish, with the simple fact that / must still be btrfs. But whether it works or is stable or not, we neither guarantee, or support, because we don’t test for it, and have no intention of doing so.
Aeon and Kalpa, as offered, are intended for desktop use, not mixed use.
You can certainly modify the immutable base, in whatever manner you choose and try and make it behave more like Leap/Tumbleweed, but if you’re just going to do that, why you wouldn’t continue to just use Leap or Tumbleweed is beyond me.
I would expect as a ‘server’ or ‘self install image/iso’ for you to run everything you need in containers…
Perhaps a peruse here may help clarify? https://documentation.suse.com/alp/micro/html/alp-micro/concept-alp-deployment.html
There is. There was a call for contributors on the mailing list some time ago for building the new Leap. Things are not clear yet, but there is initiative and experiments are starting to take a shape.
Please, read openSUSE:ALP - openSUSE Wiki for more info and consider joining the matrix room if you’re interested in the development of the project!
Edit: openSUSE:ALP/ArchitectureTeam - openSUSE Wiki for the experimental projects!
@sfalken I’m making an effort to embrace the ALP concept and be ready in case Leap is discontinued. For certain of my clients, I believe I can deploy an immutable system on a modest VPS while determining its scope and restrictions.
@malcolmlewis Right now I’m installing D-Installer-Live.Aarch64-0.8.3-ALP-Build11.1.iso from https://download.opensuse.org/repositories/SUSE:/ALP:/Products:/Installer:/0.8/images/iso.iso.
Hoping we don’t kill our old-CentOS. Right now, we are the only long term path to enterprise Linux left.
To kill openSUSE is to kill SLE. We don’t need to be “Red Hat”.
(otherwise enterprise Linux is dead… perhaps it needs to die??)
SLE doesn’t release their source code to the public either. Redhat just followed their suit.
@asdhio It’s always been there in a source repo or via request (and still is);
https://www.suse.com/source-code/
Just curious, are there any 1:1 derivatives of SLE, like Alma Linux or Rocky Linux is to Red Hat (or used to be)?
