#160 Ship fedora-motd in F24 atomic image
Opened 7 years ago by rtnpro. Modified 5 years ago

fedora-motd-0.1.3-1 has been tested and moved to stable F24 repo. We need to come up with a plan to ship it an upcoming Fedora 24 atomic cloud images.

https://bodhi.fedoraproject.org/updates/FEDORA-2016-c8948356b9


We have added tests to run on tunir for fedora-motd at https://github.com/rtnpro/motdgen/tree/master/tunirtests. The tests do the following:

  • install fedora-motd rpm on atomic host in hotfix mode
  • reboot atomic host
  • assert if motd message is printed on SSH login

Here's some instructions on how to run the tests: https://github.com/rtnpro/motdgen#tests

Next steps?

  • include fedora-motd in fedora atomic host builds and enable motdgen.service
  • include fedora-motd in fedora cloud images as well

@walters could you outline the steps to ship fedora-motd in fedora atomic image build?

The previous discussion on this was https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2016-April/msg00020.html
which I didn't reply to.

Okay, so you said:

The file
/etc/motdgen.d/02-updateinfo.sh
does nothing but cat the content of /var/run/updateinfo.txt if
available. 

which, looking at https://kojipkgs.fedoraproject.org//packages/fedora-motd/0.1.2/2.fc25/noarch/fedora-motd-0.1.2-2.fc25.noarch.rpm
isn't true, since I see this code:

cat etc/motdgen.d/02-updateinfo.sh 
...
if [ ! -f "$firstrun" ]; then
    touch $firstrun
    nohup /usr/bin/motdgen-cache-updateinfo &
fi
# cat usr/bin/motdgen-cache-updateinfo 
#!/bin/sh
if [ -f /run/ostree-booted ]; then
    rpm-ostree upgrade --check --preview > /var/run/rpmostree_updateinfo.out
...

We're hence starting a potentially long running process out of the PAM stack, which is really not a good idea. Invoking rpm-ostree like this will also block other clients as I said (And that's also true of yum/dnf) - which is again very problematic if the "login" is actually Ansible where you're trying to do things like configure a proxy or mirror.

Deleting the first run bit would deal with the biggest of my objections, but then we'd still have the cron job (which itself is problematic because we just got rid of cron - this should be a systemd timer)

An architecture which is event driven and would implement the "only check automatically if explicitly invoked at least once" is to patch rpm-ostree to do something like systemctl start --no-block system-motdgen.service after it's completed a transaction. Then the motd code could call back with the DBus API for GetCachedUpdateDetails.

To repeat again, I am a big fan of this effort - having a nicer interactive experience is great! The cockpit guys were working on something similar to what CoreOS does with displaying the host IP addresses in the console too.

But the PAM and update stacks are about some of the most senstitive/critical aspects of the OS, and we have to be really careful when tying them together.

@walters I got that. I will fix fedora-motd based on your feedback and share it for review by this weekend.

We need to ship this for f25.

I did not manage to work on it post walter's review. I will be off for quite some time from next week on account of my marriage. It will be great if someone can lend me a hand to see this feature to completion.

@walters

I created an issue1 to work on migrating from cron to systemd.

Regarding the first run of motdgen-cache-updateinfo, I am not a big fan of it being run from the PAM stack. That's why I have a workaround in place.

Use cases

Installing fedora-motd manually

User can run /usr/bin/motdgen manually post install to cache update details. Hence, in subsequent runs, neither atomic or dnf update info will be checked. May be we can run /usr/bin/motdgen post install. Also, another way is to start motdgen.service or enable it at boot. So, atomic and dnf commands won't be run at all from the PAM stack, because it has already been run, post install or at system boot.

Enabling fedora-motd in images

We can enable motdgen.service at system boot. This will execute atomic and dnf commands only during first boot and cache the results. This will result in displaying the motd data from the cached update info result.

@walters what do you think? Is this workaround good enough?

We can enable motdgen.service at system boot. This will execute atomic and dnf commands only during first boot and cache the results.

I'm concerned that this'll make the first boot annoying slow. Can we just run it from a systemd timer?

Fixed the following issues:

If the cloud WG is OK with the changes, I will update the RPM package and release it.

@dustymabe @walters @mattdm ^^

Metadata Update from @roshi:
- Issue untagged with: meeting

7 years ago

@dustymabe did anyone have time to review the above changes?

@rtnpro any current development/info on this issue? I'd like to make use of fedora-motd in greenboot (https://github.com/LorbusChris/greenboot)
cc @walters @dustymabe

One thing that changed is that rpm-ostree now has a DBus API that shows the already cached update. Simply querying that is cheap and addresses my concerns about blocking other operations, etc.

A side note: Today Container Linux does not include Python, and we'd like to continue towards that for the converged Fedora CoreOS. golang and Rust are both good options.

Login to comment on this ticket.

Metadata