# What can be rebased? **URL:** \ **Category:** General\ **Created:** [June 20, 2024, 10:52pm UTC](https://universal-blue.discourse.group/t/what-can-be-rebased/2425 "2024-06-20T22:52:59Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![genson](https://avatars.discourse-cdn.com/v4/letter/g/e480ec/32.png) [@genson](https://universal-blue.discourse.group/u/genson)\ **Post date:** [June 20, 2024, 10:52pm UTC](https://universal-blue.discourse.group/t/what-can-be-rebased/2425/1 "2024-06-20T22:52:59Z")
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: ```auto 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: ```auto #!/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. ---
**Author:** ![genson](https://avatars.discourse-cdn.com/v4/letter/g/e480ec/32.png) [@genson](https://universal-blue.discourse.group/u/genson)\ **Post date:** [June 21, 2024, 11:17am UTC](https://universal-blue.discourse.group/t/what-can-be-rebased/2425/2 "2024-06-21T11:17:24Z")
I found this: > **[ostree native containers](https://coreos.github.io/rpm-ostree/container/)** > > rpm-ostree documentation 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. ---
**Author:** ![j0rge](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/j0rge/32/8_2.png) [@j0rge](https://universal-blue.discourse.group/u/j0rge)\ **Post date:** [June 21, 2024, 4:05pm UTC](https://universal-blue.discourse.group/t/what-can-be-rebased/2425/3 "2024-06-21T16:05:19Z")
> [@genson](#): > > - Has someone come up with a way to run one time configuration commands like authselect from the image? > > - Has someone come up with a way to preinstall some flatpaks from the image? 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!): > > > \### Checklist > > \- \[X\] I agree to follow the \[Code of Conduct\](https://github.co…m/flatpak/flatpak/blob/main/CODE\_OF\_CONDUCT.md) that this project adheres to. > \- \[X\] I have searched the \[issue tracker\](https://www.github.com/flatpak/flatpak/issues) for a feature request that matches the one I want to file, without success. > > \### Suggestion > > \## Introduction > An operating system may have a set of Flatpaks that are considered to be “part” of the system, and that are automatically installed with the operating system. This set could change between versions of the operating system, so on upgrade, it might be necessary to remove or add applications. > > Adding support for this in the core of Flatpak will allow sharing the logic between distributions and desktops and can also improve the behavior when preinstallation interacts with manual installation and removal of Flatpaks. > > \## Prior Work > Endless OS has handling for Flatpaks linked to the OS - as Will Thompson \[describes it\](https://gitlab.com/fedora/ostree/sig/-/issues/8#note\_1611169716): > > \> In brief, here's how we install / upgrade / remove Flatpaks together with OS upgrades on Endless OS: > \> The OS contains files in /usr/share/eos-application-tools/flatpak-autoinstall.d/ which describe the operations to perform to reach a particular (monotonically increasing) serial number > \> When a new ostree commit is pulled, eos-updater looks inside it, and finds any actions with higher serial number than that on the system > \> If there are some, it pulls & installs any needed Flatpak runtimes, pulls but does not deploy any needed Flatpak apps, and updates any Flatpaks requested > \> Then you reboot into the new OS version > \> Early in the first boot in the new OS version, eos-updater-flatpak-installer runs and inspects the actions again. It installs the pulled-but-not-deployed apps, uninstalls any Flatpaks, and finally updates the serial number > > \## Basic Idea > There’s a drop-in directory \`/etc/flatpak/preinstall.d/\` that allows configuring what apps should be preinstalled, and a \`flatpak preinstall\` command that installs and removes apps based on the current configuration. To avoid \`flatpak preinstall\` stomping on changes made directly, “manual-install” and “manual-remove” lists are tracked. > > \## Rationale > An approach based on a strict series of actions to be applied won’t work well if the system supports non-linear updates - downgrades, or rebasing to an unrelated OSTree commit (for example rebasing from the GNOME-based Fedora Silverblue to the KDE-based Fedora Kinoite.) Simply declaring what applications should be installed is more robust in these scenarios. But we don’t want to revert changes that the user makes manually. The manual-install and manual-remove lists provide a mechanism for local customization to override the preinstall list. > > \## Details > Add directory \`/etc/flatpak/preinstall.d/\` with files such as \`org.mozilla.Firefox.preinstall\`: > > \`\`\` > \[org.mozilla.Firefox\] > CollectionID=org.flatpakhub > Preinstall=true > \`\`\` > > \* Names are arbitrary but must end in \`.preinstall\` > \* Files are sorted alphanumerically by filename, sections that are duplicated are merged with the last specified option used. > \* \`Preinstall\` is required. It will be typically be \`true\` - \`false\` could be useful as an override > \* \`CollectionID\` is optional - if missing or empty (\`CollectionID=\` will override \`CollectionID=something\`), then the application will be installed from an arbitrarily-chosen remote > > Preinstallation can be run on the command line with: > > \`\`\` sh > flatpak preinstall \[-y | --assumeyes\] > \`\`\` > > This always operates on the system remote \`- --user\` operation is not supported. The behavior is as follows > > \* Lists of application IDs \`core.xa.manual-install\`, \`core.xa.manual-remove\` are kept in /var/lib/flatpak/repo/config > \* The contents of /etc/flatpak/preinstall.d is combined to create a “preinstall list” > \* When an application is installed \*not\* through the preinstall command > \* If the manual-install list is not present it is left untouched > \* Otherwise, the newly installed app is added to the manual-install list > \* When an application is removed \*not\* through the preinstall command > \* If the app is part of the preinstall list, it it added to the manual-remove list. > \* If the app is part of the manual-install list, it is removed from there > \* When ‘preinstall’ is run. > \* If the manual-install list is not present, it is set to a “best guess” - installed apps not in the preinstall list. > \* Any apps in the preinstall list not currently installed and not in the manual-remove list are installed > \* Any apps currently installed that are not in the manual-install list and not on the preinstall list are removed. > \* Any needed runtimes and extensions are installed in the same way as would happen for ‘flatpak install \ \’ > \* runtimes and extensions can also be listed in the preinstall file, with simplified handing > \* They are installed if missing > \* They are not tracked on the manual-install / manual-remove lists > \* They are never removed by flatpak preinstall. > > The intended behavior here is that the equivalent of ‘flatpak preinstall --assumeyes’ happens on each login. (And possibly at other times, like after registering a system for updates.) Failure is handled app-by-app - if one app can’t be found or an error occurs, other apps are still handled. > > Preinstallation is exposed through FlatpakTransaction, in such a way that a GUI could present installation with confirmation and display of errors, but this is not recommended. > > \## Open Questions > > \* Should there be a way of configuring preinstalled applications that can’t be removed? (without overriding the preinstall configuration) - say \`Protected=true\`? > \* If the preinstall operation is run in a user session where the configured apps are already installed --user, should they still be installed for the system? > \* Should there be support for preinstallation happening “offline” during system upgrade, so that when the user logs into the new session, the applications are already there? > \* How should authentication to the remote during pre-installation work when it’s not run explicitly? We shouldn’t be prompting for credentials “out of the blue”, so perhaps it should simply silently fail, and be retried after the system is registered. > \* Is the CollectionID handling here useful, or just an unnecessary complication? > \* Would it be useful to have 'flatpak preinstall-ls' so, an installer image building tool, say, could query what Flatpaks are needed by the image and should be cached in a sideload repository. ---
**Author:** ![genson](https://avatars.discourse-cdn.com/v4/letter/g/e480ec/32.png) [@genson](https://universal-blue.discourse.group/u/genson)\ **Post date:** [June 21, 2024, 8:30pm UTC](https://universal-blue.discourse.group/t/what-can-be-rebased/2425/4 "2024-06-21T20:30:29Z")
I added a bug for the authselect issue, but I’m sure I’ll probably find out I was doing something wrong. > > > \### Describe the bug > > I created an OCI container using bazzite as the FROM. The… main purpose of this container was to pre-include the ldap setup into the container. autheselect changes do not seem to be populated from the container, specifically, the sss entries that should exist in /etc/autheselect/system-auth and by symlink /etc/pam.d/system-auth are not added to the system despite the fact that they are present within the container > > \### Reproduction steps > > 1. Create an oci image from a Containerfile with: > \`\`\` > FROM bazzite:latest > RUN authselect select sssd with-mkhomedir && \\ > ostree container commit > \`\`\` > 2. build oci-container: > \`\`\` > podman build -t bazzite-custom . > \`\`\` > 4. verify lines exist in container: > \`\`\` > podman run --rm -it bazzite-custom grep sss /etc/pam.d/system-auth > \`\`\` > 5. push to registry > 6. ostree rebase ostree-unverified-registry:\ > 7. grep sss /etc/pam.d/system-auth > > \### Expected behavior > > Lines in rebased system match lines in container: > \`\`\` > auth sufficient pam\_sss.so forward\_pass > account \[default=bad success=ok user\_unknown=ignore\] pam\_sss.so > password sufficient pam\_sss.so use\_authtok > session optional pam\_sss.so > \`\`\` > > \### Actual behavior > > /etc/pam.d/system-auth is unchanged and has no sssd support included > > \### System details > > root@bazzite-test:~# rpm-ostree --version > rpm-ostree: > Version: '2024.6' > Git: 1dda51b264eec8003eb6032f1f41844754ec163b > Features: > - rust > - compose > - container > - fedora-integration > root@bazzite-test:~# rpm-ostree status -b > State: idle > BootedDeployment: > ● ostree-unverified-registry:registry.home.whitfieldclan.com/repository/images/bazzite-custom:latest > Digest: sha256:d119613c0e0e24bbc74d4d94c00681270c53c6697730ace0a240a01a517e8589 > Version: 40.20240618.0 (2024-06-21T11:04:38Z) > > > \### Additional information > > \_No response\_ ---
**Author:** ![m2Giles](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/m2giles/32/471_2.png) [@m2Giles](https://universal-blue.discourse.group/u/m2Giles)\ **Post date:** [June 25, 2024, 10:09am UTC](https://universal-blue.discourse.group/t/what-can-be-rebased/2425/5 "2024-06-25T10:09:59Z")
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. ---
**Author:** ![genson](https://avatars.discourse-cdn.com/v4/letter/g/e480ec/32.png) [@genson](https://universal-blue.discourse.group/u/genson)\ **Post date:** [July 6, 2024, 3:55pm UTC](https://universal-blue.discourse.group/t/what-can-be-rebased/2425/6 "2024-07-06T15:55:04Z")
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? ---
**Author:** ![m2Giles](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/m2giles/32/471_2.png) [@m2Giles](https://universal-blue.discourse.group/u/m2Giles)\ **Post date:** [July 7, 2024, 3:45am UTC](https://universal-blue.discourse.group/t/what-can-be-rebased/2425/7 "2024-07-07T03:45:48Z")
Delete the file and then copy from /user/etc