This the multi-page printable view of this section. Click here to print.
Photon RPM OSTree: a simple guide
- 1: Introduction
- 2: Installing a host against default server repository
- 3: Concepts in Action
- 4: Querying For Commit File and Package Metadata
- 5: Host Updating Operations
- 6: Creating a Server
- 7: Installing a Photon RPM-OStree host against a custom server repository
- 8: Automatic Updates
- 9: File Oriented Server Operations
- 10: Package Oriented Server Operations
- 11: Remotes
- 12: Running container applications between bootable images
- 13: Install or rebase to Photon OS 3.0
1 - Introduction
RPM-OSTree Overview
OSTree is a tool to manage bootable, immutable, versioned filesystem trees. Unlike traditional package managers like rpm or dpkg that know how to install, uninstall, configure packages, OSTree has no knowledge of the relationship between files. But when you add rpm capabilities on top of OSTree, it becomes RPM-OSTree, meaning a filetree replication system that is also package-aware.
The idea behind it is to use a client/server architecture to keep your Linux installed machines (physical or VM) in sync with the latest bits, in a predictable and reliable manner. To achieve that, OSTree uses a git-like repository that records the changes to any file and replicate them to any subscriber.
A system administrator or an image builder developer takes a base Linux image, prepares the packages and other configuration on a server box, executes a command to compose a filetree that the host machines will download and then incrementally upgrade whenever a new change has been committed. You may read more about OSTree here.
Why use RPM-OSTree in Photon?
There are several important benefits:
- Reliable, efficient: The filetree replication is simple, reliable and efficient. It will only transfer deltas over the network. If you have deployed two almost identical bootable images on same box (differing just by several files), it will not take twice the space. The new tree will have a set of hardlinks to the old tree and only the different files will have a separate copy stored to disk.
- Atomic: the filetree replication is atomic. At the end of a deployment, you are either booting from one deployment, or the other. There is no “partial deployed bootable image”. If anything bad happens during replication or deployment- power loss, network failure, your machine boots from the old image. There is even a tool option to cleanup old deployed (successfully or not) image.
- Manageable: You are provided simple tools to figure out exactly what packages have been installed, to compare files, configuration and package changes between versions.
- Predictable, repeatable: A big headache for a system administrator is to maintain a farm of computers with different packages, files and configuration installed in different order, that will result in exponential set of test cases. With RPM-OStree, you get identical, predictable installed systems.
As drawbacks, I would mention:
- Some applications configured by user on host may have compatibility issues if they save configuration or download into read only directories like /usr.
- People not used with “read only” file systems will be disappointed that they could no longer use RPM, yum, tdnf to install whatever they want. Think of this as an “enterprise policy”. They may circumvent this by customizing the target directory to a writable directory like /var or using rpm to install packages and record them using a new RPM repository in a writable place.
- Administrators need to be aware about the directories re-mapping specific to OSTree and plan accordingly.
Photon with RPM-OSTree installation profiles
Photon takes advantage of RPM-OSTree and offers several installation choices:
- Photon RPM-OSTree server - used to compose customized Photon OS installations and to prepare updates. I will call it for short ‘server’.
- Photon RPM-OSTree host connected to a default online server repository via http or https, maintained by VMware Photon OS team, where future updates will be published. This will create a minimal installation profile, but with the option to self-upgrade. I will call it for short ‘default host’.
- Photon RPM-OSTree host connected to a custom server repository. It requires a Photon RPM-OSTree Server installed in advance. I will call it for short ‘custom host’.
Terminology
In this section, the term OSTree refers to the general use of this technology, the format of the repository or replication protocol.
The term RPM-OSTree emphasizes the layer that adds RedHat Package Manager compatibility on both ends - at server and at host. However, since Photon OS is an RPM-based Linux, there are places in the documentation and even in the installer menus where OSTree may be used instead of RPM-OSTree when the distinction is not obvious or does not matter in that context.
When ostree and rpm-ostree are encountered, they refer to the usage of the specific Unix commands.
Finally, Photon RPM-OSTree is the application or implementation of the RPM-OStree system into Photon OS, materialized into two options: Photon Server and Photon Host (or client). Server or Host may be used with or without the Photon and/or RPM-OStree qualifier, but it means the same thing.
Sample code
Codes samples used throughout the book are small commands that can be typed at shell command prompt and do not require downloading additional files. As an alternative, one can remote connect via ssh, so cut & paste sample code from outside sources or copy files via scp will work. See the Photon Administration guide to learn how to enable ssh. The samples assume that the following VMs have been installed - see the steps in the next chapters:
- A default host VM named photon-host-def.
- Two server VMs named photon-srv1 and photon-srv2.
- Two custom host VMs named photon-host-cus1 and photon-host-cus2, connected each to the corresponding server during install.
How to read this book
The RPM OSTree guide is structured to be used both as a sequential read and as a reference documentation.
If you are just interested in deploying a host system and keeping it up to date, then read Installing a Photon RPM-OSTree host against default server repository and Host updating operations.
If you want to install your own server and experiment with customizing packages for your Photon hosts, then read [Installing a Photon RPM-OSTree server](../creating-a-rpm-ostree-
server/) onwards. There are references to the concepts discussed throughout the book, if you need to understand them better.
However, if you want to read page by page, information is presented from simple to complex, although as with any technical book, we occasionally run into the chicken and egg problem - forward references to concepts that have yet to be explained later. In other cases, concepts are introduced and presented in great detail that may be seem hard to follow at first, but I promise they will make sense in the later pages when you get to use them.
RPM OSTree in Photon OS 3.0
This book is relevant to RPM OSTree in Photon OS 3.0.
Version 3.0 supports the following features:
- Upgrade
- Rollback
- Remote, compose, and rebase server
- Installation and uninstallation of packages with URL
- Installation and uninstallation of packages from default repos
- Automatic updates
2 - Installing a host against default server repository
RPM-OSTree Host default server repo installation option in Photon 3.0 will setup a profile similar to Photon Minimal, with the added benefit of being able to self-upgrade.
Who is this for?
The RPM-OSTree ‘default host’ is the easiest way to deploy a Photon RPM-OSTree host from ISO/cdrom, without the need to deploy and maintain an RPM-OSTree server. It is targeted at the user who relies on VMware Photon OS team to keep his or her system up-to-date, configured to get its updates from the official Photon 3.0 OSTree repository.
This is also the fastest way to install a host, as we’ve included in the ISO/cdrom an identical copy of the Photon 3.0 “starter” RPM-OSTree repository that is published online by VMware Photon OS team. So rather than pulling from the online repository, the installer pulls the repo from cdrom, which saves bandwidth and also reduces to zero the chances of failing due to a networking problem. After successful installation, any updates are going to be pulled from the official online repository, when Photon OS team will make them available.
Note: It is also possible to install an RPM-OSTree host against the official online repo via PXE boot, without the benefit of fast, local pull from cdrom. This will be covered in the PXE boot/kickstart chapter, as it requires additional configuration.
Installing the ISO
User will first download Photon OS ISO file that contains the installer, which is able to deploy any of the supported Photon installation profiles.
There are some steps common to all Photon installation profiles, starting with adding a VM in VMware Fusion, Workstation or ESXi, selecting the OS family, then customizing for disk size, CPU, memory size, network interface etc. (or leaving the defaults) and selecting the ISO image as cdrom. The installer will launch, that will go through disk partitioning and accepting the license agreement screens, followed by selecting an installation profile. These steps are described at the page linked below, so I won’t repeat them, just that instead of setting up a Photon Minimal profile, we will install a Photon OSTree host:
Running Project Photon on Fusion.
Select the Photon OSTree Host option.
Continue with setting up a host name like photon1-def and a root password, re-confirm. Then, select “Default OSTree Server” and continue.
When installation is over, the VM will reboot and will show in grub VMWare Photon/Linux 3.0_minimal (ostree), which will reassure that it’s booting from an OSTree image!
Boot, login and you are ready to use it.
To upgrade your host, see Host updating operations.
3 - Concepts in Action
Now that we have a fresh installed host (either as [[default|Photon-RPM-OSTree:-2-Installing-a-host-against-default-server-repository]] or [[custom|Photon-RPM-OSTree:-7-Installing-a-host-against-a-custom-server-repository]]), I can explain better the OStree concepts and see them in action.
Querying the deployed filetrees
The first thing to do is to run a command that tells us what is installed on the machine and when. Since it’s a fresh install from the CD, there is only one bootable filetree image deployed.
root@photon-host [ ~ ]# rpm-ostree status
* ostree://photon:photon/3.0/x86_64/minimal
Version: 3.0_minimal (2019-08-29T11:20:19Z)
Commit: a31a843985e314a9e70bcf09afe8d59f7351817d9fb743c2b6dab84f20833650
Bootable filetree version
3.0_minimal is not the Linux Photon OS release version, nor daily build, but rather a human readable, self-incrementing version associated with every commit that brings file/package updates. Think of this as version 0. The following versions are going to be 3.0_minimal.1, 3.0_minimal.2, 3.0_minimal.3 and so on.
Commit ID
The ID listed is actually the first 5 bytes (10 hex digits) of the commit hash. If you want to see the verbose mode, use the -v option.
root@photon-host [ ~ ]# rpm-ostree status -v
State: idle
AutomaticUpdates: disabled
Deployments:
* ostree://photon:photon/3.0/x86_64/minimal
Version: 3.0_minimal (2019-08-29T11:20:19Z)
Commit: a31a843985e314a9e70bcf09afe8d59f7351817d9fb743c2b6dab84f20833650
`- photon (2019-08-29T11:18:53Z)
Staged: no
StateRoot: photon
RPM OStree Options
To see the list of options available with the rpm-ostree command, use the -h option.
root@photon-host [ ~ ]# rpm-ostree -h
Usage:
rpm-ostree [OPTION?] COMMAND
Builtin Commands:
compose Commands to compose a tree
cleanup Clear cached/pending data
db Commands to query the RPM database
deploy Deploy a specific commit
rebase Switch to a different tree
rollback Revert to the previously booted tree
status Get the version of the booted system
upgrade Perform a system upgrade
reload Reload configuration
usroverlay Apply a transient overlayfs to /usr
cancel Cancel an active transaction
initramfs Enable or disable local initramfs regeneration
install Overlay additional packages
uninstall Remove overlayed additional packages
override Manage base package overrides
reset Remove all mutations
refresh-md Generate rpm repo metadata
kargs Query or modify kernel arguments
Help Options:
-h, --help Show help options
Application Options:
--version Print version information and exit
OSname
The OS Name identifies the operating system installed. All bootable filetrees for the same OS will share the /var directory, in other words applications installed in one booted image into this directory will be available in all other images.
If a new set of images are created for a different OS, they will receive a fresh copy of /var that is not shared with the previous OS images for the initial OS. In other words, if a machine is dual boot for different operating systems, they will not share each other’s /var content, however they will still merge 3-way /etc.
Refspec
The Refspec is a branch inside the repo, expressed in a hierarchical way. In this case, it’s the default branch that will receive package updates for the Photon OS 1.0 Minimal installation profile on Intel platforms. There could be other branches in the future, for example photon/3.0/x86_64/full that will match the Full installation profile (full set of packages installed).
Think of Refspec as the head of the minimal branch (just like in git) at the origin repo. On the replicated, local repo at the host, minimal is a file that contains the latest commit ID known for that branch.
root@photon-host [ ~ ]# cat /ostree/repo/refs/remotes/photon/photon/3.0/x86_64/minimal
a31a843985e314a9e70bcf09afe8d59f7351817d9fb743c2b6dab84f20833650
Why are there two ‘photon’ directory levels in the remotes path? The photon: prefix in the Refspec listed by rpm-ostree status corresponds to the first photon directory in the remotes path and is actually the name given to the remote that the host is connected to, which points to an http or https URL. We’ll talk about remotes later, but for now think of it as a namespace qualifier. The second photon is part of the Refspec path itself.
Deployments
We’ve used so far rpm-ostree. The same information can be obtained running an ostree command:
root@photon-host [ ~ ]# ostree admin status
* photon a31a843985e314a9e70bcf09afe8d59f7351817d9fb743c2b6dab84f20833650.0
Version: 3.0_minimal
origin refspec: photon:photon/3.0/x86_64/minimal
But where is this information stored? As you may have guessed, the local repo stores the heads of the deployed trees - the most recent commitment ID, just like Git does:
root@photon-host [ ~ ]# cat /ostree/repo/refs/heads/ostree/0/1/0
a31a843985e314a9e70bcf09afe8d59f7351817d9fb743c2b6dab84f20833650
This also where this command that lists the references (local heads and remotes) takes its data from:
root@photon-host [ ~ ]# ostree refs
ostree/0/1/0
photon:photon/3.0/x86_64/minimal
Based on that, it could find the root of the deployment that it boots from. The actual filetree is deployed right here:
root@photon-host [ ~ ]# ls -l /ostree/deploy/photon/deploy/a31a843985e314a9e70bcf09afe8d59f7351817d9fb743c2b6dab84f20833650.0
total 36
lrwxrwxrwx 2 root root 7 Sep 4 04:58 bin -> usr/bin
drwxr-xr-x 2 root root 4096 Jan 1 1970 boot
drwxr-xr-x 2 root root 4096 Jan 1 1970 dev
drwxr-xr-x 34 root root 4096 Sep 4 05:00 etc
lrwxrwxrwx 2 root root 8 Sep 4 04:58 home -> var/home
lrwxrwxrwx 3 root root 7 Sep 4 04:58 lib -> usr/lib
lrwxrwxrwx 3 root root 7 Sep 4 04:58 lib64 -> usr/lib
lrwxrwxrwx 2 root root 9 Sep 4 04:58 media -> run/media
lrwxrwxrwx 2 root root 7 Sep 4 04:58 mnt -> var/mnt
lrwxrwxrwx 2 root root 7 Sep 4 04:58 opt -> var/opt
lrwxrwxrwx 2 root root 14 Sep 4 04:58 ostree -> sysroot/ostree
drwxr-xr-x 2 root root 4096 Jan 1 1970 proc
lrwxrwxrwx 2 root root 12 Sep 4 04:58 root -> var/roothome
drwxr-xr-x 2 root root 4096 Jan 1 1970 run
lrwxrwxrwx 2 root root 8 Sep 4 04:58 sbin -> usr/sbin
lrwxrwxrwx 2 root root 7 Sep 4 04:58 srv -> var/srv
drwxr-xr-x 2 root root 4096 Jan 1 1970 sys
drwxr-xr-x 2 root root 4096 Jan 1 1970 sysroot
lrwxrwxrwx 2 root root 11 Sep 4 04:58 tmp -> sysroot/tmp
drwxr-xr-x 10 root root 4096 Jan 1 1970 usr
drwxr-xr-x 8 root root 4096 Sep 4 04:59 var
So how is a deployment linked to a specific branch, originating from a remote repo? Well, there is a file next to the deployed filetree root directory with the same name and .origin suffix, that contains exactly this info:
root@photon-host [ ~ ]# cat /ostree/deploy/photon/deploy/a31a843985e314a9e70bcf09afe8d59f7351817d9fb743c2b6dab84
f20833650.0.origin
[origin]
refspec=photon:photon/3.0/x86_64/minimal
Fast forwarding a bit, if there is a new deployment due to an upgrade or rebase, a new filetree will be added at the same level, and a new .origin file will tie it to the remote branch it originated from.
The photon directory in the path is the actual OSname. Multiple deployments of same OS will share a writable /var folder.
root@photon-host [ ~ ]# ls -l /ostree/deploy/photon/var/
total 52
drwxr-xr-x 4 root root 4096 Sep 4 05:00 cache
drwxr-xr-x 2 root root 4096 Sep 4 05:00 home
drwxr-xr-x 14 root root 4096 Sep 4 05:00 lib
drwxr-xr-x 2 root root 4096 Sep 4 05:00 local
lrwxrwxrwx 1 root root 11 Sep 4 04:59 lock -> ../run/lock
drwxr-xr-x 4 root root 4096 Sep 4 05:00 log
drwxr-xr-x 2 root root 4096 Sep 4 05:00 mail
drwxr-xr-x 2 root root 4096 Sep 4 05:00 mnt
drwxr-xr-x 4 root root 4096 Sep 4 05:00 opt
drwx------ 3 root root 4096 Sep 4 05:25 roothome
lrwxrwxrwx 1 root root 6 Sep 4 04:59 run -> ../run
drwxr-xr-x 2 root root 4096 Sep 4 05:00 spool
drwxr-xr-x 2 root root 4096 Sep 4 05:00 srv
drwxrwxrwt 5 root root 4096 Sep 4 05:34 tmp
drwxr-xr-x 11 root root 4096 Sep 4 05:00 usrlocal
4 - Querying For Commit File and Package Metadata
There are several ostree and rpm-ostree commands that list file or package data based on either the Commit ID, or Refspec. If Refspec is passed as a parameter, it’s the same as passing the most recent commit ID (head) for that branch.
Commit history
For a host that is freshly installed, there is only one commit in the history for the only branch.
root@photon-host [ ~ ]# ostree log photon/3.0/x86_64/minimal
commit a31a843985e314a9e70bcf09afe8d59f7351817d9fb743c2b6dab84f20833650
ContentChecksum: e91261daf8d60074f334a7ebf81d3b930c3fc88c765f994f79ab2445296f03c5
Date: 2019-08-29 11:20:19 +0000
Version: 3.0_minimal
This commit has no parent; if there was an older commit, it would have been listed too. We can get the same listing (either nicely formatted or raw variant data) by passing the Commit ID. Just the first several hex digits will suffice to identify the commit ID. We can either request to be displayed in a pretty format, or raw - the actual C struct.
root@photon-host [ ~ ]# ostree log a31a
commit a31a843985e314a9e70bcf09afe8d59f7351817d9fb743c2b6dab84f20833650
ContentChecksum: e91261daf8d60074f334a7ebf81d3b930c3fc88c765f994f79ab2445296f03c5
Date: 2019-08-29 11:20:19 +0000
Version: 3.0_minimal
root@photon-host [ ~ ]# ostree log a31a --raw
commit a31a843985e314a9e70bcf09afe8d59f7351817d9fb743c2b6dab84f20833650
({'rpmostree.inputhash': <'a3e8f3f6ef6e93c2ed6ce9edd1e9e80c93a36ecda0fed0d78f607e6ec3179d04'>, 'rpmostree.rpmmd-repos': <[{'id': <'photon'>, 'timestamp': <uint64 1567077533>}]>, 'version': <'3.0_minimal'>, 'rpmostree.rpmdb.pkglist': <[('Linux-PAM', '0', '1.3.0', '1.ph3', 'x86_64'), ('attr', '0', '2.4.48', '1.ph3', 'x86_64'), ('autogen-libopts', '0', '5.18.16', '1.ph3', 'x86_64'), ('bash', '0', '4.4.18', '1.ph3', 'x86_64'), ('bc', '0', '1.07.1', '1.ph3', 'x86_64'), ('binutils', '0', '2.31.1', '6.ph3', 'x86_64'), ('bridge-utils', '0', '1.6', '1.ph3', 'x86_64'), ('bubblewrap', '0', '0.3.0', '2.ph3', 'x86_64'), ('bzip2', '0', '1.0.6', '10.ph3', 'x86_64'), ('bzip2-libs', '0', '1.0.6', '10.ph3', 'x86_64'), ('ca-certificates', '0', '20190521', '1.ph3', 'x86_64'), ('ca-certificates-pki', '0', '20190521', '1.ph3', 'x86_64'), ('coreutils', '0', '8.30', '1.ph3', 'x86_64'), ('cpio', '0', '2.12', '4.ph3', 'x86_64'), ('cracklib', '0', '2.9.6', '8.ph3', 'x86_64'), ('cracklib-dicts', '0', '2.9.6', '8.ph3', 'x86_64'), ('curl', '0', '7.61.1', '4.ph3', 'x86_64'), ('curl-libs', '0', '7.61.1', '4.ph3', 'x86_64'), ('dbus', '0', '1.13.6', '1.ph3', 'x86_64'), ('device-mapper', '0', '2.02.181', '1.ph3', 'x86_64'), ('device-mapper-libs', '0', '2.02.181', '1.ph3', 'x86_64'), ('docker', '0', '18.06.2', '3.ph3', 'x86_64'), ('dracut', '0', '048', '1.ph3', 'x86_64'), ('dracut-tools', '0', '048', '1.ph3', 'x86_64'), ('e2fsprogs-libs', '0', '1.44.3', '2.ph3', 'x86_64'), ('elfutils', '0', '0.176', '1.ph3', 'x86_64'), ('elfutils-libelf', '0', '0.176', '1.ph3', 'x86_64'), ('expat', '0', '2.2.6', '2.ph3', 'x86_64'), ('expat-libs', '0', '2.2.6', '2.ph3', 'x86_64'), ('file', '0', '5.34', '1.ph3', 'x86_64'), ('file-libs', '0', '5.34', '1.ph3', 'x86_64'), ('filesystem', '0', '1.1', '4.ph3', 'x86_64'), ('findutils', '0', '4.6.0', '5.ph3', 'x86_64'), ('flex', '0', '2.6.4', '2.ph3', 'x86_64'), ('fuse', '0', '2.9.7', '5.ph3', 'x86_64'), ('gc', '0', '8.0.0', '1.ph3', 'x86_64'), ('glib', '0', '2.58.0', '4.ph3', 'x86_64'), ('glib-networking', '0', '2.59.1', '2.ph3', 'x86_64'), ('glibc', '0', '2.28', '4.ph3', 'x86_64'), ('glibc-iconv', '0', '2.28', '4.ph3', 'x86_64'), ('gmp', '0', '6.1.2', '2.ph3', 'x86_64'), ('gnupg', '0', '2.2.17', '1.ph3', 'x86_64'), ('gnutls', '0', '3.6.3', '3.ph3', 'x86_64'), ('gobject-introspection', '0', '1.58.0', '2.ph3', 'x86_64'), ('gpgme', '0', '1.11.1', '2.ph3', 'x86_64'), ('grep', '0', '3.1', '1.ph3', 'x86_64'), ('grub2', '0', '2.02', '13.ph3', 'x86_64'), ('grub2-efi', '0', '2.02', '13.ph3', 'x86_64'), ('grub2-pc', '0', '2.02', '13.ph3', 'x86_64'), ('guile', '0', '2.0.13', '2.ph3', 'x86_64'), ('gzip', '0', '1.9', '1.ph3', 'x86_64'), ('iana-etc', '0', '2.30', '2.ph3', 'noarch'), ('icu', '0', '61.1', '1.ph3', 'x86_64'), ('iproute2', '0', '4.18.0', '2.ph3', 'x86_64'), ('iptables', '0', '1.8.3', '1.ph3', 'x86_64'), ('js', '0', '1.8.5', '2.ph3', 'x86_64'), ('json-c', '0', '0.13.1', '1.ph3', 'x86_64'), ('json-glib', '0', '1.4.4', '1.ph3', 'x86_64'), ('kmod', '0', '25', '1.ph3', 'x86_64'), ('krb5', '0', '1.17', '1.ph3', 'x86_64'), ('libapparmor', '0', '2.13', '7.ph3', 'x86_64'), ('libarchive', '0', '3.3.3', '3.ph3', 'x86_64'), ('libassuan', '0', '2.5.1', '1.ph3', 'x86_64'), ('libcap', '0', '2.25', '8.ph3', 'x86_64'), ('libdb', '0', '5.3.28', '2.ph3', 'x86_64'), ('libffi', '0', '3.2.1', '6.ph3', 'x86_64'), ('libgcc', '0', '7.3.0', '4.ph3', 'x86_64'), ('libgcrypt', '0', '1.8.3', '2.ph3', 'x86_64'), ('libgomp', '0', '7.3.0', '4.ph3', 'x86_64'), ('libgpg-error', '0', '1.32', '1.ph3', 'x86_64'), ('libgsystem', '0', '2015.2', '2.ph3', 'x86_64'), ('libksba', '0', '1.3.5', '1.ph3', 'x86_64'), ('libltdl', '0', '2.4.6', '3.ph3', 'x86_64'), ('libmodulemd', '0', '2.4.0', '1.ph3', 'x86_64'), ('libpsl', '0', '0.20.2', '1.ph3', 'x86_64'), ('librepo', '0', '1.10.2', '1.ph3', 'x86_64'), ('libseccomp', '0', '2.4.0', '1.ph3', 'x86_64'), ('libselinux', '0', '2.8', '1.ph3', 'x86_64'), ('libsepol', '0', '2.8', '1.ph3', 'x86_64'), ('libsolv', '0', '0.6.35', '1.ph3', 'x86_64'), ('libsoup', '0', '2.64.0', '2.ph3', 'x86_64'), ('libssh2', '0', '1.9.0', '1.ph3', 'x86_64'), ('libstdc++', '0', '7.3.0', '4.ph3', 'x86_64'), ('libtasn1', '0', '4.13', '1.ph3', 'x86_64'), ('libtool', '0', '2.4.6', '3.ph3', 'x86_64'), ('libunistring', '0', '0.9.10', '1.ph3', 'x86_64'), ('libxml2', '0', '2.9.9', '1.ph3', 'x86_64'), ('libyaml', '0', '0.2.1', '2.ph3', 'x86_64'), ('linux', '0', '4.19.65', '3.ph3', 'x86_64'), ('m4', '0', '1.4.18', '2.ph3', 'x86_64'), ('mpfr', '0', '4.0.1', '1.ph3', 'x86_64'), ('ncurses', '0', '6.1', '1.ph3', 'x86_64'), ('ncurses-libs', '0', '6.1', '1.ph3', 'x86_64'), ('ncurses-terminfo', '0', '6.1', '1.ph3', 'x86_64'), ('net-tools', '0', '1.60', '11.ph3', 'x86_64'), ('nettle', '0', '3.4', '1.ph3', 'x86_64'), ('npth', '0', '1.6', '1.ph3', 'x86_64'), ('nspr', '0', '4.21', '1.ph3', 'x86_64'), ('nss-altfiles', '0', '2.23.0', '1.ph3', 'x86_64'), ('nss-libs', '0', '3.44', '2.ph3', 'x86_64'), ('openssh', '0', '7.8p1', '5.ph3', 'x86_64'), ('openssh-clients', '0', '7.8p1', '5.ph3', 'x86_64'), ('openssh-server', '0', '7.8p1', '5.ph3', 'x86_64'), ('openssl', '0', '1.0.2s', '1.ph3', 'x86_64'), ('ostree', '0', '2019.2', '1.ph3', 'x86_64'), ('ostree-grub2', '0', '2019.2', '1.ph3', 'x86_64'), ('ostree-libs', '0', '2019.2', '1.ph3', 'x86_64'), ('pcre', '0', '8.42', '1.ph3', 'x86_64'), ('pcre-libs', '0', '8.42', '1.ph3', 'x86_64'), ('photon-release', '0', '3.0', '3.ph3', 'noarch'), ('photon-repos', '0', '3.0', '3.ph3', 'noarch'), ('pinentry', '0', '1.1.0', '1.ph3', 'x86_64'), ('pkg-config', '0', '0.29.2', '2.ph3', 'x86_64'), ('polkit', '0', '0.113', '5.ph3', 'x86_64'), ('popt', '0', '1.16', '5.ph3', 'x86_64'), ('procps-ng', '0', '3.3.15', '1.ph3', 'x86_64'), ('python3', '0', '3.7.3', '2.ph3', 'x86_64'), ('python3-libs', '0', '3.7.3', '2.ph3', 'x86_64'), ('readline', '0', '7.0', '2.ph3', 'x86_64'), ('rpm-libs', '0', '4.14.2', '4.ph3', 'x86_64'), ('rpm-ostree', '0', '2019.3', '1.ph3', 'x86_64'), ('sed', '0', '4.5', '1.ph3', 'x86_64'), ('shadow', '0', '4.6', '3.ph3', 'x86_64'), ('shadow-tools', '0', '4.6', '3.ph3', 'x86_64'), ('sqlite-libs', '0', '3.27.2', '3.ph3', 'x86_64'), ('systemd', '0', '239', '13.ph3', 'x86_64'), ('util-linux', '0', '2.32', '1.ph3', 'x86_64'), ('util-linux-libs', '0', '2.32', '1.ph3', 'x86_64'), ('vim', '0', '8.1.0388', '4.ph3', 'x86_64'), ('which', '0', '2.21', '5.ph3', 'x86_64'), ('xz', '0', '5.2.4', '1.ph3', 'x86_64'), ('xz-libs', '0', '5.2.4', '1.ph3', 'x86_64'), ('zchunk', '0', '1.1.1', '1.ph3', 'x86_64'), ('zchunk-libs', '0', '1.1.1', '1.ph3', 'x86_64'), ('zlib', '0', '1.2.11', '1.ph3', 'x86_64')]>}, @ay [], @a(say) [], '', '', uint64 1567077619, [byte 0x1e, 0x0a, 0x85, 0x20, 0xa8, 0xe0, 0x18, 0x6a, 0x88, 0x15, 0xc0, 0xd9, 0xb0, 0xab, 0xc9, 0x98, 0x94, 0xa1, 0xfb, 0x0a, 0x48, 0xdf, 0xa0, 0x73, 0x32, 0x02, 0x9a, 0xdf, 0x49, 0xed, 0x13, 0x8d], [byte 0x44, 0x6a, 0x0e, 0xf1, 0x1b, 0x7c, 0xc1, 0x67, 0xf3, 0xb6, 0x03, 0xe5, 0x85, 0xc7, 0xee, 0xee, 0xb6, 0x75, 0xfa, 0xa4, 0x12, 0xd5, 0xec, 0x73, 0xf6, 0x29, 0x88, 0xeb, 0x0b, 0x6c, 0x54, 0x88])
Listing file mappings
This command lists the file relations between the original source Linux Photon filetree and the deployed filetree. The normal columns include file type type (regular file, directory, link), permissions in chmod octal format, userID, groupID, file size, file name.
root@photon-host [ ~ ]# ostree ls photon/3.0/x86_64/minimal
d00755 0 0 0 /
l00777 0 0 0 /bin -> usr/bin
l00777 0 0 0 /home -> var/home
l00777 0 0 0 /lib -> usr/lib
l00777 0 0 0 /lib64 -> usr/lib
l00777 0 0 0 /media -> run/media
l00777 0 0 0 /mnt -> var/mnt
l00777 0 0 0 /opt -> var/opt
l00777 0 0 0 /ostree -> sysroot/ostree
l00777 0 0 0 /root -> var/roothome
l00777 0 0 0 /sbin -> usr/sbin
l00777 0 0 0 /srv -> var/srv
l00777 0 0 0 /tmp -> sysroot/tmp
d00755 0 0 0 /boot
d00755 0 0 0 /dev
d00755 0 0 0 /proc
d00755 0 0 0 /run
d00755 0 0 0 /sys
d00755 0 0 0 /sysroot
d00755 0 0 0 /usr
d00755 0 0 0 /var
Extra columns can be added like checksum (-C) and extended attributes (-X).
root@photon-host [ /usr/share/man/man1 ]# ostree ls photon/3.0/x86_64/minimal -C
d00755 0 0 0 1e0a8520a8e0186a8815c0d9b0abc99894a1fb0a48dfa07332029adf49ed138d 446a0ef11b7cc167f3b603e585c7eeeeb675faa412d5ec73f62988eb0b6c5488 /
l00777 0 0 0 389846c2702216e1367c8dfb68326a6b93ccf5703c89c93979052a9bf359608e /bin -> usr/bin
l00777 0 0 0 4344c10bf4931483f918496534f12ed9b50dc6a2cead35e3cd9dd898d6ac9414 /home -> var/home
l00777 0 0 0 f11902ca9d69a80df33918534a3e443251fd0aa7f94b76301e1f55e52aed29dd /lib -> usr/lib
l00777 0 0 0 f11902ca9d69a80df33918534a3e443251fd0aa7f94b76301e1f55e52aed29dd /lib64 -> usr/lib
l00777 0 0 0 75317a3df11447c470ffdd63dde045450ca97dfb2a97a0f3f6a21a5da66f737c /media -> run/media
l00777 0 0 0 97c55dbe24e8f3aecfd3f3e5b3f44646fccbb39799807d37a217e9c871da108b /mnt -> var/mnt
l00777 0 0 0 46b1abbd27a846a9257a8d8c9fc4b384ac0888bdb8ac0d6a2d5de72715bd5092 /opt -> var/opt
l00777 0 0 0 d37269e3f46023fd0275212473e07011894cdf4148cbf3fb5758a7e9471dad8e /ostree -> sysroot/ostree
l00777 0 0 0 6f800e74eed172661278d1e1f09e389a6504dcd3358618e1c1618f91f9d33601 /root -> var/roothome
l00777 0 0 0 e0bead7be9323b06bea05cb9b66eb151839989e3a4e5d1a93e09a36919e91818 /sbin -> usr/sbin
l00777 0 0 0 5d4250bba1ed300f793fa9769474351ee5cebd71e8339078af7ebfbe6256d9b5 /srv -> var/srv
l00777 0 0 0 364fbd62f91ca1e06eb7dbd50c93de8976f2cea633658e2dbe803ce6f7490c09 /tmp -> sysroot/tmp
d00755 0 0 0 6e340b9cffb37a989ca544e6bb780a2c78901d3fb33738768511a30617afa01d 446a0ef11b7cc167f3b603e585c7eeeeb675faa412d5ec73f62988eb0b6c5488 /boot
d00755 0 0 0 6e340b9cffb37a989ca544e6bb780a2c78901d3fb33738768511a30617afa01d 446a0ef11b7cc167f3b603e585c7eeeeb675faa412d5ec73f62988eb0b6c5488 /dev
d00755 0 0 0 6e340b9cffb37a989ca544e6bb780a2c78901d3fb33738768511a30617afa01d 446a0ef11b7cc167f3b603e585c7eeeeb675faa412d5ec73f62988eb0b6c5488 /proc
d00755 0 0 0 6e340b9cffb37a989ca544e6bb780a2c78901d3fb33738768511a30617afa01d 446a0ef11b7cc167f3b603e585c7eeeeb675faa412d5ec73f62988eb0b6c5488 /run
d00755 0 0 0 6e340b9cffb37a989ca544e6bb780a2c78901d3fb33738768511a30617afa01d 446a0ef11b7cc167f3b603e585c7eeeeb675faa412d5ec73f62988eb0b6c5488 /sys
d00755 0 0 0 6e340b9cffb37a989ca544e6bb780a2c78901d3fb33738768511a30617afa01d 446a0ef11b7cc167f3b603e585c7eeeeb675faa412d5ec73f62988eb0b6c5488 /sysroot
d00755 0 0 0 ef1c0980e0d77f64e7f250a3e48f0b24e9285fc0716b80520dac6f98c148324a 446a0ef11b7cc167f3b603e585c7eeeeb675faa412d5ec73f62988eb0b6c5488 /usr
d00755 0 0 0 a3a987e053ea5a116f1e75a31cd7557fc6e57a3ae09e64171d7fea17ef71ec3e 446a0ef11b7cc167f3b603e585c7eeeeb675faa412d5ec73f62988eb0b6c5488 /var
By default, only the top folders are listed, but -R will list recursively. Instead of listing over 10,000 files, let’s filter to just all files that contain ‘rpm-ostree’, ‘rpmostree’ or ‘RpmOstree’, that must belong to rpm-ostree package itself.
root@photon-host [ /usr/share/rpm-ostree ]# ostree ls photon/3.0/x86_64/minimal -R | grep -e '[Rr]pm-\?[Oo]stree'
-00755 0 0 749000 /usr/bin/rpm-ostree
d00755 0 0 0 /usr/bin/rpm-ostree-host
-00644 0 0 1069 /usr/bin/rpm-ostree-host/function.inc
-00755 0 0 10507 /usr/bin/rpm-ostree-host/mk-ostree-host.sh
-00644 0 0 209 /usr/etc/rpm-ostreed.conf
-00644 0 0 1530 /usr/etc/dbus-1/system.d/org.projectatomic.rpmostree1.conf
l00777 0 0 0 /usr/lib/librpmostree-1.so.1 -> librpmostree-1.so.1.0.0
-00755 0 0 5278496 /usr/lib/librpmostree-1.so.1.0.0
-00644 0 0 2312 /usr/lib/girepository-1.0/RpmOstree-1.0.typelib
-00755 0 0 22 /usr/lib/kernel/install.d/00-rpmostree-skip.install
d00755 0 0 0 /usr/lib/rpm-ostree
-00755 0 0 1640704 /usr/lib/rpm-ostree/libdnf.so.2
-00644 0 0 622 /usr/lib/rpm-ostree/rpm-ostree-0-integration.conf
d00755 0 0 0 /usr/lib/sysimage/rpm-ostree-base-db
-00644 0 0 544768 /usr/lib/sysimage/rpm-ostree-base-db/Basenames
-00644 0 0 8192 /usr/lib/sysimage/rpm-ostree-base-db/Conflictname
-00644 0 0 110592 /usr/lib/sysimage/rpm-ostree-base-db/Dirnames
-00644 0 0 8192 /usr/lib/sysimage/rpm-ostree-base-db/Enhancename
-00644 0 0 8192 /usr/lib/sysimage/rpm-ostree-base-db/Filetriggername
-00644 0 0 8192 /usr/lib/sysimage/rpm-ostree-base-db/Group
-00644 0 0 12288 /usr/lib/sysimage/rpm-ostree-base-db/Installtid
-00644 0 0 8192 /usr/lib/sysimage/rpm-ostree-base-db/Name
-00644 0 0 8192 /usr/lib/sysimage/rpm-ostree-base-db/Obsoletename
-00644 0 0 2625536 /usr/lib/sysimage/rpm-ostree-base-db/Packages
-00644 0 0 86016 /usr/lib/sysimage/rpm-ostree-base-db/Providename
-00644 0 0 8192 /usr/lib/sysimage/rpm-ostree-base-db/Recommendname
-00644 0 0 69632 /usr/lib/sysimage/rpm-ostree-base-db/Requirename
-00644 0 0 20480 /usr/lib/sysimage/rpm-ostree-base-db/Sha1header
-00644 0 0 16384 /usr/lib/sysimage/rpm-ostree-base-db/Sigmd5
-00644 0 0 8192 /usr/lib/sysimage/rpm-ostree-base-db/Suggestname
-00644 0 0 8192 /usr/lib/sysimage/rpm-ostree-base-db/Supplementname
-00644 0 0 8192 /usr/lib/sysimage/rpm-ostree-base-db/Transfiletriggername
-00644 0 0 8192 /usr/lib/sysimage/rpm-ostree-base-db/Triggername
-00644 0 0 263 /usr/lib/systemd/system/rpm-ostree-bootstatus.service
-00644 0 0 257 /usr/lib/systemd/system/rpm-ostreed-automatic.service
-00644 0 0 227 /usr/lib/systemd/system/rpm-ostreed-automatic.timer
-00644 0 0 272 /usr/lib/systemd/system/rpm-ostreed.service
-00644 0 0 102 /usr/lib/systemd/system-preset/40-rpm-ostree-auto.preset
-00644 0 0 622 /usr/lib/tmpfiles.d/rpm-ostree-0-integration.conf
-00644 0 0 1082 /usr/lib/tmpfiles.d/rpm-ostree-1-autovar.conf
-00755 0 0 53 /usr/libexec/rpm-ostreed
-00644 0 0 3049 /usr/share/bash-completion/completions/rpm-ostree
-00644 0 0 15997 /usr/share/dbus-1/interfaces/org.projectatomic.rpmostree1.xml
-00644 0 0 133 /usr/share/dbus-1/system-services/org.projectatomic.rpmostree1.service
-00644 0 0 6160 /usr/share/polkit-1/actions/org.projectatomic.rpmostree1.policy
d00755 0 0 0 /usr/share/rpm-ostree
-00644 0 0 1169 /usr/share/rpm-ostree/treefile.json
atomic is really an alias for rpm-ostree command. The last file treefile.json is not installed by the rpm-ostree package, it is actually downloaded from the server, as we will see in the next chapter. For now, let us notice “osname” : “photon”, “ref” : “photon/1.0/x86_64/minimal”, “automatic_version_prefix” : “1.0_minimal”, that matches what we have known so far, and also the “documentation” : false setting, that explains why there are no manual files installed for rpm-ostree, and in fact for any package.
root@photon-host [ /usr/share/rpm-ostree ]# ls -l /usr/share/man/man1
total 0
Listing configuration changes
To diff the current /etc configuration versus default /etc (from the base image), this command will show the Modified, Added and Deleted files:
root@photon-host [ ~ ]# ostree admin config-diff
M ssh/sshd_config
M machine-id
M fstab
M hosts
M mtab
M shadow
A ssh/ssh_host_rsa_key
A ssh/ssh_host_rsa_key.pub
A ssh/ssh_host_dsa_key
A ssh/ssh_host_dsa_key.pub
A ssh/ssh_host_ecdsa_key
A ssh/ssh_host_ecdsa_key.pub
A ssh/ssh_host_ed25519_key
A ssh/ssh_host_ed25519_key.pub
A udev/hwdb.bin
A resolv.conf
A hostname
A localtime
A .pwd.lock
A .updated
Listing packages
The following is the rpm-ostree command that lists all the packages for that branch, extracted from RPM database.
root@photon-host [ ~ ]# rpm-ostree db list photon/3.0/x86_64/minimal
ostree commit: photon/3.0/x86_64/minimal (a31a843985e314a9e70bcf09afe8d59f7351817d9fb743c2b6dab84f20833650)
Linux-PAM-1.3.0-1.ph3.x86_64
attr-2.4.48-1.ph3.x86_64
autogen-libopts-5.18.16-1.ph3.x86_64
bash-4.4.18-1.ph3.x86_64
bc-1.07.1-1.ph3.x86_64
binutils-2.31.1-6.ph3.x86_64
bridge-utils-1.6-1.ph3.x86_64
bubblewrap-0.3.0-2.ph3.x86_64
bzip2-1.0.6-10.ph3.x86_64
bzip2-libs-1.0.6-10.ph3.x86_64
ca-certificates-20190521-1.ph3.x86_64
ca-certificates-pki-20190521-1.ph3.x86_64
coreutils-8.30-1.ph3.x86_64
cpio-2.12-4.ph3.x86_64
cracklib-2.9.6-8.ph3.x86_64
cracklib-dicts-2.9.6-8.ph3.x86_64
curl-7.61.1-4.ph3.x86_64
curl-libs-7.61.1-4.ph3.x86_64
dbus-1.13.6-1.ph3.x86_64
device-mapper-2.02.181-1.ph3.x86_64
device-mapper-libs-2.02.181-1.ph3.x86_64
docker-18.06.2-3.ph3.x86_64
dracut-048-1.ph3.x86_64
dracut-tools-048-1.ph3.x86_64
e2fsprogs-libs-1.44.3-2.ph3.x86_64
elfutils-0.176-1.ph3.x86_64
elfutils-libelf-0.176-1.ph3.x86_64
expat-2.2.6-2.ph3.x86_64
expat-libs-2.2.6-2.ph3.x86_64
file-5.34-1.ph3.x86_64
file-libs-5.34-1.ph3.x86_64
filesystem-1.1-4.ph3.x86_64
findutils-4.6.0-5.ph3.x86_64
flex-2.6.4-2.ph3.x86_64
fuse-2.9.7-5.ph3.x86_64
gc-8.0.0-1.ph3.x86_64
glib-2.58.0-4.ph3.x86_64
glib-networking-2.59.1-2.ph3.x86_64
glibc-2.28-4.ph3.x86_64
glibc-iconv-2.28-4.ph3.x86_64
gmp-6.1.2-2.ph3.x86_64
gnupg-2.2.17-1.ph3.x86_64
gnutls-3.6.3-3.ph3.x86_64
gobject-introspection-1.58.0-2.ph3.x86_64
gpgme-1.11.1-2.ph3.x86_64
grep-3.1-1.ph3.x86_64
grub2-2.02-13.ph3.x86_64
grub2-efi-2.02-13.ph3.x86_64
grub2-pc-2.02-13.ph3.x86_64
guile-2.0.13-2.ph3.x86_64
gzip-1.9-1.ph3.x86_64
iana-etc-2.30-2.ph3.noarch
icu-61.1-1.ph3.x86_64
iproute2-4.18.0-2.ph3.x86_64
iptables-1.8.3-1.ph3.x86_64
js-1.8.5-2.ph3.x86_64
json-c-0.13.1-1.ph3.x86_64
json-glib-1.4.4-1.ph3.x86_64
kmod-25-1.ph3.x86_64
krb5-1.17-1.ph3.x86_64
libapparmor-2.13-7.ph3.x86_64
libarchive-3.3.3-3.ph3.x86_64
libassuan-2.5.1-1.ph3.x86_64
libcap-2.25-8.ph3.x86_64
libdb-5.3.28-2.ph3.x86_64
libffi-3.2.1-6.ph3.x86_64
libgcc-7.3.0-4.ph3.x86_64
libgcrypt-1.8.3-2.ph3.x86_64
libgomp-7.3.0-4.ph3.x86_64
libgpg-error-1.32-1.ph3.x86_64
libgsystem-2015.2-2.ph3.x86_64
libksba-1.3.5-1.ph3.x86_64
libltdl-2.4.6-3.ph3.x86_64
libmodulemd-2.4.0-1.ph3.x86_64
libpsl-0.20.2-1.ph3.x86_64
librepo-1.10.2-1.ph3.x86_64
libseccomp-2.4.0-1.ph3.x86_64
libselinux-2.8-1.ph3.x86_64
libsepol-2.8-1.ph3.x86_64
libsolv-0.6.35-1.ph3.x86_64
libsoup-2.64.0-2.ph3.x86_64
libssh2-1.9.0-1.ph3.x86_64
libstdc++-7.3.0-4.ph3.x86_64
libtasn1-4.13-1.ph3.x86_64
libtool-2.4.6-3.ph3.x86_64
libunistring-0.9.10-1.ph3.x86_64
libxml2-2.9.9-1.ph3.x86_64
libyaml-0.2.1-2.ph3.x86_64
linux-4.19.65-3.ph3.x86_64
m4-1.4.18-2.ph3.x86_64
mpfr-4.0.1-1.ph3.x86_64
ncurses-6.1-1.ph3.x86_64
ncurses-libs-6.1-1.ph3.x86_64
ncurses-terminfo-6.1-1.ph3.x86_64
net-tools-1.60-11.ph3.x86_64
nettle-3.4-1.ph3.x86_64
npth-1.6-1.ph3.x86_64
nspr-4.21-1.ph3.x86_64
nss-altfiles-2.23.0-1.ph3.x86_64
nss-libs-3.44-2.ph3.x86_64
openssh-7.8p1-5.ph3.x86_64
openssh-clients-7.8p1-5.ph3.x86_64
openssh-server-7.8p1-5.ph3.x86_64
openssl-1.0.2s-1.ph3.x86_64
ostree-2019.2-1.ph3.x86_64
ostree-grub2-2019.2-1.ph3.x86_64
ostree-libs-2019.2-1.ph3.x86_64
pcre-8.42-1.ph3.x86_64
pcre-libs-8.42-1.ph3.x86_64
photon-release-3.0-3.ph3.noarch
photon-repos-3.0-3.ph3.noarch
pinentry-1.1.0-1.ph3.x86_64
pkg-config-0.29.2-2.ph3.x86_64
polkit-0.113-5.ph3.x86_64
popt-1.16-5.ph3.x86_64
procps-ng-3.3.15-1.ph3.x86_64
python3-3.7.3-2.ph3.x86_64
python3-libs-3.7.3-2.ph3.x86_64
readline-7.0-2.ph3.x86_64
rpm-libs-4.14.2-4.ph3.x86_64
rpm-ostree-2019.3-1.ph3.x86_64
sed-4.5-1.ph3.x86_64
shadow-4.6-3.ph3.x86_64
shadow-tools-4.6-3.ph3.x86_64
sqlite-libs-3.27.2-3.ph3.x86_64
systemd-239-13.ph3.x86_64
util-linux-2.32-1.ph3.x86_64
util-linux-libs-2.32-1.ph3.x86_64
vim-8.1.0388-4.ph3.x86_64
which-2.21-5.ph3.x86_64
xz-5.2.4-1.ph3.x86_64
xz-libs-5.2.4-1.ph3.x86_64
zchunk-1.1.1-1.ph3.x86_64
zchunk-libs-1.1.1-1.ph3.x86_64
zlib-1.2.11-1.ph3.x86_64
Querying for package details
We are able to use the query option of rpm to make sure any package have been installed properly. The files list should match the previous file mappings in 4.2, so let’s check package rpm-ostree. As we’ve seen, manual files listed here are actually missing, they were not installed.
root@photon-host [ /usr/share/man/man1 ]# rpm -ql rpm-ostree
/usr/bin/atomic
/usr/bin/rpm-ostree
/usr/lib/girepository-1.0/RpmOstree-1.0.typelib
/usr/lib/librpmostree-1.so.1
/usr/lib/librpmostree-1.so.1.0.0
/usr/lib/rpm-ostree
/usr/lib/rpm-ostree/tmpfiles-ostree-integration.conf
/usr/share/man/man1/atomic.1.gz
/usr/share/man/man1/rpm-ostree.1.gz
Why am I unable to install, upgrade or uninstall packages?
The OSTree host installer needs the server URL or the server repository.
When you perform the installation using the repo, the install packages are located under the layer package. When you install with the URL, the packages are located under the local packages.
You can use the rpm-ostree uninstall command to uninstall only the layered and local packages but not the base packages. To modify the base packages, you can use the rpm-ostree override command.
When you run rpm-ostree upgrade, the command will only upgrade packages based on the commit available in the server.
5 - Host Updating Operations
- Upgrade Overview
- Incremental upgrade
- Listing file differences
- Listing package differences
- Rollback
- Installing Packages
- Uninstalling Packages
- Deleting a deployed filetree
- Version skipping upgrade
- Tracking parent commits
- Resetting a branch to a previous commit
Upgrade overview
If you’ve used yum, dnf (and now tdnf for Photon) in RPM systems or apt-get in Debian based Unix, you understand what “install” is for packages and the subtle difference between “update” and “upgrade”.
OSTree and RPM-OSTree don’t distinguish between them and the term “upgrade” has a slightly different meaning - to bring the system in sync with the remote repo, to the top of the Refspec (branch), just like in Git, by pulling the latest changes.
In fact, ostree and rpm-ostree commands support a single “upgrade” verb for a file image tree and a package list in the same refspec (branch). rpm-ostree upgrade will install a package if it doesn’t exist, will not touch it if it has same version in the new image, will upgrade it if the version number is higher and it may actually downgrade it, if the package has been downgraded in the new image. I wish this operation had a different name, to avoid any confusion.
The reverse operation of an upgrade is a “rollback” and fortunately it’s not named “downgrade” because it may upgrade packages in the last case describe above.
As we’ll see in a future chapter, a jump to a different Refspec (branch) is also supported and it’s named “rebase”.
Incremental upgrade
To check if there are any updates available, one would execute:
root@photon-host-def [ ~ ]# rpm-ostree upgrade
Updating from: photon:photon/3.0/x86_64/minimal
No upgrade available.
It is good idea to check periodically for updates.
To check if there are any new updates without actually applying them, we will pass the –check-diff flag, that would list the different packages as added, modified or deleted - if such operations were to happen.
root@photon-host [ ~ ]# rpm-ostree upgrade --check-diff
Updating from: photon:photon/3.0/x86_64/minimal
8 metadata, 13 content objects fetched; 1026 KiB transferred in 0 seconds
+gawk-4.1.3-2.ph1.x86_64
+sudo-1.8.15-3.ph1.x86_64
+wget-1.17.1-2.ph1.x86_64
We like what we see and now let’s upgrade for real. This command will deploy a new bootable filetree.
root@photon-host [ ~ ]# rpm-ostree upgrade
Receiving metadata objects: 134/(estimating) 14.1 MB/s 14.1 MB... done
Checking out tree c8f2b11... done
Enabled rpm-md repositories: repo photon-updates photon photon-extras
rpm-md repo 'repo' (cached); generated: 2019-09-18T05:26:00Z
rpm-md repo 'photon-updates' (cached); generated: 2019-09-11T00:02:44Z
rpm-md repo 'photon' (cached); generated: 2019-02-06T08:56:24Z
rpm-md repo 'photon-extras' (cached); generated: 2018-11-02T18:09:56Z
Importing rpm-md... done
Resolving dependencies... done
Checking out packages... done
Running pre scripts... done
Running post scripts... done
Writing rpmdb... done
Writing OSTree commit... done
Staging deployment... done
Freed: 20.7 MB (pkgcache branches: 0)
zlib 1.2.11-1.ph3 -> 1.2.11-2.ph3
Downgraded:
ostree 2019.2-15.ph3 -> 2019.2-2.ph3
ostree-grub2 2019.2-15.ph3 -> 2019.2-2.ph3
ostree-libs 2019.2-15.ph3 -> 2019.2-2.ph3
Removed:
chkconfig-1.9-1.ph3.x86_64
elasticsearch-6.7.0-2.ph3.x86_64
kibana-6.7.0-2.ph3.x86_64
logstash-6.7.0-2.ph3.x86_64
newt-0.52.20-1.ph3.x86_64
nodejs-10.15.2-1.ph3.x86_64
openjdk8-1.8.0.212-2.ph3.x86_64
openjre8-1.8.0.212-2.ph3.x86_64
ruby-2.5.3-2.ph3.x86_64
slang-2.3.2-1.ph3.x86_64
Added:
nss-3.44-2.ph3.x86_64
xmlsec1-1.2.26-2.ph3.x86_64
Run "systemctl reboot" to start a reboot
By looking at the commit history, notice that the new commit has the original commit as parent.
root@photon-host [ ~ ]# ostree log photon/3.0/x86_64/minimal
commit c8f2b116b067d7695f9033bf2a99505198269354e157c0f2d5b78266cb874239
ContentChecksum: 9bc2079ad70df6dc9373752b254711f3413ae8a07628016c7de7f7d3fa505a6f
Date: 2019-09-18 08:22:15 +0000
Version: 3.0_minimal.2
(no subject)
commit 28dc49ecb4604c0bc349e4445adc659491a1874c01198e6253a261f4d59708b7
ContentChecksum: c3650c76e2bb0e9b6b063cda2dd55939c965c54fd0b0f5ce2cfb7e801403e610
Date: 2019-09-16 09:51:33 +0000
Version: 3.0_minimal.1
Notice that now we have a new reference, that corresponds to the newly deployed image.
root@photon-host [ ~ ]# ostree refs
rpmostree/pkg/createrepo__c/0.11.1-2.ph3.x86__64
rpmostree/pkg/wget/1.20.3-1.ph3.x86__64
photon-1:photon/3.0/x86_64/minimal
rpmostree/base/0
rpmostree/base/1
ostree/0/0/0
ostree/0/0/1
ostree/0/0/2
rpmostree/pkg/rpm/4.14.2-4.ph3.x86__64
Let us look at the status. The new filetree version .1 has the expected Commit ID and a newer timestamp, that is actually the server date/time when the image has been generated, not the time/date when it was downloaded or installed at the host. The old image has a star next to it, showing that’s the image the system is booted currently into.
root@photon-host [ ~ ]# rpm-ostree status
State: idle
AutomaticUpdates: disabled
Deployments:
ostree://photon-1:photon/3.0/x86_64/minimal
Version: 3.0_minimal.2 (2019-09-18T08:22:15Z)
BaseCommit: c8f2b116b067d7695f9033bf2a99505198269354e157c0f2d5b78266cb874239
Diff: 1 upgraded, 3 downgraded, 10 removed, 2 added
LayeredPackages: createrepo_c rpm wget
* ostree://photon-1:photon/3.0/x86_64/minimal
Version: 3.0_minimal.1 (2019-09-16T09:51:33Z)
BaseCommit: 28dc49ecb4604c0bc349e4445adc659491a1874c01198e6253a261f4d59708b7
LayeredPackages: createrepo_c rpm wget
ostree://photon:photon/3.0/x86_64/minimal
Version: 3.0_minimal.1 (2019-09-16T09:51:33Z)
BaseCommit: 28dc49ecb4604c0bc349e4445adc659491a1874c01198e6253a261f4d59708b7
LayeredPackages: createrepo_c rpm wget
Now let’s type ‘reboot’. Grub will list the new filetree as the first image, marked with a star, as the default bootable image. If the keyboard is not touched and order is not changed, grub will timeout and will boot into that image.
Let’s look again at the status. It’s identical, just that the star is next to the newer image, to show it’s the current image it has booted from.
root@photon-host [ ~ ]# rpm-ostree status
State: idle
AutomaticUpdates: disabled
Deployments:
* ostree://photon-1:photon/3.0/x86_64/minimal
Version: 3.0_minimal.2 (2019-09-18T08:22:15Z)
BaseCommit: c8f2b116b067d7695f9033bf2a99505198269354e157c0f2d5b78266cb874239
LayeredPackages: createrepo_c rpm wget
ostree://photon-1:photon/3.0/x86_64/minimal
Version: 3.0_minimal.1 (2019-09-16T09:51:33Z)
BaseCommit: 28dc49ecb4604c0bc349e4445adc659491a1874c01198e6253a261f4d59708b7
LayeredPackages: createrepo_c rpm wget
Also, the current deployment directory is based on the new commit:
root@photon-host-def [ ~ ]# ostree admin config-diff --print-current-dir
/ostree/deploy/photon/deploy/63fd7a46dac6c169ee997039c229dd1d626f9b13eaf47b7a183f7a449eb4076f.0
A fresh upgrade for a new version will delete the older, original image and bring a new one, that will become the new default image. The previous ‘default’ image will move down one position as the backup image.
Listing file differences
Now we can look at what files have been Added, Modified, Deleted due to the addition of those three packages and switching of the boot directories, by comparing the two commits.
root@photon-host-def [ ~ ]# ostree diff 63fd 37e2
M /usr/etc/ld.so.cache
M /usr/lib/sysimage/rpm-ostree-base-db/Basenames
M /usr/lib/sysimage/rpm-ostree-base-db/Conflictname
M /usr/lib/sysimage/rpm-ostree-base-db/Dirnames
M /usr/lib/sysimage/rpm-ostree-base-db/Enhancename
M /usr/lib/sysimage/rpm-ostree-base-db/Filetriggername
M /usr/lib/sysimage/rpm-ostree-base-db/Group
M /usr/lib/sysimage/rpm-ostree-base-db/Installtid
M /usr/lib/sysimage/rpm-ostree-base-db/Name
M /usr/lib/sysimage/rpm-ostree-base-db/Obsoletename
M /usr/lib/sysimage/rpm-ostree-base-db/Packages
M /usr/lib/sysimage/rpm-ostree-base-db/Providename
M /usr/lib/sysimage/rpm-ostree-base-db/Recommendname
M /usr/lib/sysimage/rpm-ostree-base-db/Requirename
M /usr/lib/sysimage/rpm-ostree-base-db/Sha1header
M /usr/lib/sysimage/rpm-ostree-base-db/Sigmd5
M /usr/lib/sysimage/rpm-ostree-base-db/Suggestname
M /usr/lib/sysimage/rpm-ostree-base-db/Supplementname
M /usr/lib/sysimage/rpm-ostree-base-db/Transfiletriggername
M /usr/lib/sysimage/rpm-ostree-base-db/Triggername
M /usr/share/rpm/Basenames
M /usr/share/rpm/Conflictname
M /usr/share/rpm/Dirnames
M /usr/share/rpm/Enhancename
M /usr/share/rpm/Filetriggername
M /usr/share/rpm/Group
M /usr/share/rpm/Installtid
M /usr/share/rpm/Name
M /usr/share/rpm/Obsoletename
M /usr/share/rpm/Packages
M /usr/share/rpm/Providename
M /usr/share/rpm/Recommendname
M /usr/share/rpm/Requirename
M /usr/share/rpm/Sha1header
M /usr/share/rpm/Sigmd5
M /usr/share/rpm/Suggestname
M /usr/share/rpm/Supplementname
M /usr/share/rpm/Transfiletriggername
M /usr/share/rpm/Triggername
M /usr/share/rpm-ostree/treefile.json
D /usr/bin/certutil
D /usr/bin/nss-config
D /usr/bin/pk12util
D /usr/bin/xmlsec1
D /usr/lib/libfreebl3.chk
D /usr/lib/libfreebl3.so
D /usr/lib/libfreeblpriv3.chk
D /usr/lib/libgtest1.so
D /usr/lib/libgtestutil.so
D /usr/lib/libnssckbi.so
D /usr/lib/libnssdbm3.chk
D /usr/lib/libnssdbm3.so
D /usr/lib/libnsssysinit.so
D /usr/lib/libsmime3.so
D /usr/lib/libsoftokn3.chk
D /usr/lib/libssl3.so
D /usr/lib/libxmlsec1-nss.so
D /usr/lib/libxmlsec1-nss.so.1
D /usr/lib/libxmlsec1-nss.so.1.2.26
D /usr/lib/libxmlsec1-openssl.so
D /usr/lib/libxmlsec1-openssl.so.1
D /usr/lib/libxmlsec1-openssl.so.1.2.26
D /usr/lib/libxmlsec1.so
D /usr/lib/libxmlsec1.so.1
D /usr/lib/libxmlsec1.so.1.2.26
Listing package differences
We can also look at package differences, as you expect, using the right tool for the job.
root@photon-host-def [ ~ ]# rpm-ostree db diff 63fd 37e2
ostree diff commit old: rollback deployment (63fd7a46dac6c169ee997039c229dd1d626f9b13eaf47b7a183f7a449eb4076f)
ostree diff commit new: booted deployment (37e2ecfa34eb808962fdfed28623bbc457184bcd6bb788b79143d33e3569084f)
Removed:
nss-3.44-2.ph3.x86_64
xmlsec1-1.2.26-2.ph3.x86_64
Rollback
If we want to go back to the previous image, we can rollback. The order of the images will be changed, so the old filetree will become the default bootable image. If -r option is passed, the rollback will continue with a reboot.
root@photon-host-def [ ~ ]# rpm-ostree rollback
Moving 'e663b2872efa01d80e4c34c823431472beb653373af32de83c7d2480316b8a6a.0' to be first deployment
Transaction complete; bootconfig swap: yes; deployment count change: 0
Upgraded:
ostree 2019.2-2.ph3 -> 2019.2-15.ph3
ostree-grub2 2019.2-2.ph3 -> 2019.2-15.ph3
ostree-libs 2019.2-2.ph3 -> 2019.2-15.ph3
zlib 1.2.11-2.ph3 -> 1.2.11-1.ph3
Removed:
nss-3.44-2.ph3.x86_64
xmlsec1-1.2.26-2.ph3.x86_64
Added:
chkconfig-1.9-1.ph3.x86_64
elasticsearch-6.7.0-2.ph3.x86_64
kibana-6.7.0-2.ph3.x86_64
logstash-6.7.0-2.ph3.x86_64
newt-0.52.20-1.ph3.x86_64
nodejs-10.15.2-1.ph3.x86_64
openjdk8-1.8.0.212-2.ph3.x86_64
openjre8-1.8.0.212-2.ph3.x86_64
ruby-2.5.3-2.ph3.x86_64
slang-2.3.2-1.ph3.x86_64
Run "systemctl reboot" to start a reboot
In fact, we can repeat the rollback operation as many times as we want before reboot. On each execution, it’s going to change the order. It will not delete any image.
However, an upgrade will keep the current default image and will eliminate the other image, whichever that is. So if Photon installation rolled back to an older build, an upgrade will keep that, eliminate the newer version and will replace it with an even newer version at the next upgrade.
The boot order moved back to original:
root@photon-host-def [ ~ ]# rpm-ostree status
State: idle
AutomaticUpdates: disabled
Deployments:
* ostree://photon-2:photon/3.0/x86_64/minimal
Version: 3.0_minimal.3 (2019-09-18T12:48:03Z)
Commit: cf357c0f376decb3bae42326737db7e36bcf3568ab901c33dc57800c3718f07b
ostree://photon:photon/3.0/x86_64/minimal
Version: 3.0_minimal (2019-08-29T11:20:19Z)
Commit: a31a843985e314a9e70bcf09afe8d59f7351817d9fb743c2b6dab84f20833650
The current bootable image path moved also back to the original value:
root@photon-host-def [ ~ ]# ostree admin config-diff --print-current-dir
/ostree/deploy/photon/deploy/47899767bdd4276266383fce13c4a26a51ca0304ae754609283d75f7d8aad36e.0
Installing Packages
You can add more packages onto the system that are not part of the commit composed on the server.
rpm-ostree install <packages>
Example:
rpm-ostree install https://kojipkgs.fedoraproject.org//packages/wget/1.19.5/5.fc29/x86_64/wget-1.19.5-5.fc29.x86_64.rpm
Uninstalling Packages
To remove layered packages installed from a repository, use
rpm-ostree uninstall <pkg>
To remove layered packages installed from a local package, you must specify the full NEVRA of the package.
For example:
rpm-ostree uninstall ltrace-0.7.91-16.fc22.x86_64
To uninstall a package that is a part of the base layer, use
rpm-ostree override remove <pkg>
For example:
rpm-ostree override remove firefox
Deleting a deployed filetree
It is possible to delete a deployed tree. You won’t need to do that normally, as upgrading to a new image will delete the old one, but if for some reason deploying failed (loss of power, networking issues), you’ll want to delete the partially deployed image.
The only supported index is 1. (If multiple bootable images will be supported in the future, a larger than one, zero-based index of the image to delete will be supported).
You cannot delete the default bootable filetree, so passing 0 will result in an error.
root@photon-host-def [ ~ ]# ostree admin undeploy -v 1
OT: Using bootloader: OstreeBootloaderGrub2
Transaction complete; bootconfig swap: yes deployment count change: -1
Deleted deployment a31a843985e314a9e70bcf09afe8d59f7351817d9fb743c2b6dab84f20833650
root@photon-host-cus1 [ ~ ]# ostree admin undeploy -v 0
OT: Deployment cf357c0f376decb3bae42326737db7e36bcf3568ab901c33dc57800c3718f07b.0 unlocked=0
error: Cannot undeploy currently booted deployment 0
Now, we can see that the newer image is gone, the deployment directory for commit a31a has been removed.
root@photon-host-def [ ~ ]# rpm-ostree status
State: idle
AutomaticUpdates: disabled
Deployments:
* ostree://photon-2:photon/3.0/x86_64/minimal
Version: 3.0_minimal.3 (2019-09-18T12:48:03Z)
Commit: cf357c0f376decb3bae42326737db7e36bcf3568ab901c33dc57800c3718f07b
root@photon-host-cus1 [ ~ ]# ls /ostree/deploy/photon/deploy/
cf357c0f376decb3bae42326737db7e36bcf3568ab901c33dc57800c3718f07b.0
cf357c0f376decb3bae42326737db7e36bcf3568ab901c33dc57800c3718f07b.0.origin
However the commit is still there in the OSTree repo.
root@photon-host-def [ ~ ]# ostree log cf35
commit cf357c0f376decb3bae42326737db7e36bcf3568ab901c33dc57800c3718f07b
ContentChecksum: c24d108c7b7451374b474456a47f512e648833040bfbd4f43d862456bd6d5a18
Date: 2019-09-18 12:48:03 +0000
Version: 3.0_minimal.3
But there is nothing to rollback to.
root@photon-host-def [ ~ ]# rpm-ostree rollback
error: Found 1 deployments, at least 2 required for rollback
If we were to upgrade again, it would bring these packages back, but let’s just check the differeneces.
root@photon-host-def [ ~ ]# rpm-ostree upgrade --check-diff
Updating from: photon:photon/3.0/x86_64/minimal
+gawk-4.1.0-2.ph1.x86_64
+sudo-1.8.11p1-4.ph1.x86_64
+wget-1.15-1.ph1.x86_64
Version skipping upgrade
Let’s assume that after a while, VMware releases version 2 that removes sudo and adds bison and tar. Now, an upgrade will skip version 1 and go directly to 2. Let’s first look at what packages are pulled (notice sudo missing, as expected), then upgrade with reboot option.
root@photon-host-def [ ~ ]# rpm-ostree upgrade --check-diff
Updating from: photon:photon/3.0/x86_64/minimal
7 metadata, 13 content objects fetched; 1287 KiB transferred in 0 seconds
+bison-3.0.2-2.ph1.x86_64
+gawk-4.1.0-2.ph1.x86_64
+tar-1.27.1-1.ph1.x86_64
+wget-1.15-1.ph1.x86_64
root@photon-host-def [ ~ ]# rpm-ostree upgrade -r
Updating from: photon:photon/3.0/x86_64/minimal
107 metadata, 512 content objects fetched; 13064 KiB transferred in 1 seconds
Copying /etc changes: 5 modified, 0 removed, 16 added
Transaction complete; bootconfig swap: yes deployment count change: 1
Freed objects: 19.3 MB
After reboot, let’s check the booting filetrees, the current dir for the current filetree and look at commit differences:
root@photon-host-def [ ~ ]# rpm-ostree status
State: idle
AutomaticUpdates: disabled
Deployments:
* ostree://photon-1:photon/3.0/x86_64/minimal
Version: 3.0_minimal.1 (2019-09-16T09:51:33Z)
BaseCommit: 28dc49ecb4604c0bc349e4445adc659491a1874c01198e6253a261f4d59708b7
LayeredPackages: createrepo_c rpm wget
ostree://photon:photon/3.0/x86_64/minimal
Version: 3.0_minimal.1 (2019-09-16T09:51:33Z)
BaseCommit: 28dc49ecb4604c0bc349e4445adc659491a1874c01198e6253a261f4d59708b7
LayeredPackages: createrepo_c rpm wget
root@photon-host-cus1 [ ~ ]# ostree admin config-diff --print-current-dir
/ostree/deploy/photon/deploy/e663b2872efa01d80e4c34c823431472beb653373af32de83c7d2480316b8a6a.0
root@photon-host-cus1 [ ~ ]# rpm-ostree db diff 8b4b e663
ostree diff commit old: rollback deployment (8b4b9d4ec033d1eb816711bfdda595d1013fecbe5cd340f6a619cdc9d83a3bf2)
ostree diff commit new: booted deployment (e663b2872efa01d80e4c34c823431472beb653373af32de83c7d2480316b8a6a)
root@photon-host-cus1 [ ~ ]# rpm-ostree db diff 82bc 092e
error: Refspec '82bc' not found
Interesting fact: The metadata for commit 82bc has been removed from the local repo.
Tracking parent commits
OSTree will display limited commit history - maximum 2 levels, so if you want to traverse the history even though it may not find a commitment by its ID, you can refer to its parent using ‘^’ suffix, grandfather via ‘^^’ and so on. We know that 82bc is the parent of 092e:
root@photon-host-def [ ~ ]# rpm-ostree db diff 092e^ 092e
error: No such metadata object 82bca728eadb7292d568404484ad6889c3f6303600ca8c743a4336e0a10b3817.commit
error: Refspec '82cb' not found
root@photon-host-def [ ~ ]# rpm-ostree db diff 092e^^ 092e
error: No such metadata object 82bca728eadb7292d568404484ad6889c3f6303600ca8c743a4336e0a10b3817.commit
So commit 092e knows who its parent is, but its metadata is no longer in the local repo, so it cannot traverse further to its parent to find an existing grandfather.
Resetting a branch to a previous commit
We can reset the head of a branch in a local repo to a previous commit, for example corresponding to version 0 (3.0_minimal).
root@photon-host-def [ ~ ]# ostree reset photon:photon/3.0/x86_64/minimal cf35
Now if we look again at the branch commit history, the head is at version 0.
root@photon-host-def [ ~ ]# ostree log photon/3.0/x86_64/minimal
commit cf357c0f376decb3bae42326737db7e36bcf3568ab901c33dc57800c3718f07b
ContentChecksum: c24d108c7b7451374b474456a47f512e648833040bfbd4f43d862456bd6d5a18
Date: 2019-09-18 12:48:03 +0000
Version: 3.0_minimal
6 - Creating a Server
Photon OS 3.0 includes a rpm-ostree-repo package that can be installed on a VM.
This package provides an automated script that creates a repo tree that acts as a server.
Run the following commands to create a server:
tdnf install rpm-ostree-repo
A script is created, which provides options to create a server.
Script to create a Photon OSTree repo Usage:
/usr/bin/rpm-ostree-server/mkostreerepo -r=<repo path>
/usr/bin/rpm-ostree-server/mkostreerepo -r=<repo path> -p=<json treefile>
/usr/bin/rpm-ostree-server/mkostreerepo -c -r=<repo path> -p=<json treefile>
-r|--repopath <Provide repo path>
-p|--jsonfile <Provide Json file>
-c|--customrepo <Provide custom repo file inside repo path directory>
Note
- Use PATH=$PATH:/usr/bin/rpm-ostree-server and then use mkostreerepo from any directory for ease of use.
- mkostreerepo is used to create the fresh tree for ostree.
- mkostreerepo is also used to update a new commit to the existing tree.
- You can also use custom repo as to create/append the tree.
Run the following command to initiate the script, choose different help options to create a server.
mkostreerepo
Manually Composing your OSTree repo
Use the following commands to initialize a new repo and to compose it.
root [ ~ ]# cd /srv/rpm-ostree
root [ /srv/rpm-ostree ]# ostree --repo=repo init --mode=archive-z2
root [ /srv/rpm-ostree ]# rpm-ostree compose tree --repo=repo photon-base.json
You can now deploy a host. For more information, see File oriented server operations and Package oriented server operations to learn create your own customized file tree.
7 - Installing a Photon RPM-OStree host against a custom server repository
Organizations that maintain their own OSTree servers create custom image trees suited to their needs from which hosts can be deployed and upgraded. One single server may make available several branches to install, for example “base”, “minimal” and “full”. Or, if you think in terms of Windows OS SKUs - “Home”, “Professional” or “Enterprise” edition.
So in fact there are two pieces of information the OSTree host installer needs - the server URL and the branch ref. Also, there are two ways to pass this info - manually via keyboard, when prompted and automated, by reading from a config file.
Manual install of a custom host
For Photon 1.0 or 1.0 Revision 2, installing a Photon RPM-OSTree host that will pull from a server repository of your choice is very similar to the way we installed the host against the default server repo in Chapter 2.
We will follow the same steps, selecting “Photon OSTree Host”, and after assigning a host name like photon-host and a root password, this time we will click on “Custom RPM-OSTree Server”.
An additional screen will ask for the URL of server repo - just enter the IP address or fully qualified domain name of the server installed in the previous step.
Once this is done and the installation finished, reboot and you are ready to use it. You may verify - just like in Chapter 3.1 - that you can get an rpm-ostree status. The value for the CommitID should be identical to the host that installed from default repo, if the server has been installed fresh, from the same ISO.
Automated install of a custom host via kickstart
Photon 3.0 supports automated install that will not interact with the user, in other words installer will display its progress, but will not prompt for any keys to be clicked, and will boot at the end of installation.
If not familiar with the way kickstart works, visit Kickstart Support in Photon OS. The kickstart json config for OSTree is similar to minimal or full, except for these settings that should sound familiar:
...
"type": "ostree_host",
"ostree_repo_url": "http://192.168.218.249",
"ostree_repo_ref": "photon/3.0/x86_64/minimal",
...
Or, for default installation
....
"type": "ostree_host",
"default_repo": true,
....
If the server is a future version of Photon OS, say Photon OS 4.0, and the administrator composed trees for the included json files, the ostree_repo_ref will take either value: photon/4.0/x86_64/base, photon/4.0/x86_64/minimal, or photon/4.0/x86_64/full.
In most situations, kickstart file is accessed via http from PXE boot. That enables booting from network and end to end install of hosts from pre-defined server URL and branch without assistance from user.
8 - Automatic Updates
Automatic updates are disabled by default.
To verify this, run the status command.
root@photon-host-def [ ~ ]# rpm-ostree status
State: idle
AutomaticUpdates: disabled
Deployments:
* ostree://photon-1:photon/3.0/x86_64/minimal
Version: 3.0_minimal.1 (2019-09-16T09:51:33Z)
BaseCommit: 28dc49ecb4604c0bc349e4445adc659491a1874c01198e6253a261f4d59708b7
LayeredPackages: createrepo_c rpm wget
Enable Automatic Updates
- Run the following command:
$ systemctl restart rpm-ostreed
To enable automatic background updates, edit the
/etc/rpm-ostreed.conf, and include the below lines in theDaemonsection:[Daemon] AutomaticUpdatePolicy=stage #IdleExitTimeout=60Run the following commands:
$ systemctl reload rpm-ostreed $ systemctl enable rpm-ostree-automatic.timer --now $ systemctl restart rpm-ostree-automaticVerify that the automatic update feature has been enabled:
$ rpm-ostree status -v State: idle AutomaticUpdates: stage; rpm-ostreed-automatic.timer: last run 16min agoOn the server machine, perform another commit on the base tree.
Automatic updates are now enabled and will automatically update the host system.
9 - File Oriented Server Operations
In this section, we will checkout a filetree into a writable directory structure on disk, make several file changes and commit the changes back into the repository. Then we will download this commit and apply at the host. As you may have guessed, this chapter is mostly about OSTree - the base technology. I’ve not mentioned anything about packages, although it is quite possible to install packages (afler all, packages are made of files, right?) and commit without the help of rpm-ostree, but it’s too much of a headache and not worth the effort, since rpm-ostree does it simpler and better.
When would you want to do that? When you want for all your hosts to get an application or configuration customization that is not encapsulated as part of a package upgrade.
Starting a fresh OSTree repo
If you want to start fresh with your own branch and/or versioning scheme, you can delete the OSTree repo created during the Photon 3.0 RPM-OSTree server install and re-create it empty.
root [ /srv/rpm-ostree ]# rm -rf repo/*
root [ /srv/rpm-ostree ]# ostree --repo=repo init --mode=archive-z2
root [ /srv/rpm-ostree ]# ls repo
config objects refs state tmp uncompressed-objects-cache
root [ /srv/rpm-ostree ]# cat repo/config
[core]
repo_version=1
mode=archive-z2
Creating summary metadata
A newer ostree feature, available in Photon OS 2.0 and higher, allows the OSTree server admin to create server summary metadata, that includes among other things the list of available branches and the list of static deltas, so they could be discovered by hosts. To create a summary, run this command after you committed for your branches:
root [ /srv/rpm-ostree ]# ostree summary -u "This is BigData's OSTree server, it has three branches"
We will find out later how the hosts query for branches list.
10 - Package Oriented Server Operations
Now that we have a Photon RPM-OSTree server up and running (if not, see how to install), we will learn how to provide the desired set of packages as input and instruct rpm-ostree to compose a filetree, that will result in creation (or update) of an OSTree repo.
The simplest way to explain is to take a look at the files installed by the Photon RPM-OSTree server during setup.
root [ ~ ]# cd /srv/rpm-ostree/
root [ /srv/rpm-ostree ]# ls -l
total 16
lrwxrwxrwx 1 root root 31 Aug 28 19:06 lightwave-ostree.repo -> /etc/yum.repos.d/lightwave.repo
-rw-r--r-- 1 root root 7356 Aug 28 19:06 ostree-httpd.conf
-rw-r--r-- 1 root root 1085 Aug 28 19:06 photon-base.json
lrwxrwxrwx 1 root root 35 Aug 28 19:06 photon-extras-ostree.repo -> /etc/yum.repos.d/photon-extras.repo
lrwxrwxrwx 1 root root 32 Aug 28 19:06 photon-iso-ostree.repo -> /etc/yum.repos.d/photon-iso.repo
lrwxrwxrwx 1 root root 28 Aug 28 19:06 photon-ostree.repo -> /etc/yum.repos.d/photon.repo
lrwxrwxrwx 1 root root 36 Aug 28 19:06 photon-updates-ostree.repo -> /etc/yum.repos.d/photon-updates.repo
drwxr-xr-x 7 root root 4096 Aug 20 22:27 repo
JSON configuration file
How can we tell rpm-ostree what packages we want to include, where to get them from and how to compose the filetree? There is JSON file for that. Let’s take a look at photon-base.json used by the Photon OS team.
root [ /srv/rpm-ostree ]# cat photon-base.json
{
"comment": "Photon Minimal OSTree",
"osname": "photon",
"ref": "photon/3.0/x86_64/minimal",
"automatic_version_prefix": "3.0_minimal",
"repos": ["photon"],
"selinux": false,
"initramfs-args": ["--no-hostonly"],
"bootstrap_packages": ["filesystem"],
"documentation": false,
"packages": ["glibc", "zlib", "binutils", "gmp", "mpfr", "libgcc", "libstdc++","libgomp",
"pkg-config", "ncurses", "bash", "bzip2", "cracklib", "cracklib-dicts", "shadow",
"procps-ng", "iana-etc", "readline", "coreutils", "bc", "libtool", "net-tools",
"findutils", "xz", "grub2", "grub2-pc", "grub2-efi", "iproute2", "util-linux", "linux",
"attr", "libcap", "kmod", "expat", "dbus", "file",
"sed", "grep", "cpio", "gzip",
"openssl", "ca-certificates", "curl",
"systemd",
"openssh", "iptables",
"photon-release",
"vim", "photon-repos",
"docker", "bridge-utils",
"dracut", "dracut-tools", "rpm-ostree", "nss-altfiles", "which"]
}
There are some mandatory settings, some optional. I’m only going to explain the most important ones for our use case.
osname and ref should be familiar, they have been explained in previous sections OSname and Refspec. Basicaly, we are asking rpm-ostree to compose a tree for photon OS and photon/3.0/x86_64/minimal branch.
For more information, see the OS Tree Documentation.
Package addition, removal, upgrade
packages is the list of packages that are to be added, in this case, in the “minimal” installation profile, on top of the packages already included by default. This is not quite the identical set of RPMS you get when you select the minimal profile in the ISO installer, but it’s pretty close and that’s why it’s been named the same.
Let’s add to the list three new packages: gawk, sudo and wget using vim photon-base.json
!!!Warning: do not remove any packages from the default list, even an “innocent” one, as it may bring the system to an unstable condition. During my testing, I’ve removed “which”; it turns out it was used to figure out the grub booting roots: on reboot, the system was left hanging at grub prompt.
RPMS repository
But where are these packages located? RPM-OStree uses the same standard RPMS repositories, that yum installs from.
root [ /srv/rpm-ostree ]# ls /etc/yum.repos.d/
photon-debuginfo.repo photon-extras.repo photon-iso.repo photon-updates.repo photon.repo
Going back to our JSON file, repos is a multi-value setting that tells RPM-OSTree in what RPMS repositories to look for packages. In this case, it looks in the current directory for a “photon” repo configuration file, that is a .repo file starting with a [photon] section. There is such a file: photon-ostree.repo, that is in fact a link to photon.repo in /etc/yum.repos.d directory.
root [ /srv/rpm-ostree ]# cat /etc/yum.repos.d/photon.repo
[photon]
name=VMware Photon Linux 3.0(x86_64)
baseurl=https://dl.bintray.com/vmware/photon_release_$releasever_$basearch
gpgkey=file:///etc/pki/rpm-gpg/VMWARE-RPM-GPG-KEY
gpgcheck=1
enabled=1
skip_if_unavailable=True
In this case, rpm-ostree is instructed to download its packages in RPM format from the bintray URL, that is the location of an online RPMS repo maintained by the WMware Photon OS team. To make sure those packages are genuine, signed by VMware, the signature is checked against the official VMware public key.
So what’s in an RPMS repository? If we point the browser to https://packages.vmware.com/photon/3.0/photon_updates_3.0_x86_64, we can see there are three top directories:
- noarch - where all packages that don’t depend on the architecture reside. Those may contain scripts, platform neutral source files, configuration.
- x86_64 - platform dependent packages for Intel 32 and 64 bits CPUs.
- repodata - internal repo management data, like a catalog of all packages, and for every package its name, id, version, architecture and full path file/directory list. There is also a compressed XML file containing the history of changelogs extracted from github, as packages in RPM format were built by Photon OS team members from sources.
Fortunately, in order to compose a tree, you don’t need to download the packages from the online repository (which is time consuming - in the order of minutes), unless there are some new ones or updated versions of them, added by the Photon team after shipping 1.0 version or the 1.0 Refresh. A copy of the starter RPMS repository (as of 1.0 shipping date) has been included on the CD-ROM and you can access it.
root [ /srv/rpm-ostree ]# mount /dev/cdrom
root [ /srv/rpm-ostree ]# ls /mnt/cdrom/RPMS
noarch repodata x86_64
All you have to do now is to replace the "repos": ["photon"] entry by "repos": ["photon-iso"], which will point to the RPMS repo on CD-ROM, rather than the online repo. This way, composing saves time, bandwidth and reduces to zero the risk of failure because of a networking issue.
root [ /srv/rpm-ostree ]# cat /etc/yum.repos.d/photon-iso.repo
[photon-iso]
name=VMWare Photon Linux ISO 3.0(x86_64)
baseurl=file:///mnt/cdrom/RPMS
gpgkey=file:///etc/pki/rpm-gpg/VMWARE-RPM-GPG-KEY
gpgcheck=1
enabled=0
skip_if_unavailable=True
There are already in current directory links created to all repositories in /etc/yum.repos.d, so they are found when tree compose command is invoked. You may add any other repo to the list and include packages found in that repo to be part of the image.
Composing a tree
After so much preparation, we can execute a tree compose. We have only added 3 new packages and changed the RPMS repo source. Assuming that the JSON file is editted, run the following:
root [ /srv/rpm-ostree ]# rpm-ostree compose tree --repo=repo photon-base.json
Previous commit: 2940e10c4d90ce6da572cbaeeff7b511cab4a64c280bd5969333dd2fca57cfa8
Downloading metadata [=========================================================================] 100%
Transaction: 117 packages
Linux-PAM-1.1.8-2.ph3.x86_64
attr-2.4.47-1.ph3.x86_64
...
gawk-4.1.0-2.ph3.x86_64
...
sudo-1.8.11p1-4.ph3.x86_64
...
wget-1.15-1.ph3.x86_64
which-2.20-1.ph3.x86_64
xz-5.0.5-2.ph3.x86_64
zlib-1.2.8-2.ph3.x86_64
Installing packages [==========================================================================] 100%
Writing '/var/tmp/rpm-ostree.TVO089/rootfs.tmp/usr/share/rpm-ostree/treefile.json'
Preparing kernel
Creating empty machine-id
Executing: /usr/bin/dracut -v --tmpdir=/tmp -f /var/tmp/initramfs.img 4.0.9 --no-hostonly
...
*** Including module: bash ***
*** Including module: kernel-modules ***
*** Including module: resume ***
*** Including module: rootfs-block ***
*** Including module: terminfo ***
*** Including module: udev-rules ***
Skipping udev rule: 91-permissions.rules
Skipping udev rule: 80-drivers-modprobe.rules
*** Including module: ostree ***
*** Including module: systemd ***
*** Including module: usrmount ***
*** Including module: base ***
/etc/os-release: line 1: Photon: command not found
*** Including module: fs-lib ***
*** Including module: shutdown ***
*** Including modules done ***
*** Installing kernel module dependencies and firmware ***
*** Installing kernel module dependencies and firmware done ***
*** Resolving executable dependencies ***
*** Resolving executable dependencies done***
*** Stripping files ***
*** Stripping files done ***
*** Store current command line parameters ***
*** Creating image file ***
*** Creating image file done ***
Image: /var/tmp/initramfs.img: 11M
========================================================================
Version: dracut-041-1.ph3
Arguments: -v --tmpdir '/tmp' -f --no-hostonly
dracut modules:
bash
kernel-modules
resume
rootfs-block
terminfo
udev-rules
ostree
systemd
usrmount
base
fs-lib
shutdown
========================================================================
drwxr-xr-x 12 root root 0 Sep 1 00:52 .
crw-r--r-- 1 root root 5, 1 Sep 1 00:52 dev/console
crw-r--r-- 1 root root 1, 11 Sep 1 00:52 dev/kmsg
... (long list of files removed)
========================================================================
Initializing rootfs
Migrating /etc/passwd to /usr/lib/
Migrating /etc/group to /usr/lib/
Moving /usr to target
Linking /usr/local -> ../var/usrlocal
Moving /etc to /usr/etc
Placing RPM db in /usr/share/rpm
Ignoring non-directory/non-symlink '/var/tmp/rpm-ostree.TVO089/rootfs.tmp/var/lib/nss_db/Makefile'
Ignoring non-directory/non-symlink '/var/tmp/rpm-ostree.TVO089/rootfs.tmp/var/cache/ldconfig/aux-cache'
Ignoring non-directory/non-symlink '/var/tmp/rpm-ostree.TVO089/rootfs.tmp/var/log/btmp'
Ignoring non-directory/non-symlink '/var/tmp/rpm-ostree.TVO089/rootfs.tmp/var/log/lastlog'
Ignoring non-directory/non-symlink '/var/tmp/rpm-ostree.TVO089/rootfs.tmp/var/log/wtmp'
Moving /boot
Using boot location: both
Copying toplevel compat symlinks
Adding tmpfiles-ostree-integration.conf
Committing '/var/tmp/rpm-ostree.TVO089/rootfs.tmp' ...
photon/1.0/x86_64/minimal => c505f4bddb4381e8b5213682465f1e5bb150a18228aa207d763cea45c6a81bbe
I’ve cut a big part of logging, but as you can see, the new filetree adds to the top of the previous (initial) commit 2940e10c4d and produces a new commit c505f4bddb. Our packages gawk-4.1.0-2.ph3.x86_64, sudo-1.8.11p1-4.ph3.x86_64 and wget-1.15-1.ph3.x86_64 have been added.
During compose, rpm-ostree checks out the file tree into its uncompressed form, applies the package changes, places the updated RPM repo into /usr/share/rpm and calls ostree to commit its changes back into the OSTree repo. If we were to look at the temp directory during this time:
root [ /srv/rpm-ostree ]# ls /var/tmp/rpm-ostree.TVO089/rootfs.tmp
bin dev lib media opt proc run srv sysroot usr
boot home lib64 mnt ostree root sbin sys tmp var
If we repeat the command, and there is no change in the JSON file settings and no change in metadata, rpm-ostree will figure out that nothing has changed and stop. You can force however to redo the whole composition.
root [ /srv/rpm-ostree ]# rpm-ostree compose tree --repo=repo photon-base.json
Previous commit: c505f4bddb4381e8b5213682465f1e5bb150a18228aa207d763cea45c6a81bbe
Downloading metadata [=========================================================================] 100%
No apparent changes since previous commit; use --force-nocache to override
This takes several minutes. Then why is the RPM-OSTree server installing so fast, in 45 seconds on my SSD? The server doesn’t compose the tree, it uses a pre-created OSTree repo that is stored on the CD-ROM. It comes of course at the expense of larger CD-ROM size. This OSTree repo is created from the same set of RPMS on the CD-ROM, so if you compose fresh, you will get the same exact tree, with same commit ID for the “minimal” ref.
Automatic version prefix
If you recall the filetree version explained earlier, this is where it comes into play. When a tree is composed from scratch, the first version (0) associated to the initial commit is going to get that human readable value. Any subsequent compose operation will auto-increment to .1, .2, .3 and so on.
It’s a good idea to start a versionning scheme of your own, so that your customized Photon builds that may get different packages of your choice don’t get the same version numbers as the official Photon team builds, coming from VMware’s bintray OSTree repository. There is no conflict, it’s just confusing to have same name for different commits coming from different repos,
So if you work for a company named Big Data Inc., you may want to switch to a new versioning scheme "automatic_version_prefix": "1.0_bigdata".
Installing package updates
If you want to provide hosts with the package updates that VMware periodically releases, all that you need to do is to add the photon-updates.repo to the list of repos in photon-base.json and then re-compose the usual way.
"repos": ["photon", "photon-updates"],
Even though you may have not modified the “packages” section in the json file, the newer versions of existing packages will be included in the new image and then downloaded by the host the usual way. Note that upgrading a package shows differently than adding (+) or removing (-). You may still see packages added (or removed) though because they are new dependencies (or no longer dependencies) for the newer versions of other packages, as libssh2 in the example below.
root [ ~ ]# rpm-ostree upgrade --check-diff
Updating from: photon:photon/3.0/x86_64/minimal
8 metadata, 13 content objects fetched; 1002 KiB transferred in 0 seconds
!bridge-utils-1.5-2.ph3.x86_64
=bridge-utils-1.5-3.ph3.x86_64
!bzip2-1.0.6-5.ph3.x86_64
=bzip2-1.0.6-6.ph3.x86_64
!curl-7.47.1-2.ph3.x86_64
=curl-7.51.0-2.ph3.x86_64
!docker-1.11.0-5.ph3.x86_64
=docker-1.12.1-1.ph3.x86_64
...
+libssh2-1.8.0-1.ph3.x86_64
...
root [ ~ ]# rpm-ostree upgrade
Updating from: photon:photon/1.0/x86_64/minimal
258 metadata, 1165 content objects fetched; 76893 KiB transferred in 8 seconds
Copying /etc changes: 6 modified, 0 removed, 14 added
Transaction complete; bootconfig swap: yes deployment count change: 1
Changed:
bridge-utils 1.5-2.ph3 -> 1.5-3.ph3
bzip2 1.0.6-5.ph3 -> 1.0.6-6.ph3
curl 7.47.1-2.ph3 -> 7.51.0-2.ph3
docker 1.11.0-5.ph3 -> 1.12.1-1.ph3
...
Added:
libssh2-1.8.0-1.ph3.x86_64
Upgrade prepared for next boot; run "systemctl reboot" to start a reboot
Now if we want to see what packages have been updated and what issues have been fixed, just run at the host the command that we learned about in chapter 5.4.
root [ ~ ]# rpm-ostree db diff 56ef 396e
ostree diff commit old: 56e (56ef687f1319604b7900a232715718d26ca407de7e1dc89251b206f8e255dcb4)
ostree diff commit new: 396 (396e1116ad94692b8c105edaee4fa12447ec3d8f73c7b3ade4e955163d517497)
Upgraded:
bridge-utils-1.5-3.ph3.x86_64
* Mon Sep 12 2016 Alexey Makhalov <amakhalov@vmware.com> 1.5-3
- Update patch to fix-2.
bzip2-1.0.6-6.ph3.x86_64
* Fri Oct 21 2016 Kumar Kaushik <kaushikk@vmware.com> 1.0.6-6
- Fixing security bug CVE-2016-3189.
curl-7.51.0-2.ph3.x86_64
* Wed Nov 30 2016 Xiaolin Li <xiaolinl@vmware.com> 7.51.0-2
- Enable sftp support.
* Wed Nov 02 2016 Anish Swaminathan <anishs@vmware.com> 7.51.0-1
- Upgrade curl to 7.51.0
* Thu Oct 27 2016 Anish Swaminathan <anishs@vmware.com> 7.47.1-4
- Patch for CVE-2016-5421
* Mon Sep 19 2016 Xiaolin Li <xiaolinl@vmware.com> 7.47.1-3
- Applied CVE-2016-7167.patch.
docker-1.12.1-1.ph3.x86_64
* Wed Sep 21 2016 Xiaolin Li <xiaolinl@vmware.com> 1.12.1-1
- Upgraded to version 1.12.1
* Mon Aug 22 2016 Alexey Makhalov <amakhalov@vmware.com> 1.12.0-2
- Added bash completion file
* Tue Aug 09 2016 Anish Swaminathan <anishs@vmware.com> 1.12.0-1
- Upgraded to version 1.12.0
* Tue Jun 28 2016 Anish Swaminathan <anishs@vmware.com> 1.11.2-1
- Upgraded to version 1.11.2
...
Added:
libssh2-1.8.0-1.ph3.x86_64
Composing for a different branch
RPM-OSTree makes it very easy to create and update new branches, by composing using json config files that include the Refspec as the new branch name, the list of packages and the other settings we are now familiar with. Photon OS 2.0 RPM-OSTRee Server installer adds two extra files photon-minimal.json and photon-full.json in addition to photon-base.json, that correspond almost identically to the minimal and full profiles installed via tdnf. It also makes ‘photon-base’ a smaller set of starter branch.
Of course, you can create your own config files for your branches with desired lists of packages. You may compose on top of the existing tree, or you can start fresh your own OSTRee repo, using your own customized versioning.
11 - Remotes
In Chapter 3 we talked about the Refspec that contains a photon: prefix, that is the name of a remote. When a Photon host is installed, a remote is added - which contains the URL for an OSTree repository that is the origin of the commits we are going to pull from and deploy filetrees, in our case the Photon RPM-OSTree server we installed the host from. This remote is named photon, which may be confusing, because it’s also the OS name and part of the Refspec (branch) path.
Listing remotes
A host repo can be configured to switch between multiple remotes to pull from, however only one remote is the “active” one at a time. We can list the remotes created so far, which brings back the expected result.
root@photon-host-def [ ~ ]# ostree remote list
photon
photon-1
We can inquiry about the URL for that remote name, which for the default host is the expected Photon OS online OSTree repo.
root@photon-host-def [ ~ ]# ostree remote show-url photon
https://<host-name>:8080/repo
But where is this information stored? The repo’s config file has it.
root@photon-host-def [ ~ ]# cat /ostree/repo/config
[core]
repo_version=1
mode=bare
[remote "photon"]
url=http:<Server-IP-Address:port>/repo
gpg-verify=false
If same command is executed on the custom host we’ve installed, it’s going to reveal the URL of the Photon RPM-OSTree server connected to during setup.
root@photon-host-cus [ ~ ]# ostree remote show-url photon
http://10.197.103.175:8000/repo
GPG signature verification
You may wonder what is the purpose of gpg-verify=false in the config file, associated with the specific remote. This will instruct any host update to skip the signing verification for the updates that come from server, resulted from tree composed locally at the server, as they are not signed. Without this, host updating will fail.
There is a whole chapter about signing, importing keys and so on that I will not get into, but the idea is that signing adds an extra layer of security, by validating that everything you download comes from the trusted publisher and has not been altered. That is the case for all Photon OS artifacts downloaded from VMware official site. All OVAs and packages, either from the online RPMS repositories or included in the ISO file - are signed by VMware. We’ve seen a similar setting gpgcheck=1 in the RPMS repo configuration files that tdnf uses to validate or not the signature for all packages downloaded to be installed.
Switching repositories
Since mapping name/url is stored in the repo’s config file, in principle you can re-assign a different URL, connecting the host to a different server. The next upgrade will get the latest commit chain from the new server.
If we edit photon-host-def’s repo config and replace the bintray URL by photon-srv1’s IP address, all original packages in the original 3.0_minimal version will be preserved, but any new package change (addition, removal, upgrade) added after that (in 3.0_minimal.1, 3.0_minimal.2) will be reverted and all new commits from photon-srv1 (that may have same version) will be applied. This is because the two repos are identical copies, so they have the same original commit ID as a common ancestor, but they diverge from there.
If the old and new repo have nothing in common (no common ancestor commit), this will undo even the original commit, so all commits from the new tree will be applied.
A better solution would be to add a new remote that will identify where the commits come from.
Adding and removing remotes
A cleaner way to switch repositories is to add remotes that point to different servers. Let us add another server that we will refer to as photon2, along with (optional) the refspecs for branches that it provides (we will see later that in the newer OSTree versions, we don’t need to know the branch names, they could be queried at run-time).
root@photon-host-cus [ ~ ]# ostree remote add --repo=/ostree/repo -v --no-gpg-verify photon2 http://10.197.103.204:8080 photon/3.0/x86_64/minimal photon/3.0/x86_64/full
root@photon-host-cus [ ~ ]# ostree remote list
photon
photon2
root@photon-host-cus [ ~ ]# ostree remote show-url photon2
http://10.118.101.86
Where is this information stored? There is an extra config file created per each remote:
root@photon-host-cus [ ~ ]# cat /etc/ostree/remotes.d/photon2.conf
[remote "photon2"]
url=http://10.118.101.86
branches=photon/3.0/x86_64/minimal;photon/2.0/x86_64/full;
gpg-verify=false
You may have guessed what is the effect of --no-gpg-verify option.
Obviously, remotes could also be deleted.
root@photon-host-cus [ ~ ]# ostree remote delete photon2
root@photon-host-cus [ ~ ]# ostree remote list
photon
List available branches
If a host has been deployed from a specific branch and would like to switch to a different one, maybe from a different server, how would it know what branches are available? In git, you would run git remote show origin or git remote -a (although last command would not show all branches, unless you ran git fetch first).
Fortunately, in Photon OS 3.0 and higher, the hosts are able to query the server, if summary metadata has been generated, as we’ve seen in Creating summary metadata. This command lists all branches available for remote photon2.
root@photon-host-cus [ ~ ]# ostree remote refs photon2
photon2:photon/3.0/x86_64/base
photon2:photon/3.0/x86_64/full
photon2:photon/3.0/x86_64/minimal
Switching branches (rebasing)
If you have an installed Photon 1.0 or 1.0 Rev2 that you want to carry to 3.0, you need to rebase it.
12 - Running container applications between bootable images
In this chapter, we want to test a docker application and make sure that all the settings and downloads done in one bootable filetree are going to be saved into writable folders and be available in the other image, in other words after reboot from the other image, everything is available exactly the same way.
We are going to do this twice: first, to verify an existing bootable image installed in parallel and then create a new one.
Downloading a docker container appliance
Photon OS comes with docker package installed and configured, but we expect that the docker daemon is inactive (not started). Configuration file /usr/lib/systemd/system/docker.service is read-only (remember /usr is bound as read-only).
root@sample-host-def [ ~ ]# systemctl status docker
* docker.service - Docker Daemon
Loaded: loaded (/usr/lib/systemd/system/docker.service; disabled)
Active: inactive (dead)
root@sample-host-def [ ~ ]# cat /usr/lib/systemd/system/docker.service
[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network-online.target
Wants=network-online.target
[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
ExecStart=/usr/bin/dockerd
ExecReload=/bin/kill -s HUP $MAINPID
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity
# Uncomment TasksMax if your systemd version supports it.
# Only systemd 226 and above support this version.
#TasksMax=infinity
TimeoutStartSec=0
# set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes
# kill only the docker process, not all processes in the cgroup
KillMode=process
# restart the docker process if it exits prematurely
Restart=on-failure
StartLimitBurst=3
StartLimitInterval=60s
[Install]
WantedBy=multi-user.target
Now let’s enable docker daemon to start at boot time - this will create a symbolic link into writable folder /etc/systemd/system/multi-user.target.wants to its systemd configuration, as with all other systemd controlled services.
root@sample-host-def [ ~ ]# systemctl enable docker
Created symlink /etc/systemd/system/multi-user.target.wants/docker.service -> /lib/systemd/system/docker.service.
root@sample-host-def [ ~ ]# ls -l /etc/systemd/system/multi-user.target.wants
total 0
lrwxrwxrwx 1 root root 34 Sep 10 10:48 docker.service -> /lib/systemd/system/docker.service
lrwxrwxrwx 1 root root 36 Sep 4 04:59 iptables.service -> /lib/systemd/system/iptables.service
lrwxrwxrwx 1 root root 35 Sep 4 04:59 machines.target -> /lib/systemd/system/machines.target
lrwxrwxrwx 1 root root 36 Sep 4 04:59 remote-fs.target -> /lib/systemd/system/remote-fs.target
lrwxrwxrwx 1 root root 39 Sep 4 04:59 sshd-keygen.service -> /lib/systemd/system/sshd-keygen.service
lrwxrwxrwx 1 root root 32 Sep 4 04:59 sshd.service -> /lib/systemd/system/sshd.service
lrwxrwxrwx 1 root root 44 Sep 4 04:59 systemd-networkd.service -> /lib/systemd/system/systemd-networkd.service
lrwxrwxrwx 1 root root 44 Sep 4 04:59 systemd-resolved.service -> /lib/systemd/system/systemd-resolved.service
To verify that the symbolic link points to a file in a read-only directory, try to make a change in this file using vim and save. you’ll get an error: “/usr/lib/systemd/system/docker.service” E166: Can’t open linked file for writing".
Finally, let’s start the daemon, check again that is active.
root@sample-host-def [ ~ ]# systemctl start docker
root@sample-host-def [ ~ ]# systemctl status -l docker
* docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2019-09-10 10:54:32 UTC; 14s ago
Docs: https://docs.docker.com
Main PID: 2553 (dockerd)
Tasks: 35 (limit: 4711)
Memory: 148.2M
CGroup: /system.slice/docker.service
|-2553 /usr/bin/dockerd
`-2566 docker-containerd --config /var/run/docker/containerd/containerd.toml
Sep 10 10:54:31 photon-76718dd2fa33 dockerd[2553]: time="2019-09-10T10:54:31.421759662Z" level=info msg="pickfirstBalancer: HandleSubConnStateChange: 0xc420312f90, CONNECTING" module=grpc
Sep 10 10:54:31 photon-76718dd2fa33 dockerd[2553]: time="2019-09-10T10:54:31.421935355Z" level=info msg="pickfirstBalancer: HandleSubConnStateChange: 0xc420312f90, READY" module=grpc
Sep 10 10:54:31 photon-76718dd2fa33 dockerd[2553]: time="2019-09-10T10:54:31.421980614Z" level=info msg="Loading containers: start."
Sep 10 10:54:31 photon-76718dd2fa33 dockerd[2553]: time="2019-09-10T10:54:31.886520281Z" level=info msg="Default bridge
(docker0) is assigned with an IP address 172.17.0.0/16. Daemon option --bip can be used to set a preferred IP address"
Sep 10 10:54:32 photon-76718dd2fa33 dockerd[2553]: time="2019-09-10T10:54:32.027763113Z" level=info msg="Loading containers: done."
Sep 10 10:54:32 photon-76718dd2fa33 dockerd[2553]: time="2019-09-10T10:54:32.468277184Z" level=info msg="Docker daemon"
commit=6d37f41 graphdriver(s)=overlay2 version=18.06.2-ce
Sep 10 10:54:32 photon-76718dd2fa33 dockerd[2553]: time="2019-09-10T10:54:32.468441587Z" level=info msg="Daemon has completed initialization"
Sep 10 10:54:32 photon-76718dd2fa33 dockerd[2553]: time="2019-09-10T10:54:32.684925824Z" level=warning msg="Could not register builder git source: failed to find git binary: exec: \"git\": executable file not found in $PATH"
Sep 10 10:54:32 photon-76718dd2fa33 dockerd[2553]: time="2019-09-10T10:54:32.691070166Z" level=info msg="API listen on /var/run/docker.sock"
Sep 10 10:54:32 photon-76718dd2fa33 systemd[1]: Started Docker Application Container Engine.
We’ll ask docker to run Ubuntu Linux in a container. Since it’s not present locally, it’s going to be downloaded first from the official docker repository https://hub.docker.com/_/ubuntu/.
root@sample-host-def [ ~ ]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
root@sample-host-def [ ~ ]# docker run -it ubuntu
Unable to find image 'ubuntu:latest' locally
latest: Pulling from library/ubuntu
35c102085707: Pull complete
251f5509d51d: Pull complete
8e829fe70a46: Pull complete
6001e1789921: Pull complete
Digest: sha256:d1d454df0f579c6be4d8161d227462d69e163a8ff9d20a847533989cf0c94d90
Status: Downloaded newer image for ubuntu:latest
When downloading is complete, it comes to Ubuntu root prompt with assigned host name 7029a64e7aa3, that is actually the Container ID. Let’s verify it’s indeed the expected OS.
root@sample-host-def [ ~ ]# docker run -it ubuntu
Unable to find image 'ubuntu:latest' locally
latest: Pulling from library/ubuntu
d3a1f33e8a5a: Pull complete
c22013c84729: Pull complete
d74508fb6632: Pull complete
91e54dfb1179: Already exists
library/ubuntu:latest: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provide security.
Digest: sha256:fde8a8814702c18bb1f39b3bd91a2f82a8e428b1b4e39d1963c5d14418da8fba
Status: Downloaded newer image for ubuntu:latest
root@7029a64e7aa3:/# cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.3 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.3 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic
root@7029a64e7aa3:/#
Now let’s write a file into Ubuntu home directory
echo "Ubuntu file" >> /home/myfile
root@7029a64e7aa3:/home# cat /home/myfile
Ubuntu file
We’ll exit back to the Photon prompt and if it’s stopped, we will re-start it.
root@7029a64e7aa3:/# exit
exit
root@sample-host-def [ ~ ]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7029a64e7aa3 ubuntu "/bin/bash" 6 minutes ago Exited (0) 11 seconds ago gifted_dijkstra
root@photon-host-cus1 [ ~ ]# docker start 7029a64e7aa3
7029a64e7aa3
root@photon-host-cus1 [ ~ ]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7029a64e7aa3 ubuntu "/bin/bash" 7 minutes ago Up 21 seconds gifted_dijkstra
Rebooting into an existing image
Now let’s reboot the machine and select the other image. First, we’ll verify that the docker daemon is automaically started.
root@photon-host-cus1 [ ~ ]# systemctl status docker
* docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2019-09-10 10:54:32 UTC; 13min ago
Docs: https://docs.docker.com
Main PID: 2553 (dockerd)
Tasks: 55 (limit: 4711)
Memory: 261.3M
CGroup: /system.slice/docker.service
|-2553 /usr/bin/dockerd
...
Next, is the Ubuntu OS container still there?
root@photon-host-cus1 [ ~ ]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7029a64e7aa3 ubuntu "/bin/bash" 9 minutes ago Up 2 minutes gifted_dijkstra
It is, so let’s start it, attach and verify that our file is persisted, then add another line to it and save, exit.
root@photon-host-cus1 [ ~ ]# docker start -i 7029a64e7aa3
root@7029a64e7aa3:/# cat /home/myfile
Ubuntu file
root@7029a64e7aa3:/# echo "booted into existing image" >> /home/myfile
root@7029a64e7aa3:/# exit
exit
Reboot into a newly created image
Let’s upgrade and replace the .0 image by a .3 build that contains git and also perl_YAML (because it is a dependency of git).
root@photon-host-cus1 [ ~ ]# rpm-ostree status
TIMESTAMP (UTC) VERSION ID OSNAME REFSPEC
* 2015-09-04 00:36:37 3.0_tp2_minimal.2 092e21d292 photon photon:photon/tp2/x86_64/minimal
2015-08-20 22:27:43 3.0_tp2_minimal 2940e10c4d photon photon:photon/tp2/x86_64/minimal
root@photon-host-cus1 [ ~ ]# rpm-ostree upgrade
Updating from: photon:photon/tp2/x86_64/minimal
43 metadata, 209 content objects fetched; 19992 KiB transferred in 0 seconds
Copying /etc changes: 5 modified, 0 removed, 19 added
Transaction complete; bootconfig swap: yes deployment count change: 0
Freed objects: 16.2 MB
Added:
git-2.1.2-1.ph3tp2.x86_64
perl-YAML-1.14-1.ph3tp2.noarch
Upgrade prepared for next boot; run "systemctl reboot" to start a reboot
root@photon-host-cus1 [ ~ ]# rpm-ostree status
TIMESTAMP (UTC) VERSION ID OSNAME REFSPEC
2015-09-06 18:12:08 3.0_tp2_minimal.3 d16aebd803 photon photon:photon/tp2/x86_64/minimal
* 2015-09-04 00:36:37 3.0_tp2_minimal.2 092e21d292 photon photon:photon/tp2/x86_64/minimal
After reboot from 3.0_tp2_minimal.3 build, let’s check that the 3-way /etc merge succeeded as expected. The docker.service slink is still there, and docker demon restarted at boot.
root@photon-host-cus1 [ ~ ]# ls -l /etc/systemd/system/multi-user.target.wants/docker.service
lrwxrwxrwx 1 root root 38 Sep 6 12:50 /etc/systemd/system/multi-user.target.wants/docker.service -> /usr/lib/systemd/system/docker.service
root@photon-host-cus1 [ ~ ]# systemctl status docker
* docker.service - Docker Daemon
Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled)
Active: active (running) since Sun 2015-09-06 12:56:33 UTC; 1min 27s ago
Main PID: 292 (docker)
CGroup: /system.slice/docker.service
`-292 /bin/docker -d -s overlay
...
Let’s revisit the Ubuntu container. Is the container still there? is myfile persisted?
root@photon-host-cus1 [ ~ ]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7029a64e7aa3 ubuntu "/bin/bash" 5 days ago Exited (0) 5 days ago gifted_dijkstra
55825c961f95 ubuntu "/bin/bash" 5 days ago Exited (127) 5 days ago distracted_shannon
root@photon-host-cus1 [ ~ ]# docker start 57dcac5d0490
root@57dcac5d0490:/# cat /home/myfile
Ubuntu file
booted into existing image
root@57dcac5d0490:/# echo "booted into new image" >> /home/myfile
13 - Install or rebase to Photon OS 3.0
Photon OS 3.0 provides full RPM-OSTree functionality, it lets the user drive it, rather than provide a pre-defined solution as part of the installation.
The number of packages included in the RPMS repo in Photon OS 3.0 increased significantly, compared to 1.0. To keep the ISO at reasonable size, Photon OS 2.0 no longer includes the compressed ostree.repo file, that helped optimize both the server and host install in 1.0 or 1.0 Rev2. That decision affected the OSTree features we ship out of the box. Customer could achieve the same results by several additional simple steps, that will be explained in this chapter. In addition, there is a new way to create a host raw image at server.
Composing your own RPM-OSTree Server
You can compose your own RPM-OSTRee server in the following two ways:
By Manually executing the below command:
root [ /srv/rpm-ostree ]# ostree --repo=repo init --mode=archive-z2 root [ /srv/rpm-ostree ]# rpm-ostree compose tree --repo=repo photon-base.jsonBy installing
rpm-ostree-repo package. This provides the script to create the repo tree which act as server by executing a single command.
Installing an RPM-OSTree host
Automated host install is supported, as explained in Chapter 7.2 Automated install of a custom host via kickstart.
Rebasing a host from Photon 1.0 to 3.0
If kickstart sounds too complicated and we still want to go the UI way there is a workaround that requires an extra step. Also, if you have an installed Photon 1.0 or 1.0 Rev2 that you want to carry to 3.0, you need to rebase it. Notice that I didn’t say “upgrade”.
Basically the OSTree repo will switch to a different branch on a different server, following the new server’s branch versioning scheme. The net result is that the lots of packages will get changed to newer versions from newer OSTree repo, that has been composed from a newer Photon OS 3.0 RPMS repo. Again, I didn’t say “upgraded”, neither the rebase command output, that lists “changed” packages. Some obsolete packages will be removed, new packages will be added, either because they didn’t exist in 2.0 repo, or because the new config file includes them.
The OS name is the same (Photon), so the content in /var and /etc will be transferred over.
To install fresh, deploy a Photon 1.0 Rev2 host default, as described in Chapter 2. Of course, if you already have an existing Photon OS 1.0 host that you want to move to 2.0, skip this step.
Edit /ostree/repo/config and substitute the url, providing the IP address for the Photon OS 2.0 RPM-OSTree server installed above. This was explained in Chapter 10.
ostree should confirm that is the updated server IP for the “photon” remote.root@ostree-host [ ~ ]# ostree remote show-url photon http://10.197.103.175:8000/repoRebase your host to the new 2.0 server and Refspec.
root@ostree-host [ ~ ]# ostree remote add photon-2 http://10.197.103.204:8000/repo --no-gpg-verify root@ostree-host [ ~ ]# rpm-ostree rebase photon-2:photon/3.0/x86_64/minimal Rebasing to photon-2:photon/3.0/x86_64/minimal ⠉ Receiving objects: 99% (1541/1549) 478.3 kB/s 107.1 MB Receiving objects: 99% (1541/1549) 478.3 kB/s 107.1 MB... done Staging deployment... done Upgraded: docker 18.06.2-3.ph3 -> 18.06.2-4.ph3 gmp 6.1.2-2.ph3 -> 6.1.2-3.ph3 gobject-introspection 1.58.0-2.ph3 -> 1.58.0-3.ph3 gzip 1.9-1.ph3 -> 1.9-2.ph3 linux 4.19.65-3.ph3 -> 4.19.69-1.ph3 mpfr 4.0.1-1.ph3 -> 4.0.1-2.ph3 ostree 2019.2-1.ph3 -> 2019.2-2.ph3 ostree-grub2 2019.2-1.ph3 -> 2019.2-2.ph3 ostree-libs 2019.2-1.ph3 -> 2019.2-2.ph3 zlib 1.2.11-1.ph3 -> 1.2.11-2.ph3 Added: efibootmgr-15-1.ph3.x86_64 efivar-36-1.ph3.x86_64 tar-1.30-3.ph3.x86_64 Run "systemctl reboot" to start a rebootCheck the status
root@ostree-host [ ~ ]# rpm-ostree status State: idle AutomaticUpdates: disabled Deployments: * ostree://photon-1:photon/3.0/x86_64/minimal Version: 3.0_minimal.2 (2019-09-18T08:22:15Z) BaseCommit: c8f2b116b067d7695f9033bf2a99505198269354e157c0f2d5b78266cb874239 LayeredPackages: createrepo_c rpm wget ostree://photon:photon/1.0/x86_64/minimal Version: 1.0_minimal.1 (2017-01-11T02:18:42) BaseCommit: 28dc49ecb4604c0bc349e4445adc659491a1874c01198e6253a261f4d59708b7 LayeredPackages: createrepo_c rpm wget
You may now reboot to the new Photon OS 3.0 image.
Creating a host raw image
It is now possible to run at server a script that is part of RPM-OStree package, to create a host raw mage.