Cockpit motd support
by Allison Karlitskaya
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
4 years, 2 months
Release criteria proposal: installing / removing software
by Adam Williamson
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
4 years, 8 months
Cockpit 171 released
by Martin Pitt
http://cockpit-project.org/blog/cockpit-171.html
Cockpit is the modern Linux admin interface. We release regularly. Here
are the release notes from version 171.
Machines: Add virtual CPU configuration
---------------------------------------
The Machines page can now flexibly configure the number and layout of virtual CPUs:
When changing the values for an already running VM, they become effective after
stopping and restarting it.
Screenshot: https://cockpit-project.org/images/machines-vcpu-config.png
Thanks to Bohdan Iakymets!
Kubernetes: Add KubeVirt pod metrics
------------------------------------
The details page of a KubeVirt VM now shows the current CPU, memory, and
network usage. This is similar to the libvirt VM on the Machines page.
Screenshot: https://cockpit-project.org/images/kubernetes-kubevirt-pod-metrics.png
Thanks to suomiy!
Docker: Show container volumes
------------------------------
The details page of a running Docker container now shows its volumes and their
mode (like "read only"):
Screenshot: https://cockpit-project.org/images/docker-volumes-list.png
Thanks to Katerina Koukiou!
Fix broken actions for non-administrators
-----------------------------------------
The tuned, system time, and host name links on the System page, as well as the
unit and service buttons on the Services page now check if the user is actually
allowed to carry out the action. If not, the elements now get disabled and show
a proper tooltip.
Screenshot: https://cockpit-project.org/images/system-tuned-permission.png
Networking: Handle non-running NetworkManager
---------------------------------------------
The Networking page now hides the non-functional network graphs and action
buttons while NetworkManager is not running, and shows an appropriate
notification. If NetworkManager is enabled, this usually indicates a crash or
otherwise unexpected situation:
Scresnshot: https://cockpit-project.org/images/network-nm-stopped-enabled.png
If NetworkManager is disabled, this usually just means that some other
software manages the network, or that this might be a fresh installation where
NetworkManager is not configured yet:
Screenshot: https://cockpit-project.org/images/network-nm-stopped-disabled.png
Accounts: User role improvements
--------------------------------
The Accounts page now offers adding an "Image Builder" role to a user, which
puts that user into the weldr Unix group. It also points out that this does not
become immediately effective but only applies to new logins:
Screenshot: https://cockpit-project.org/images/accounts-weldr-notification.png
Localize times
--------------
Dates and times on all affected pages (System, Storage, and Docker) now use the
format matching the selected Display Language instead of the U.S.format.
Screenshot: https://cockpit-project.org/images/moment-i18n.png
Get it
------
You can get Cockpit here:
http://cockpit-project.org/running.html
Cockpit 171 is available in Fedora 28:
https://bodhi.fedoraproject.org/updates/cockpit-171-1.fc28
Or download the tarball here:
https://github.com/cockpit-project/cockpit/releases/tag/171
Take care,
Martin Pitt
4 years, 9 months
[Canceled] Server SIG Weekly Meeting (2018-06-26)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
We have nothing on the agenda for this week, so let's cancel.
-----BEGIN PGP SIGNATURE-----
Version: Mailvelope v2.2.2
Comment: https://www.mailvelope.com
wkYEAREIABAFAlsyRPcJEHolVWI2uqOjAADisACeLWHCUV/d4LSOFyvDDSU8
vuG0z+oAoI4CJZXRaqGR9PY5Oy5gVdWfE13D
=saeZ
-----END PGP SIGNATURE-----
4 years, 9 months
Proposal to archive the Server PRD
by Stephen Gallagher
-----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-----
4 years, 9 months
Server SIG Weekly Meeting Minutes (2018-06-19)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
================================================================
#fedora-meeting-1: Fedora Server SIG Weekly Meeting (2018-06-19)
================================================================
Meeting started by sgallagh at 20:00:47 UTC. The full logs are available
athttps://meetbot.fedoraproject.org/fedora-meeting-1/2018-06-19/serversig...
.
Meeting summary
- ---------------
* Roll Call (sgallagh, 20:00:47)
* Agenda (sgallagh, 20:03:44)
* Agenda Item: Aging PRD and FreeIPA requirements (sgallagh,
20:04:09)
* Aging PRD and FreeIPA requirements (sgallagh, 20:05:04)
* Those present generally agree with the proposal "Archive the current
Server Edition PRD as a historical document and move our specific
release criteria out of it and into the general Release Criteria
wiki pages." but it will be sent to the mailing list for further
discussion. (sgallagh, 20:14:43)
* Open Floor (sgallagh, 20:14:48)
Meeting ended at 20:18:08 UTC.
Action Items
- ------------
Action Items, by person
- -----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
- ---------------------------
* sgallagh (25)
* zodbot (8)
* nirik (4)
* smooge (4)
* langdon (4)
* mjwolf (2)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
-----BEGIN PGP SIGNATURE-----
Version: Mailvelope v2.2.2
Comment: https://www.mailvelope.com
wkYEAREIABAFAlspZSUJEHolVWI2uqOjAADD/wCgihKHM5FFkpuwepwZZ//o
ZU/uP9IAoJZl4mSI6zUWWF5qR9mJyCRWb9f6
=Hpbi
-----END PGP SIGNATURE-----
4 years, 9 months
Release criteria proposal: use replicated topology for domain
controllers
by Alexander Bokovoy
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
4 years, 9 months
Server SIG Weekly Meeting Agenda (2018-06-12)
by Stephen Gallagher
We have one item for today's meeting: a review of the Remote Logging
criteria for Server Edition. If there are other topics, please come to the
meeting and raise them.
4 years, 9 months
