Re: [atomic-devel] Enabling motd feature

[Ratnadeep Debnath <rtnpro gmail com>]

Hi,

On Thu, Apr 7, 2016 at 12:13 AM, Colin Walters <walters verbum org> wrote:
> That said I have some detailed and high level concerns.
>
> The detailed concerns are a security issue and a buglet:
> https://github.com/rtnpro/fedora-motd/issues?utf8=%E2%9C%93&q=is%3Aissue+author%3Acgwalters+
Thanks for reporting the above issues. I will fix them ASAP and
release an updated for fedora-motd.

> The high level concern is having this functionality live
> outside of the update system and the login system
> is rather awkward.  I really don't like calling into rpm-ostreed from
> inside every PAM login.
>
> Among other reasons, the first ssh login might e.g. be ansible
> trying to configure the host, and having rpm-ostreed be spun
> up for that when the administrator might actually want to do
> something else is problematic - the check-updates will
> block whatever action they want to take (e.g. rpm-ostree rebase).
>
> The way it hooks into dnf is a bit better from this perspective.  But
> since rpm-ostree is already a daemon, it might be simplest to
> have it just write out the required data in /run/rpm-ostree/bash-check-updates
> only after the administrator requests an update once or so?

Neither rpm-ostree nor dnf is called on every login. I was aware of
the blocking nature and high
CPU usage (for dnf updateinfo).

/usr/bin/motdgen is called on each PAM login via sshd. It does nothing
more than going
through the files in /etc/motdgen.d and running them. The file
/etc/motdgen.d/02-updateinfo.sh
does nothing but cat the content of /var/run/updateinfo.txt if
available. Neither dnf nor rpmostree
is accessed. The content of /var/run/updateinfo.txt is updated by running
/usr/bin/motdgen-cache-updateinfo in the background at periodic
intervals (currently once a day)
or on dnf transaction triggers (no trigger for rpm-ostree yet) in a
decoupled way.

So, the current implementation does not slow down or block the login
process in any way.

Is this implementation OK? Let us know if we can improve it.

Thanks,
rtnpro
-- 
Ratnadeep Debnath,
https://www.waartaa.com
GPG Fingerprint: 033C 8041 A0E9 CDBA 2E02  B785 2119 5486 F245 DFD6