I pushed a new release 0.1.2 for fedora-motd and submitted the updateOn Thu, Apr 7, 2016 at 9:24 PM, Ratnadeep Debnath <rtnpro gmail com> wrote:
> 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.
to bodhi at [1]. The rpm is available at [2]. This update contains:
- Fix detecting rpm-ostree based system
- Don't use predicatable name in /tmp
- Cache updateinfo in background on first login post fedora-motd installation
- Don't wait for background jobs to complete in motdgen scripts
[1]: https://bodhi.fedoraproject.org/updates/FEDORA-2016-fa9e77c232
[2]: https://kojipkgs.fedoraproject.org//packages/fedora-motd/0.1.2/1.fc23/noarch/fedora-motd-0.1.2-1.fc23.noarch.rpm
Please give it a try and let us know your feedback.
Thanks,
rtnpro
--
Ratnadeep Debnath,
https://www.waartaa.com
GPG Fingerprint: 033C 8041 A0E9 CDBA 2E02 B785 2119 5486 F245 DFD6