[opensuse-factory] Convert from classic to transactional server?
Hi, When installing openSUSE (any flavour), the installer offers a choice between the "server" and "transactional server" roles, among others. If I choose to install using the "server" role, is there a (supported) procedure by which I can later convert it into a "transactional server"? (Assume using btrfs for /, and having snapshots.) I tried to do this conversion on a test system running openSUSE Leap 15.2 as follows: * run "zypper install patterns-base-transactional_base" * edit /etc/fstab to make root read-only * reboot This appears to work: The system self-updates, and reboots when needed; /etc has been turned into an overlay filesystem; and zypper up tells me to use the transactional-update tool. However, one of the packages installed during the conversion is "read- only-root-fs", and its description contains a rather stern warning: Files, scripts and directories to run the system with a read-only root filesystem with /etc writeable via overlayfs. This package should never be installed in an already running system! It should only be selected by a system role for a read-only root filesystem with transactional updates. The package will create / modify entries for mounting /etc and /var. Those entries are used by dracut to mount the overlay file systems during the early boot phase. After reading this, I ask myself, was it just dumb luck that the test system wasn't destroyed during the conversion? What can/does go wrong if read-only-root-fs is installed in an already running system, against the advice given? Any clarification on this would be much appreciated. Regards, Olav -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2020-08-15 08:43, seroton10@gmail.com wrote:
Hi,
When installing openSUSE (any flavour), the installer offers a choice between the "server" and "transactional server" roles, among others.
If I choose to install using the "server" role, is there a (supported) procedure by which I can later convert it into a "transactional server"? (Assume using btrfs for /, and having snapshots.)
I tried to do this conversion on a test system running openSUSE Leap 15.2 as follows:
* run "zypper install patterns-base-transactional_base" * edit /etc/fstab to make root read-only * reboot
This appears to work: The system self-updates, and reboots when needed; /etc has been turned into an overlay filesystem; and zypper up tells me to use the transactional-update tool.
However, one of the packages installed during the conversion is "read- only-root-fs", and its description contains a rather stern warning:
Files, scripts and directories to run the system with a read-only root filesystem with /etc writeable via overlayfs.
This package should never be installed in an already running system! It should only be selected by a system role for a read-only root filesystem with transactional updates. The package will create / modify entries for mounting /etc and /var. Those entries are used by dracut to mount the overlay file systems during the early boot phase.
After reading this, I ask myself, was it just dumb luck that the test system wasn't destroyed during the conversion? What can/does go wrong if read-only-root-fs is installed in an already running system, against the advice given?
Any clarification on this would be much appreciated.
I think it was mostly dumb luck. There are some pretty invasive changes to your system done by that package eg. https://github.com/openSUSE/read-only-root-fs/blob/master/usr/sbin/setup-fst... There are also additional layers of configuration done by the system role you have probably neglected, such as marking the read-only property on the btrfs / subvolume (the fstab is too easily overriden to be the only way to mark your root read-only). The server system role also has a significantly different partitioning configuration from the transactional server one. Server requires 5GB or 17.5GB if btrfs with snapshots. Snapshots will be auto disabled if system does not have a large enough partition. Transactional Server requires 20GB. btrfs w. Snapshots are mandatory Transactional Server has /boot/writable subvolume for Ignition, regular Server does not. I think you got rather lucky to have a working system after your experiments :) Congratulations -- Richard Brown Linux Distribution Engineer - Future Technology Team SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Olav, Am 15.08.20 um 08:43 Uhr schrieb seroton10@gmail.com:
Hi,
When installing openSUSE (any flavour), the installer offers a choice between the "server" and "transactional server" roles, among others.
If I choose to install using the "server" role, is there a (supported) procedure by which I can later convert it into a "transactional server"? (Assume using btrfs for /, and having snapshots.)
No, this is unsupported - see Richards mail for the differences between the roles.
I tried to do this conversion on a test system running openSUSE Leap 15.2 as follows:
* run "zypper install patterns-base-transactional_base" * edit /etc/fstab to make root read-only * reboot
This appears to work: The system self-updates, and reboots when needed; /etc has been turned into an overlay filesystem; and zypper up tells me to use the transactional-update tool.
However, one of the packages installed during the conversion is "read- only-root-fs", and its description contains a rather stern warning:
Files, scripts and directories to run the system with a read-only root filesystem with /etc writeable via overlayfs.
This package should never be installed in an already running system! It should only be selected by a system role for a read-only root filesystem with transactional updates. The package will create / modify entries for mounting /etc and /var. Those entries are used by dracut to mount the overlay file systems during the early boot phase.
After reading this, I ask myself, was it just dumb luck that the test system wasn't destroyed during the conversion? What can/does go wrong if read-only-root-fs is installed in an already running system, against the advice given?
Any clarification on this would be much appreciated.
I was also quite surprised to see this approach working - I would have expected that at least the /etc overlays would be falling apart. So I just checked the read-only-root-fs spec file. The necessary directories will be created there even on an existing system, so you may indeed have created a working setup ;-) HOWEVER: The warning is imho completely legitimate. Installing this package will not magically convert an existing read-write system into a read-only system, but will require manual interaction. In fact you missed one important step: The root subvolume should also be set read-only (i.e. not only setting the read-only flag in fstab but by calling `btrfs property set / ro true`). You may have to mount the root file system rw again for this operation to succeed, or call it directly on the snapshot directory in /.snapshots/xxx/snapshot). Cheers, Ignaz -- Ignaz Forster <iforster@suse.com> Research Engineer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Ignaz, and Richard, On Fri, 2020-08-21 at 09:48 +0200, Ignaz Forster wrote:
Hi Olav,
Am 15.08.20 um 08:43 Uhr schrieb seroton10@gmail.com:
Hi,
When installing openSUSE (any flavour), the installer offers a choice between the "server" and "transactional server" roles, among others.
If I choose to install using the "server" role, is there a (supported) procedure by which I can later convert it into a "transactional server"? (Assume using btrfs for /, and having snapshots.)
No, this is unsupported - see Richards mail for the differences between the roles.
[cut] Any clarification on this would be much appreciated.
I was also quite surprised to see this approach working - I would have expected that at least the /etc overlays would be falling apart.
So I just checked the read-only-root-fs spec file. The necessary directories will be created there even on an existing system, so you may indeed have created a working setup ;-)
HOWEVER: The warning is imho completely legitimate. Installing this package will not magically convert an existing read-write system into a read-only system, but will require manual interaction. In fact you missed one important step: The root subvolume should also be set read-only (i.e. not only setting the read-only flag in fstab but by calling `btrfs property set / ro true`). You may have to mount the root file system rw again for this operation to succeed, or call it directly on the snapshot directory in /.snapshots/xxx/snapshot).
I never got back to thank you guys for your responses, but I'd like to add that to the record now. For your information: After applying the btrfs read-only property manually, as suggested, I just left the machine (a Raspberry Pi 3) running. It is still running just fine, after having been powered on non-stop for 6 months. By "just fine" I mean I can do SSH login to it, and nothing seems to be exploding - not disk usage, not the overlay hierarchy, etc. I would also like to add that I think it would be a very cool feature to be able to enable transactional updates on an openSUSE system that was not installed with the transactional server role. Providing that a certain set of minimum requirements are met, of course. Even if such a retrofitted system is not identical to a real transactional server, and maybe doesn't support all its features, from my experience it still seems like a very useful thing to be able to do. IMHO. Again, thank you for your feedback. Regards, Olav
On Sat, Feb 27, 2021, at 23:23, Olav Reinert wrote:
Hi Ignaz, and Richard,
On Fri, 2020-08-21 at 09:48 +0200, Ignaz Forster wrote:
Hi Olav,
Am 15.08.20 um 08:43 Uhr schrieb seroton10@gmail.com:
Hi,
When installing openSUSE (any flavour), the installer offers a choice between the "server" and "transactional server" roles, among others.
If I choose to install using the "server" role, is there a (supported) procedure by which I can later convert it into a "transactional server"? (Assume using btrfs for /, and having snapshots.)
No, this is unsupported - see Richards mail for the differences between the roles.
[cut] Any clarification on this would be much appreciated.
I was also quite surprised to see this approach working - I would have expected that at least the /etc overlays would be falling apart.
So I just checked the read-only-root-fs spec file. The necessary directories will be created there even on an existing system, so you may indeed have created a working setup ;-)
HOWEVER: The warning is imho completely legitimate. Installing this package will not magically convert an existing read-write system into a read-only system, but will require manual interaction. In fact you missed one important step: The root subvolume should also be set read-only (i.e. not only setting the read-only flag in fstab but by calling `btrfs property set / ro true`). You may have to mount the root file system rw again for this operation to succeed, or call it directly on the snapshot directory in /.snapshots/xxx/snapshot).
I never got back to thank you guys for your responses, but I'd like to add that to the record now.
For your information: After applying the btrfs read-only property manually, as suggested, I just left the machine (a Raspberry Pi 3) running. It is still running just fine, after having been powered on non-stop for 6 months. By "just fine" I mean I can do SSH login to it, and nothing seems to be exploding - not disk usage, not the overlay hierarchy, etc.
One of the nice things of MicroOS and transactional-update is the automatic upgrades. Where the server reboots by itself and performs the upgrade. Which should be a few days a week. Having an uptime of 6 months makes me think something is not working right. A mutable OS like TW or Leap can be upgraded usually without a reboot. An immutable OS like MicroOS can only upgrade with a reboot, as the /root is read only. /Syds
I would also like to add that I think it would be a very cool feature to be able to enable transactional updates on an openSUSE system that was not installed with the transactional server role. Providing that a certain set of minimum requirements are met, of course. Even if such a retrofitted system is not identical to a real transactional server, and maybe doesn't support all its features, from my experience it still seems like a very useful thing to be able to do. IMHO.
Again, thank you for your feedback.
Regards, Olav
On Sun, 2021-02-28 at 09:41 +0100, Syds Bearda wrote:
On Sat, Feb 27, 2021, at 23:23, Olav Reinert wrote:
For your information: After applying the btrfs read-only property manually, as suggested, I just left the machine (a Raspberry Pi 3) running. It is still running just fine, after having been powered on non-stop for 6 months. By "just fine" I mean I can do SSH login to it, and nothing seems to be exploding - not disk usage, not the overlay hierarchy, etc.
One of the nice things of MicroOS and transactional-update is the automatic upgrades. Where the server reboots by itself and performs the upgrade. Which should be a few days a week. Having an uptime of 6 months makes me think something is not working right.
I didn't say anything about uptime, only that the machine has been powered on and running for 6 months.
A mutable OS like TW or Leap can be upgraded usually without a reboot. An immutable OS like MicroOS can only upgrade with a reboot, as the /root is read only.
In fact, uptime on this RasPi3 is rarely more than a few days because it is self-upgrading and rebooting regularly, as evidenced by /var/log/transactional-update.log, among other things. Regards, Olav
-- Bearda Financial Services opensuse@syds.eu On Sun, Feb 28, 2021, at 11:12, Olav Reinert wrote:
On Sun, 2021-02-28 at 09:41 +0100, Syds Bearda wrote:
On Sat, Feb 27, 2021, at 23:23, Olav Reinert wrote:
For your information: After applying the btrfs read-only property manually, as suggested, I just left the machine (a Raspberry Pi 3) running. It is still running just fine, after having been powered on non-stop for 6 months. By "just fine" I mean I can do SSH login to it, and nothing seems to be exploding - not disk usage, not the overlay hierarchy, etc.
One of the nice things of MicroOS and transactional-update is the automatic upgrades. Where the server reboots by itself and performs the upgrade. Which should be a few days a week. Having an uptime of 6 months makes me think something is not working right.
I didn't say anything about uptime, only that the machine has been powered on and running for 6 months.
A mutable OS like TW or Leap can be upgraded usually without a reboot. An immutable OS like MicroOS can only upgrade with a reboot, as the /root is read only.
In fact, uptime on this RasPi3 is rarely more than a few days because it is self-upgrading and rebooting regularly, as evidenced by /var/log/transactional-update.log, among other things.
Oh perfect I understood you wrong then. Happy to hear it works as intended. /Syds
Regards, Olav
Am 2021-02-27 um 23:23 schrieb Olav Reinert:
[...] I would also like to add that I think it would be a very cool feature to be able to enable transactional updates on an openSUSE system that was not installed with the transactional server role. Providing that a certain set of minimum requirements are met, of course. Even if such a retrofitted system is not identical to a real transactional server, and maybe doesn't support all its features, from my experience it still seems like a very useful thing to be able to do. IMHO.
That's already possible by simply running the transactional-update features while being careful to not change the running system with zypper :) For example we use that - for fun and out of interest - on one of the machines within the openqa.opensuse.org infrastructure. Most machines there have a read-only root filesystem except for one but applying the updates and rebooting to activate the updated system is done in the same way on all machines.
participants (6)
-
Ignaz Forster -
Olav Reinert -
Oliver Kurz -
Richard Brown -
seroton10＠gmail.com
-
Syds Bearda