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,
I've just spent two days trying to upgrade our school's Fedora 27
FreeIPA servers to Fedora 28 and kept hitting multiple roadblocks. I
finally found this post on the freeipa-users mailing list:
It basically says (and I've spent two days attesting to the fact) that
FreeIPA isn't actually ready for production use on Fedora 28.
I would like to suggest that, for something as central to the Fedora
Server story as FreeIPA is, we should have done at least one of the
1. Posted the above message to at least one of the Fedora
users/devel/server mailing lists.
2. Put something like the above message in the Fedora 28 release notes.
3. Modularized FreeIPA, putting the current 4.6.90-pre series in a
development module, and putting Fedora 27's 4.6.x series in a stable
It seems that we knew that FreeIPA wasn't ready well before Fedora 28
was released, so I think we really dropped the ball by not releasing
this information sooner and not distributing it more widely.
P.S. For those who care, VM snapshots are wonderful. I restored our
FreeIPA servers from snapshots, so any users who changed their password
in the last 24 hours or so will have to change it again.
The only thing on the agenda for this week would be a discussion about new
release criteria for FreeIPA, but I think we'd do better by having that
discussion on the mailing list for a week. I'll start a new thread
cross-posted with the test(a)lists.fp.o list later today.
#fedora-meeting-1: Fedora Server SIG Weekly Meeting (2018-05-15)
Meeting started by sgallagh at 19:59:39 UTC. The full logs are available
* Roll Call (sgallagh, 19:59:39)
* Agenda (sgallagh, 20:05:33)
* Agenda Item: Fedora Base Snap (sgallagh, 20:05:33)
* Fedora Base Snap (sgallagh, 20:06:38)
* AGREED: Server SIG will welcome any work done by the community to
advance snaps in Fedora, but will not treat it as a priority if it
comes in conflict with other initiatives. (+5, 0, -0) (sgallagh,
Meeting ended at 21:01:15 UTC.
Action Items, by person
People Present (lines said)
* sgallagh (66)
* zyga (51)
* langdon (35)
* Pharaoh_Atem (16)
* smooge (15)
* nirik (13)
* zodbot (10)
* mjwolf (3)
* mboddu (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
As some of you may know, one of the upstream projects I work with is
the Snappy/Snapcraft system.
Recently, the Snappy system gained full support for having alternative
base/runtimes used for the basis of snaps. Given the design of the
Snappy system, it makes it very easy for us to provide a model in
which people can build applications and services using Fedora in a
manner where it's available in a cross-distribution fashion. One of
the key advantages here is that we do not need to rebuild RPMs to
retrofit them for the snap model, they can be directly sourced and
installed as components to build a snap.
However, to be able to do this, Fedora needs to provide what is known
as a "base snap". The base snap provides the foundation for
applications and devices to be built using Fedora software with snaps.
Historically, the only "base" supported for general application use
has been the Ubuntu one shipped by Canonical, but snapd recently
learned how to use different "base" runtimes for different snaps.
I believe we have an opportunity to be a great enabler for offering
the latest and greatest technologies for developers to consume for
their software if they want to distribute it as a snap. While the
Fedora Workstation WG has been primarily focused on Flatpaks for GUI
applications, snaps are useful for more than desktop applications.
Indeed, some of the most interesting uses are involved with server and
embedded systems software.
I've worked closely with the upstream developers (of which Zygmunt
Krynicki is the main point of contact for Fedora with the Snappy team
and is CC'd to this email) to ensure that this functionality is
available to us in a way that allows us to leverage our software as
effectively as possible. In addition, I've built a relatively trivial
application to build proof of concept core base snaps with Fedora,
Mageia, and openSUSE packages.
At least initially, some of these first application snaps will be
produced in a rather simple manner as we would work with upstream on
figuring out how to adapt Snapcraft to handle alternative bases. My
eventual goal is to be able to produce a Modular Fedora variant that
works off snaps, using our software packaged as RPMs as inputs, as a
variation of the modularity work going on in Fedora as a whole. This
work would be more or less similar to the efforts for producing the
Cloud Base images that are used in cloud providers and for container
systems to use (e.g. Docker/OpenShift/Kubernetes).
I discussed this with Stephen Gallagher, and he seemed amenable to the
idea of the Server WG producing the base snap as a deliverable and
publishing it to the snap store so that it can be used to build
applications. He suggested that I bring this to broader WG mailing
list to solicit some feedback on this.
So what do you all think?
真実はいつも一つ！/ Always, there's only one truth!