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.
Thanks in advance,
Please review the list of release-blocking deliverables for your
team. Let me know if any images are missing or if the blocking status
or target size have changed since the last release.
Fedora Program Manager
-----BEGIN PGP SIGNED MESSAGE-----
Hello, Server SIG!
It's been a while since we had any activity on this list, and I apologize for
that. Between Flock and DevConf.US this month, I've been quite swamped.
First, a note about meetings: I'm going to recommend that we discontinue the
weekly scheduled meeting for the time being, as we really don't have an optimal
time for people to attend. I tried to send out a WhenIsGood a while back, but
the responses were entirely disjoint and ultimately there isn't a good time for
everyone. Instead, I'd like to see us use the mailing list more frequently and
resort to calling a meeting when there's a specific topic that needs a
higher-bandwidth conversation. As such, I'm canceling today's meeting (late
though I am at that).
So now a brief post-Flock report, covering some of the highlights from the
State of the Server Edition talk and plenary session. We discussed the Server
Edition's identity crisis and put together some thoughts about the future. My
notes (in no particular order):
* Server Edition should focus on slimming down such that the Fedora Cloud image
can be Server Edition instead of the custom minimal image it is today.
Open Question: should Server own and become the base container image as well?
* We have basically given up on the original design of Server Roles, but we
see value in Cockpit's new Server Apps. We should contribute here.
* In general, the consensus was that there are two places in Server Edition
that we should focus new features around Cockpit and Ansible. Anything we want
to declare a "Server Feature" should integrate with one or both of these. We
also would like to see Cockpit provide an Ansible-based "desired state
configuration" feature that would produce an Ansible playbook that would
replicate the current state of the system for any part of it that Cockpit
understands. (I will be writing up an RFE for Cockpit shortly).
* Considering the large overlap in utility, we should probably consider closer
ties with the EPEL project.
-----BEGIN PGP SIGNATURE-----
Version: Mailvelope v2.2.2
-----END PGP SIGNATURE-----
So, a while back we talked about how we should probably be testing
FreeIPA server replication as part of the automated Server validation
I started working on that last week, and it's deployed on staging.
Unfortunately, in this last week or so we've had several bugs in
FreeIPA deployment in Rawhide, and also bugs in Rawhide itself, that
have rather interfered with testing.
You can see some 'real' runs of the tests from the 20180710.n.0 compose
on staging, which is the compose I used to test the tests:
The relevant tests are server_freeipa_replication_master ,
server_freeipa_replication_replica , and
First thing to note: this is a separate set of tests from the existing
one. Logistically, given how openQA implements signalling between
tests, it turned out to be really difficult to wedge replication
testing into that already-quite-complex interconnected server-plus-
multiple-client set of tests, and it would've been quite a pain to
maintain and debug. So I decided not to do that, but just create a
separate test group. This is a bit less resource efficient, but rather
easier to monitor and maintain.
So, the way the tests work is basically this:
1. The 'master' test deploys its SUT as the initial FreeIPA server,
using a command like this:
ipa-server-install -U --realm=DOMAIN.LOCAL --domain=domain.local --ds-password=monkeys123 --admin-password=monkeys123 --setup-dns --reverse-zone=2.0.10.in-addr.arpa --allow-zone-overlap --forwarder=10.5.126.21 --forwarder=10.5.126.22
2. The 'replica' test then deploys its SUT as a replica of the initial
server, with DNS and CA support, using a command like this:
ipa-replica-install --setup-dns --setup-ca --allow-zone-overlap -U --principal admin --admin-password monkeys123 --forwarder=10.5.126.21 --forwarder=10.5.126.22
3. The 'client' test configures the SUT to use the replica as its DNS
server and enrols it as a member of the domain *using the replica
server*, not the master server, with a command like this:
realm join --user=admin ipa003.domain.local
where 'ipa003.domain.local' is the hostname of the replica, not the
master. It then runs through a standard set of client tests, the same
ones used in the existing FreeIPA test set - see
So, I wanted to ask folks, and especially ab and other FreeIPA folks,
if this looks like a valid test approach? Is it doing the deployments
the right way? Is it testing everything that needs to be tested? Any
other suggestions, etc? Thanks a lot!
I'm hopeful that the next Rawhide compose will be in decent shape and
have FreeIPA actually working well enough for the tests to run properly
again...once we have them working reliably and FreeIPA folks sign off
on their validity, I can merge them to master so they will also run in
You can see the actual commit with all the changes on the feature
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net