openSUSE Leap 16.1 offers Leap Micro's read-only root as an install-time option

Say an admin gets paged at night, logs into a Leap host and installs a diagnostic tool to see what broke. On a host installed in standard mode, that is an ordinary change ^[5]. On a host installed in Leap 16.1's immutable mode, the root filesystem is mounted read-only, and ZDNET says directories such as /usr and /etc cannot be altered ^[6]. The same read-only mount that would stop a malicious script run by accident ^[7] also stops the admin's direct install. Changes to the system have to go through transactional updates ^[1].

The pitch and the product are close together this time. The openSUSE blog described the mode with very little roadmap language: "This is essentially what our users know from Leap Micro, just integrated directly into Leap" ^[2]. Leap is openSUSE's stable release ^[11]. The product itself is one choice in the installer, standard or immutable ^[5]. ZDNET's account describes that choice only at installation and does not say whether a running standard system can be converted.

Teams adopting immutable hosts tend to tell themselves that their servers are rebuilt from a definition and that nobody logs in. During an incident, what people actually do is log in and change something. I'd expect Leap Immutable to roll out quietly where the first account is true. Where the second one is, I'd expect support tickets.

A second change sits under this one. openSUSE used AppArmor for mandatory access control through version 15.6 ^[8] and switched to SELinux starting with 16.0 ^[9]. According to ZDNET, SELinux labels every file, process and port, and holds even the root user to its rules ^[10]. A shop going straight from 15.6 to 16.1 changes its access-control system in that one upgrade. If it also picks immutable mode, the root filesystem changes too ^[1]. With both changes in one upgrade, an SELinux denial and a blocked write to a read-only directory can turn up in the same incident, and each needs a different fix.

To decide which hosts get it, I would use two axes. One is whether the host is rebuilt from a definition or maintained by hand. The other is whether someone can reach it quickly when it breaks.

Rebuilt and hard to reach covers the edge devices and container hosts the blog named ^[4], and those are the easy yes. Rebuilt and easy to reach is also a yes, and it costs little. Hand-maintained and hard to reach is where rollback helps most, but the hand edits have to move into transactional updates first. Hand-maintained and easy to reach covers the long-lived pet server and the developer's workstation, and those can stay in standard mode for now ^[5].

To place a host, count how many times last month someone changed its system files by hand. A count of zero puts it in the immutable column at its next install. Any other count gives you the list of changes to move into transactional updates before it switches.