server August 2018

server@lists.fedoraproject.org

9 participants
6 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

Review Fedora 29 deliverables
by Ben Cotton 30 Aug '18

30 Aug '18

Please review the list of release-blocking deliverables[1] 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. [1] https://fedoraproject.org/wiki/Releases/29/ReleaseBlocking#Server -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

2 1

Cockpit 176
by Sanne Raymaekers 22 Aug '18

22 Aug '18

Cockpit is the modern Linux admin interface. We release regularly. Here are the release notes from version 176: http://cockpit-project.org/blog/cockpit-176.html Summary: - Login: Suggest other browser when browser is unsupported - PackageKit: Install auto-updates backend on demand You can get Cockpit here: http://cockpit-project.org/running.html Cockpit 176 is available in Fedora 28: https://bodhi.fedoraproject.org/updates/cockpit-176-1.fc28 Or download the tarball here: https://github.com/cockpit-project/cockpit/releases/tag/176

1 0

Post-Flock Report and Future Meeting Plans
by Stephen Gallagher 22 Aug '18

22 Aug '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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[1]. 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. [1] https://github.com/cockpit-project/cockpit/wiki/Server-Applications -----BEGIN PGP SIGNATURE----- Version: Mailvelope v2.2.2 Comment: https://www.mailvelope.com wkYEAREIABAFAlt8b4wJEHolVWI2uqOjAABkOgCgmvKZZ0id9ZjeIgrRAPzJ AQqEilAAn133zqIONixWCQintmJ8TmW995TM =DJoy -----END PGP SIGNATURE-----

4 3

FreeIPA replication testing
by Adam Williamson 07 Aug '18

07 Aug '18

Hey folks! So, a while back we talked about how we should probably be testing FreeIPA server replication as part of the automated Server validation testing. 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: https://openqa.stg.fedoraproject.org/tests/overview?version=Rawhide&groupid… The relevant tests are server_freeipa_replication_master , server_freeipa_replication_replica , and server_freeipa_replication_client . 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 https://openqa.stg.fedoraproject.org/tests/330695/modules/freeipa_client/st… . 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 production. You can see the actual commit with all the changes on the feature branch here: https://pagure.io/fedora-qa/os-autoinst-distri-fedora/commits/ipa-replica if interested. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

3 7

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

server August 2018