variant: fcos
version: 1.3.0
systemd:
units:
# installing nano as a layered package with rpm-ostree
- name: layer-nano.service
enabled: true
contents: |
[Unit]
Description=Layer nano as with rpm-ostree
# We run after `systemd-machine-id-commit.service` to ensure that
# `ConditionFirstBoot=true` services won't rerun on the next boot.
After=systemd-machine-id-commit.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/rpm-ostree install nano --reboot
[Install]
WantedBy=multi-user.target
If that works, I’ could contribute that to the Fedora documentation…
Do you think this would be another useful example? I could certainly contribute that…
Especially if the cgroups v2 thing is deleted when the change is long gone, maybe it could show a way to run custom stuff after systemd-machine-id-commit so it’s not re-done to often…
Maybe also show a full use case of using nano as your default editor?
variant: fcos
version: 1.3.0
storage:
files:
# use nano as default editor
- path: /etc/profile.d/nano.sh
overwrite: true
contents:
inline: |
#/bin/sh
export EDITOR=nano
systemd:
units:
# installing nano as a layered package with rpm-ostree
- name: layer-nano.service
enabled: true
contents: |
[Unit]
Description=Layer nano as with rpm-ostree
# We run after `systemd-machine-id-commit.service` to ensure that
# `ConditionFirstBoot=true` services won't rerun on the next boot.
After=systemd-machine-id-commit.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/rpm-ostree install nano --reboot
[Install]
WantedBy=multi-user.target
Do I miss something?
Oh yeah, maybe I miss a Condition… so it does not re-run, do I?
For this I guess, I would have to query rpm-ostree first. I saw it has a JSON interface and JSONPath, so I tried using that like this: $ rpm-ostree status --booted --jsonpath='$.deployments[?(@.booted == true)].packages[*]', but I’m either to stupid to use JSONPath or rpm-ostree or the online tools I used for comparison have a problem.
In a cloud environment (thinking EC2 with autoscaling) I wonder how long that would take and how it would impact the server being “ready”. I’ve managed to manually download and install binaries with hash verification but it would be nice to see some documentation on this.
Well… static binaries are not so nice and layering is IMHO better.
Thanks, yeah, I guess this is very useful.
However is there any solution for my rpm-ostree/condition problem already?
Or am I stupid and oneshot services do not re-run, and only run at provisioning once?
Would that approach also work for provisioning CoreOS with zfs support?
From what I see here (GitHub - coreos/layering-examples, second example) the rpms would need to be built in a container first and the system then rebased.
Will this also work during provisioning if set up as a oneshot systemd unit?
I would like to provision a system that can mount zfs pools at first boot.