keremet/rpm-ostree
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

doc: More updates, note atomic status, flesh out tradeoffs

Browse Source
This commit is contained in:
Colin Walters 2014-11-01 10:33:39 -04:00
parent 9e6231407c
commit c5d3e9cb0a
3 changed files with 31 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@ -1,4 +1,4 @@
# rpm-ostree (`/usr/bin/atomic`)
# rpm-ostree, aka /usr/bin/atomic
An system to compose RPMs on a server side into an
[OSTree](https://wiki.gnome.org/Projects/OSTree)
repository, and a client side tool to perform updates.

14
doc/administrator-handbook.md
View File

@ -1,10 +1,15 @@
## Administering an rpm-ostree based system
At the moment, there are two primary commands to be familiar with on
At the moment, there are three primary commands to be familiar with on
an rpm-ostree based system. Remember that `atomic` is an alias for
`rpm-ostree`. The author tends to use the former on client systems,
and the latter on compose servers.
# atomic status
Will show you your deployments, in the order in which they will appear
in the bootloader. The `*` shows the currently booted deployment.
# atomic upgrade
Will perform a system upgrade, creating a *new* chroot, and set it as
@ -25,3 +30,10 @@ never touched, and is shared across upgrades.
At upgrade time, the process takes the *new default* `/etc`, and adds
your changes on top. This means that upgrades will receive new
default files in `/etc`, which is quite a critical feature.
## Operating system changes
* The RPM database is stored in `/usr/share/rpm`, and is immutable.
* A package [nss-altfiles](https://github.com/aperezdc/nss-altfiles) is required,
and the system password database is stored in `/usr/lib/passwd`. Similar
for the group database.

25
doc/background.md
View File

@ -8,7 +8,7 @@ to fall cleanly into one of two camps: package-based or image-based.
* + Highly dynamic, fast access to wide array of software
* + State management in `/etc` and `/var` is well understood
* + Can swap between major/minor system states (`apt-get upgrade` is similar to `apt-get dist-upgrade`)
* + Work on top of any filesystem or partition layout
* + Generally supports any filesystem or partition layout
* - As package set grows, testing becomes combinatorially more expensive
* - Live system mutation, no rollbacks
@ -20,22 +20,26 @@ to fall cleanly into one of two camps: package-based or image-based.
* - Many image systems have a read-only `/etc`, and writable partitions elsewhere
* - Must reboot for updates
* - Usually operate at block level, so require fixed partition layout and filesystem
* - Many use a "dual root" mode which wastes space and is inflexible
* - Often paired with a separate application mechanism, but misses out on things that aren't apps
* - Administrators still need to know content inside
## How RPM-OSTree provides a middle ground
rpm-ostree allows composing packages on a server, and clients can
replicate that state reliably. For example, if one adds a package on
the compose server, clients get it. If one removes a package, it's
rpm-ostree in its default mode feels more like image replication, but
the underlying architecture allows a lot of package-like flexibility.
In this default mode, packages are composed on a server, and clients
can replicate that state reliably. For example, if one adds a package
on the compose server, clients get it. If one removes a package, it's
also removed when clients upgrade.
One simple mental model for rpm-ostree is: imagine taking a set of
packages on the server side, install them to a chroot, then doing `git
commit` on the result. And imagine clients just `git pull -r` from
that. What OSTree to this picture is support for uid/gid, extended
attributes, handling of bootloader configuration, and merges of
`/etc`.
that. What OSTree adds to this picture is support for file uid/gid,
extended attributes, handling of bootloader configuration, and merges
of `/etc`.
To emphasize, replication is at a filesystem level - that means that
that things like SELinux labels and uid/gid mappings are assigned on
@ -51,7 +55,12 @@ Currently, rpm operates on a read-only mode on installed systems; it
is not possible to add or remove anything on the client. If this
matches your deployment scenario, rpm-ostree is a good choice.
Classic examples of this are fixed purpose server farms, "corporate
standard build" laptop/desktops.
standard build" laptop/desktops, and embedded devices.
Of course, one can pair it with a dynamic application mechanism such
as [Docker](https://www.docker.com/), and have a reliable base, with a
flexible application tool. This is the rationale behind
[Project Atomic](http://www.projectatomic.io/).
## Is it worth supporting composes both on client and server?