What can be rebased?

General
1

Hi!

I am new to Universal Blue and it seems like a lot of people here I am also trying to reproduce the use-case I currently have for NixOS in UBlue.

At the moment, I am playing with bazzite; but I belive my question is probably valid for the Silverblue/Kinoite rebase process in general.

I would like to setup an image that is already configured for my network. Specifically, I would like it already joined to my ldap server and have some basic software available after rebase, so that I can keep that part of the image updated for my family.

I have been successful in creating an image which has the appropriate sssd.conf entries, but authselect doesn’t seem to configure in the container and flatpak runs, but added apps in the container do not get rebased into the running machine.

I expected that some of this wouldn’t work, but I was wondering:

  1. Where is the line drawn between what is taken from the container image and what is not?
  2. Has someone come up with a way to run one time configuration commands like authselect from the image?
  3. Has someone come up with a way to preinstall some flatpaks from the image?

I expect some of this could be done with a one-shot service, but I don’t know what the full ramifications of that would be through the whole lifecycle.

Here is what I was attempting:

Containerfile:

ARG SOURCE_IMAGE="bazzite"
ARG SOURCE_SUFFIX=""
ARG SOURCE_TAG="latest"

FROM ghcr.io/ublue-os/${SOURCE_IMAGE}${SOURCE_SUFFIX}:${SOURCE_TAG}

# I have directories here for /etc/pki, /etc/sssd, and /etc/sudoers.d
# This part works!
ADD etc /etc
RUN chmod 600 /etc/sssd/sssd.conf
RUN update-ca-trust

ADD home /home
RUN chmod 600 /home/admin_user/.ssh/authorized_keys

# Not sure what I was hoping for here, but left it commented in case...
# RUN echo "" >> /etc/hosts
# RUN echo "127.0.0.2 $HOSTNAME.$HOSTDOMAIN $HOSTNAME" >> /etc/hosts
# RUN echo "::1 $HOSTNAME.$HOSTDOMAIN $HOSTNAME" >> /etc/hosts
# RUN echo hostnamectl hostname --static $HOSTNAME

COPY build.sh /tmp/build.sh

RUN mkdir -p /var/lib/alternatives && \
    /tmp/build.sh && \
    ostree container commit
## NOTES:

build.sh:

#!/bin/bash

set -ouex pipefail

RELEASE="$(rpm -E %fedora)"


### Install packages

# Packages can be installed from any enabled yum repo on the image.
# RPMfusion repos are available by default in ublue main images
# List of rpmfusion packages can be found here:
# https://mirrors.rpmfusion.org/mirrorlist?path=free/fedora/updates/39/x86_64/repoview/index.html&protocol=https&redirect=1

# this installs a package from fedora repos
rpm-ostree install sssd-ldap oddjob-mkhomedir

# this would install a package from rpmfusion
# rpm-ostree install vlc

# This doesn't seem to take effect on rebase!
authselect select sssd with-mkhomedir

# This actually does add to the container image, but does not rebase.
# Flatpak install
flatpak remote-add --if-not-exists --system flathub /usr/etc/flatpak/remotes.d/flathub.flatpakrepo
flatpak remote-modify --system --enable flathub
flatpak --system -y install --or-update com.nextcloud.desktopclient.nextcloud

systemctl enable sshd
systemctl enable sssd
systemctl enable oddjobd
systemctl enable podman.socket

Thanks for any help in aiding my understanding of this.

2

I found this:

and it helped quite a bit.

I reorganized to follow the ostree container commit rule more closely and created a second script after build.sh to put my commands in that required the rpm’s which where being installed in build.sh

It seems /etc/pam.d changes don’t get pulled into the rebase even though according to this documentation they should.

I ran my container and verified that /etc/pam.d/system-auth had been correctly changed in the container, but that change is not applying through rpm-ostree.

3

In bluefin and bazzite we do oneshot service units that run on first boot. Right now we don’t really have a way to do that in the image afaict.

For flatpaks, we bundle that in the ISOs. Flatpak is working on a preinstall feature that should make that easier, here’s a link to that issue (looking forward to this one!):

1 Like
4

I added a bug for the authselect issue, but I’m sure I’ll probably find out I was doing something wrong.

1 Like
5

There is a line between what you can do at build time vs a booted system.

At build time you cannot persist changes to /var and /opt and not everything in /etc persists.

The workaround we use is systems oneshot services and a stamp/sentinel file for setting things up on a booted system.

1 Like
6

I have been doing some reading in the docs and source. It seems that rpm-ostree will never update a file in /etc which doesn’t already match the previous state.

This makes me believe that perhaps the reason that authselect doesn’t work on containers derived from ucore or bazzite is because at some stage ucore and bazzite have already run authselect. (BTW while messing with this I also noticed that setting the hostname in bazzite’s installer doesn’t actually set the hostname)

Does anyone know of a way to get /etc files which have deviated changes back to the correct state so that rebase/update will affect them?

7

Delete the file and then copy from /user/etc

1 Like