hi,
Cockpit 169 (released today) contains a change to take advantage of the
recently added PAM support for /etc/motd.d to display a helpful note to the
admin about how to start or access cockpit.
The required PAM changes have already landed in Fedora 28.
It seems that the PAM configuration of Fedora 28 (at least in our test
images here) doesn't use pam_motd at all, though.
I'd like to start a discussion about what would be appropriate here. We
want at least a message displayed when people log in to an interactive
session with ssh, but it might also be useful to display a message at the
virtual console, before or after login.
Thoughts?
Thanks in advance,
Allison

Hi, folks!
It's been noted a few times before that we have a release criterion
that requires *updating* packages (or, these days, 'software', to cover
things like modules) to work...but we don't have criteria covering
other basic software management tasks, notably installing and removing.
There is a possible justification for this: so long as update works,
bugs in installation and removal can be fixed with updates. But really,
it seems reasonable to me that we should require basic
installation/removal of packages (and modules, and anything else we may
choose to consider release critical now or in future, e.g. flatpaks,
Shell extensions...) to work on release.
So, I'm proposing we modify the existing Basic and Beta criteria that
cover only updates, to also cover installation and removal. I like this
a bit more than adding separate criteria as the footnotes would be very
similar, and combining allows the footnotes to be shared.
So, the Basic criterion would change from:
"The installed system must be able to download and install appropriate
updates with the default console tool for the relevant update type
(e.g. default console package manager)."
to:
"The installed system must be able to install, remove, and install
appropriate updates for software with the default console tool for the
relevant software type (e.g. default console package manager). This
includes downloading of packages to be installed/updated."
the Beta criterion would similarly change from:
"The installed system must be able to download and install appropriate
updates with the default tool for the relevant update type in all
release-blocking desktops (e.g. default graphical package manager)."
to:
"The installed system must be able to install, remove, and install
appropriate updates for software with the default tool for the relevant
update type in all release-blocking desktops (e.g. default graphical
package manager). This includes downloading of packages to be
installed/updated."
the footnotes would be tweaked to refer more generically to 'software'
and stuff instead of 'updates', just kinda logical changes to reflect
the broadened criterion; I can go into detail on that if anyone wants.
Obviously if the criterion change is agreed upon, we will add test
cases to the test matrices.
Thoughts, comments, suggestions, acks and nacks? Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
The current Product Requirements Document[1] for the Server Edition is
considerably out of date. Based on discussion in the recent thread on FreeIPA
release criteria[2], it's clear that its existence is actively hampering our
efforts to modernize our deliverables.
I took a look at the PRD with an eye towards modernizing it, but the truth of
the matter is that it basically needs a total rewrite. It is fundamentally
written around a core concept of "Server Roles" that have been entirely
abandoned by the Server Edition efforts. As a result, I feel that the PRD
needs to be archived entirely and not relied on as a source of truth.
What I propose is this:
1) Archive the Server PRD, noting that in broad strokes it describes our
aspirational goals but differs entirely on implementation.
2) Update all items on the Fedora Release Criteria so that they no longer
reference the PRD. Any requirements that Server SIG wishes to retain must be
moved to the Release Criteria wiki pages and treated as the canonical source of
truth.
I feel that this will be better for the Server Edition in the long-term, as the
Release Criteria pages are much better maintained than the PRD and we can be
both more flexible and more visible with changes.
Thoughts?
[1] https://fedoraproject.org/wiki/Server/Product_Requirements_Document
[2] https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject....
-----BEGIN PGP SIGNATURE-----
Version: Mailvelope v2.2.2
Comment: https://www.mailvelope.com
wkYEAREIABAFAlspZxUJEHolVWI2uqOjAADNUgCghgWnoSPNh8o3P/xUmj0d
2GmU0kYAoKjl7f0ytapwvszKmbNRHnPh3N8/
=JX1W
-----END PGP SIGNATURE-----

Hi,
as discussed earlier[1], I'm proposing to extend Fedora Server release
criteria to include replicated topology testing for domain controllers
shipped with Fedora Server. This is an aspirational goal as there are
limiting factors right now.
Fedora Server ships with two domain controllers: FreeIPA and Samba AD.
OpenQA infrastructure uses domain controller-agnostic approach to enroll
clients and deploys domain controllers and clients with the help of
rolekit. There is only one type supported currently to deploy a domain
controller: FreeIPA, and only a single domain controller can be
deployed.
As result, large part of FreeIPA functionality is not tested at all
because we are not able to deploy FreeIPA replicas in OpenQA via
rolekit. With an ongoing Python 3 and NSS to OpenSSL migration for
FreeIPA, Dogtag, SSSD, and other related components, we aren't testing
critical integration of these components within Fedora.
FreeIPA upstream has a testing infrastructure that allows to test
different topologies for a replicated FreeIPA deployment. The tests run
against each pull request upstream and there are 'nightly' test suites
which kicked off several times a week. These tests, however, use a fixed
Fedora image, regenerated regularly but typically tracking current
Fedora stable release, not Rawhide.
Ideally, a test covering basic replication scenario needs to exist for
Rawhide/Branched.OpenQA uses rolekit to deploy a DC. Rolekit does not
have support for deploying a replica. Rolekit is supposed to be
deprecated (dead in development). It shouldn't be hard to extend rolekit
to run FreeIPA replica promotion, though.
Based on the above, if we would extend rolekit, I believe it would be
relatively easy to extend OpenQA tests to add a second domain controller
into a test environment and check whether a client enrolled into the
domain against one domain controller can use management services from
the other domain controller.
When such extension is ready for FreeIPA, we can establish a release
criteria to include a test of replicated topology for domain controller
technology in Fedora Server.
Note that I'm trying to keep this generic to allow us to add Samba AD as
a tested domain controller later. This, however, raises a question on
whether rolekit way of configuring servers is a right approach going
forward.
--
/ Alexander Bokovoy