server June 2018

server@lists.fedoraproject.org

11 participants
13 discussions

Proposal: Changes to Fedora Server default partitioning scheme
by Stephen Gallagher 13 Dec '24

13 Dec '24

The following proposal comes out of the discussion at this weeks Server SIG meeting[1] Fedora Server will have: * / (root) will be a minimum of 2 GiB and a maximum of 15 GiB * SWAP will continue to be calculated automatically based on available RAM on the system * All unused space will be assigned to a volume group and available to be assigned to new partitions or extend existing partitions. * Anaconda will continue to handle the appropriate EFI and /boot settings We also discussed during the meeting whether we should have a separate /var partition by default, but the general sense was that we might be better served by developing a mechanism to allow partitions to be split from existing mount points, which would be more flexible going forward. As we did not have quorum in the meeting by the point we got to this proposal, I'm taking it to the list for discussion and votes. For the record, the current behavior of the partitioning scheme is for / to be given up to 50 GiB of space and then any remaining space after that is assigned to a separate /home partition. [1] https://meetbot.fedoraproject.org/fedora-meeting-1/2016-03-15/serversig.201…

4 8

Cockpit motd support
by Allison Karlitskaya 16 Jan '19

16 Jan '19

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

7 22

Release criteria proposal: installing / removing software
by Adam Williamson 17 Jul '18

17 Jul '18

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

3 8

Cockpit 171 released
by Martin Pitt 27 Jun '18

27 Jun '18

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

1 0

[Canceled] Server SIG Weekly Meeting (2018-06-26)
by Stephen Gallagher 26 Jun '18

26 Jun '18

-----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 5

Proposal to archive the Server PRD
by Stephen Gallagher 20 Jun '18

20 Jun '18

-----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.or… -----BEGIN PGP SIGNATURE----- Version: Mailvelope v2.2.2 Comment: https://www.mailvelope.com wkYEAREIABAFAlspZxUJEHolVWI2uqOjAADNUgCghgWnoSPNh8o3P/xUmj0d 2GmU0kYAoKjl7f0ytapwvszKmbNRHnPh3N8/ =JX1W -----END PGP SIGNATURE-----

3 2

Server SIG Weekly Meeting Minutes (2018-06-19)
by Stephen Gallagher 19 Jun '18

19 Jun '18

-----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.2… . 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-----

2 1

Release criteria proposal: use replicated topology for domain controllers
by Alexander Bokovoy 15 Jun '18

15 Jun '18

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

2 3

Testcase Server Remote Logging review
by Lukas Ruzicka 13 Jun '18

13 Jun '18

Hello friends, can you please review the SUBJ and let me know what you think about it? Thank you. https://fedoraproject.org/wiki/User:Lruzicka/QA:Testcase_Remote_logging -- Lukáš Růžička FEDORA QE, RHCE Red Hat <https://www.redhat.com> Purkyňova 115 612 45 Brno - Královo Pole lruzicka(a)redhat.com TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>

3 3

Cockpit 170 released
by Martin Pitt 13 Jun '18

13 Jun '18

http://cockpit-project.org/blog/cockpit-170.html Cockpit is the modern Linux admin interface. We release regularly. Here are the release notes from version 170. Software Updates: Layout rework ------------------------------- The Software Updates page has improved mobile browser support. On desktop browsers, the updates list avoids line breaks in the version column. Versions become truncated when there's not enough room to display the complete string. Hovering over the shortened string shows the complete version. Screenshots: https://cockpit-project.org/images/updates-mobile.png https://cockpit-project.org/images/updates-version-truncated.png oVirt: Use authenticated libvirt connection by default ------------------------------------------------------ The oVirt version of the Machines page now uses a TLS-enabled libvirt connection URI instead of `qemu:///`. This enables libvirt operations that require authentication. One common example is sending an NMI. A machines-ovirt.config file with a `VIRSH_CONNECTION_URI` option may override the connection address. Thanks to Sharon Gratch for this improvement! Get it ------ You can get Cockpit here: http://cockpit-project.org/running.html Cockpit 170 is available in Fedora 28: https://bodhi.fedoraproject.org/updates/cockpit-170-1.fc28 Or download the tarball here: https://github.com/cockpit-project/cockpit/releases/tag/170 Take care, Martin Pitt

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

server June 2018