packaging
/
ostree
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs/related-projects: Tweak client side snapshot text, add casync 

The latter came up on the list.

Closes: #1086
Approved by: jlebon
This commit is contained in:
Colin Walters 2017-08-16 17:37:27 -04:00 committed by Atomic Bot
parent 6709aa83a8
commit ceeefa69f5
1 changed files with 44 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

59
docs/manual/related-projects.md
View File

@ -20,6 +20,11 @@ a tool to snapshot systems on the client side (dpkg/rpm + BTRFS/LVM),
or a tool to compose on a server and replicate (ChromiumOS, Clear or a tool to compose on a server and replicate (ChromiumOS, Clear
Linux). OSTree is flexible enough to do both. Linux). OSTree is flexible enough to do both.
Note that this section of the documentation is almost entirely
focused on the "ostree for host" model; the [flatpak](https://github.com/flatpak/flatpak/)
project uses libostree to store application data, distinct from the
host system management model.
## Combining dpkg/rpm + (BTRFS/LVM) ## Combining dpkg/rpm + (BTRFS/LVM)
In this approach, one uses a block/filesystem snapshot tool underneath In this approach, one uses a block/filesystem snapshot tool underneath
@ -58,25 +63,26 @@ well.
In general, if one really tries to flesh out the BTRFS approach, a In general, if one really tries to flesh out the BTRFS approach, a
nontrivial middle layer of code between dpkg/rpm and BTRFS (or deep nontrivial middle layer of code between dpkg/rpm and BTRFS (or deep
awareness of BTRFS in dpkg/rpm itself) will be required. awareness of BTRFS in dpkg/rpm itself) will be required. A good
example of this is the [snapper.io](http://snapper.io/) project.
The OSTree author believes that having total freedom at the block The OSTree author believes that having total freedom at the block
storage layer is better for general purpose operating systems. For storage layer is better for general purpose operating systems. For
example, with OSTree, one is free to use BTRFS in any way you like - example, the ability to choose dm-crypt per deployment is quite useful;
you may decide to use a subvolume for `/home`, or not. not every site wants to pay the performance penalty. One can choose
LVM or not, etc.
Furthermore, in its most basic incarnation, the rpm/dpkg + BTRFS Where applicable, OSTree does take advantage of copy-on-write/reflink
doesn't solve the race conditions that happen when unpacking packages features offered by the kernel for `/etc`. It uses the now generic
into the live system, such as deleting the files underneath Firefox `ioctl(FICLONE)` and `copy_file_range()`.
while it's running. One could unpack packages into a separate root,
and switch to that, which gets closer to the OSTree architecture.
Note though OSTree does take advantage of BTRFS if installed on top of Another major distinction between the default OSTree usage and package managers
it! In particular, it will use reflink for the copies of `/etc` if is whether updates are "online" or "offline" by default. The default OSTree
available. design writes updates into a new root, leaving the running system unchanged.
This means preparing updates is completely non-disruptive and safe - if the
All of the above also applies if one replaces "BTRFS" with "LVM system runs out of disk space in the middle, it's easy to recover. However,
snapshots" except for the reflinks. there is work in the [rpm-ostree](https://github.com/projectatomic/rpm-ostree/)
project to support online updates as well.
OSTree supports using "bare-user" repositories, which do not require OSTree supports using "bare-user" repositories, which do not require
root to use. Using a filesystem-level layer without root is more root to use. Using a filesystem-level layer without root is more
@ -134,6 +140,29 @@ believes that at the moment, the "CL updater" is not truly atomic in
the sense that because it applies updates live, there is a window the sense that because it applies updates live, there is a window
where the OS root may be inconsistent. where the OS root may be inconsistent.
## casync
The [systemd casync](https://github.com/systemd/casync) project is
relatively new. Currently, it is more of a storage library, and doesn't
support higher level logic for things like GPG signatures, versioning
information, etc. This is mostly the `OstreeRepo` layer. Moving up to
the `OstreeSysroot` level - things like managing the bootloader
configuration, and most importantly implementing correct merging for `/etc`
are missing. casync also is unaware of SELinux.
OSTree is really today a shared library, and has been for quite some time.
This has made it easy to build higher level projects such as
[rpm-ostree](https://github.com/projectatomic/rpm-ostree/) which has quite
a bit more, such as a DBus API and other projects consume that, such as
[Cockpit](http://cockpit-project.org/).
A major issue with casync today is that it doesn't support garbage collection
on the server side. OSTree's GC works symmetrically on the server and client
side.
Broadly speaking, casync is a twist on the dual partition approach, and
shares the general purpose disadvantages of those.
## Mender.io ## Mender.io
[Mender.io](https://mender.io/) is another implementation of the dual [Mender.io](https://mender.io/) is another implementation of the dual