admin: Add an `unlock` command, and libostree API
I'm trying to improve the developer experience on OSTree-managed
systems, and I had an epiphany the other day - there's no reason we
have to be absolutely against mutating the current rootfs live. The
key should be making it easy to rollback/reset to a known good state.
I see this command as useful for two related but distinct workflows:
- `ostree admin unlock` will assume you're doing "development". The
semantics hare are that we mount an overlayfs on `/usr`, but the
overlay data is in `/var/tmp`, and is thus discarded on reboot.
- `ostree admin unlock --hotfix` first clones your current deployment,
then creates an overlayfs over `/usr` persistent
to this deployment. Persistent in that now the initramfs switchroot
tool knows how to mount it as well. In this model, if you want
to discard the hotfix, at the moment you roll back/reboot into
the clone.
Note originally, I tried using `rofiles-fuse` over `/usr` for this,
but then everything immediately explodes because the default (at least
CentOS 7) SELinux policy denies tons of things (including `sshd_t`
access to `fusefs_t`). Sigh.
So the switch to `overlayfs` came after experimentation. It still
seems to have some issues...specifically `unix_chkpwd` is broken,
possibly because it's setuid? Basically I can't ssh in anymore.
But I *can* `rpm -Uvh strace.rpm` which is handy.
NOTE: I haven't tested the hotfix path fully yet, specifically
the initramfs bits.
2016-03-18 22:32:58 +03:00
<?xml version='1.0'?> <!-- * - nxml - * -->
< !DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!--
Copyright 2016 Colin Walters <walters @ v e r b u m . o r g >
2018-01-30 22:26:26 +03:00
SPDX-License-Identifier: LGPL-2.0+
admin: Add an `unlock` command, and libostree API
I'm trying to improve the developer experience on OSTree-managed
systems, and I had an epiphany the other day - there's no reason we
have to be absolutely against mutating the current rootfs live. The
key should be making it easy to rollback/reset to a known good state.
I see this command as useful for two related but distinct workflows:
- `ostree admin unlock` will assume you're doing "development". The
semantics hare are that we mount an overlayfs on `/usr`, but the
overlay data is in `/var/tmp`, and is thus discarded on reboot.
- `ostree admin unlock --hotfix` first clones your current deployment,
then creates an overlayfs over `/usr` persistent
to this deployment. Persistent in that now the initramfs switchroot
tool knows how to mount it as well. In this model, if you want
to discard the hotfix, at the moment you roll back/reboot into
the clone.
Note originally, I tried using `rofiles-fuse` over `/usr` for this,
but then everything immediately explodes because the default (at least
CentOS 7) SELinux policy denies tons of things (including `sshd_t`
access to `fusefs_t`). Sigh.
So the switch to `overlayfs` came after experimentation. It still
seems to have some issues...specifically `unix_chkpwd` is broken,
possibly because it's setuid? Basically I can't ssh in anymore.
But I *can* `rpm -Uvh strace.rpm` which is handy.
NOTE: I haven't tested the hotfix path fully yet, specifically
the initramfs bits.
2016-03-18 22:32:58 +03:00
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
2021-12-07 04:20:55 +03:00
License along with this library. If not, see <https: / / w w w . g n u . o r g / l i c e n s e s /> .
admin: Add an `unlock` command, and libostree API
I'm trying to improve the developer experience on OSTree-managed
systems, and I had an epiphany the other day - there's no reason we
have to be absolutely against mutating the current rootfs live. The
key should be making it easy to rollback/reset to a known good state.
I see this command as useful for two related but distinct workflows:
- `ostree admin unlock` will assume you're doing "development". The
semantics hare are that we mount an overlayfs on `/usr`, but the
overlay data is in `/var/tmp`, and is thus discarded on reboot.
- `ostree admin unlock --hotfix` first clones your current deployment,
then creates an overlayfs over `/usr` persistent
to this deployment. Persistent in that now the initramfs switchroot
tool knows how to mount it as well. In this model, if you want
to discard the hotfix, at the moment you roll back/reboot into
the clone.
Note originally, I tried using `rofiles-fuse` over `/usr` for this,
but then everything immediately explodes because the default (at least
CentOS 7) SELinux policy denies tons of things (including `sshd_t`
access to `fusefs_t`). Sigh.
So the switch to `overlayfs` came after experimentation. It still
seems to have some issues...specifically `unix_chkpwd` is broken,
possibly because it's setuid? Basically I can't ssh in anymore.
But I *can* `rpm -Uvh strace.rpm` which is handy.
NOTE: I haven't tested the hotfix path fully yet, specifically
the initramfs bits.
2016-03-18 22:32:58 +03:00
-->
<refentry id= "ostree" >
<refentryinfo >
<title > ostree admin unlock</title>
<productname > OSTree</productname>
<authorgroup >
<author >
<contrib > Developer</contrib>
<firstname > Colin</firstname>
<surname > Walters</surname>
<email > walters@verbum.org</email>
</author>
</authorgroup>
</refentryinfo>
<refmeta >
<refentrytitle > ostree admin unlock</refentrytitle>
<manvolnum > 1</manvolnum>
</refmeta>
<refnamediv >
<refname > ostree-admin-unlock</refname>
<refpurpose > Prepare the current deployment for hotfix or development</refpurpose>
</refnamediv>
<refsynopsisdiv >
<cmdsynopsis >
<command > ostree admin unlock</command> <arg choice= "opt" rep= "repeat" > OPTIONS</arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1 >
<title > Description</title>
<para >
Remove the read-only bind mount on <literal > /usr</literal>
and replace it with a writable overlay filesystem. This
default invocation of "unlock" is intended for
development/testing purposes. All changes in the overlay
are lost on reboot. However, this command also supports
"hotfixes", see below.
</para>
</refsect1>
<refsect1 >
<title > Options</title>
<variablelist >
<varlistentry >
<term > <option > --hotfix</option> </term>
<listitem > <para > If this option is provided, the
current deployment will be cloned as a rollback
target. This option is intended for things like
emergency security updates to userspace components
such as <literal > sshd</literal> . The semantics here
differ from the default "development" unlock mode
in that reboots will retain any changes (which is what
you likely want for security hotfixes).
</para> </listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>