server October 2021

server@lists.fedoraproject.org

15 participants
18 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

F36/37:- Our Work Project 3: Improved support for Server Edition VMs - Feedback appreciated
by Peter Boy 18 Nov '21

18 Nov '21

On our agenda there is the project "Facilitated and improved support for Fedora Server Edition VMs". Once started as a prospective cooperation with cloud WG, this prospect has bluntly failed. The question now is how can we easily and efficiently provide a virtualised version of Fedora Server for a bare-metal Fedora Server with virtualisation support installed. This question becomes urgent given the power of current hardware. Currently there are 4 Options ready to use: (1) Usage of Cockpits 'Create VM' which launches Anaconda installation support and guides you through the standard installation process. You get a perfect duplum of Fedora Server in virtualized form, but at the price of a significant amount of work. Instead of Cockpit you could use an elaborate invocation of virsh, but the effort will not be less. That's not exactly the goal of our project. (2) Installation of guestfs-tools (f35, libguestfs-tools-c in f34) and use virt-builder to create a partly customized disk image (e.g. root password) that you can import using virsh You get a disk image file pretty quickly and importing it into KVM is easy and fast as well. You will not get a duplum of Fedora Server virtualized, contrary to the description in virt-builder. Cockpit is not installed, filesystem is without LVM, many software packages are missing (vim, tar , sshfs, etc), firewall without Fedora Server zone - just to name a few. The qcow2 image file created by default has a capacity of 10 GiB and also occupies 10 GiB in the file system - so no use of dynamic capability of qcow2 format. The image is generated on an external server and imported as a binary. With all the effort we put into Fedora to build even the smallest rpm package completely from source on Fedora infrastructure, it seems pretty absurd to use a complete VM binary from a third party source or to rely on an external binary image. Overall, this is not a suitable solution. (3) Usage of mage Builder Tool / Cockpit module The tool creates an elaborated image file. But in the current implementation it requires almost a similar effort as an Anaconda installation. And as in the case of virt-builder, a binary is imported from an external source. So it is a similarly limited suitable solution. (4) Usage of cloud base image This solution would be Fedora controlled after all. Importing via virsh is simple and fast. But the result is far from being a duplum of Fedora Server - no firewall, no cockpit, different file system, missing software, just to name a few. And a duplum is explicitly not intended by cloud WG. Altogether, this option is not a solution either. = Conclusion = Unless I have overlooked an adequate tool, our only option is to supply our own image file - similar to what CoreOS does. We already provide a perfect image file for Arm64 SBC devices - including initial configurability, similar in scope to Anaconda. Could this serve as a template? Maybe that would be a realistic goal for F36 release? Feedback and other possible alternatives are very much appreciated. Best Peter

6 11

Call for Agenda for next IRC meeting
by Peter Boy 10 Nov '21

10 Nov '21

Our next meeting is scheduled for Nov. 3. Currently, I don't have any agenda topics on the books and there are no open actions. Upcoming: * open action on issues #48 and #32 when Fedora 35 is finally released (in charge: Eighth_Doctor) * further development of documentation (in charge: pboy, copperi) * plannings for Fedora 36 / 37 * progress with our working plan Please, everyone check to see if you have a discussion topic for next week's scheduled meeting. If I don't have a feedback here on the list by Sunday, Oct 31, I propose to cancel the next meeting. Best Peter

3 5

How good is the real quality and reliability of our deliverables?
by Peter Boy 09 Nov '21

09 Nov '21

We are officially distributing a Fedora Server Edition disk image for ARM, typically used for SBCs. I just tried to install this image on a Radxa Rock Pi 4 and failed miserably. That SBC device is part of the installation procedure provided by the ARM team. With the F34 image I ended up with a black screen, no display, no chance to get the device working in the normal way (I got it to work in tricky detours). With F35 Beta I got a working display, but no network connection. I haven't found a solution for that yet. And then I remembered F33, where it was discovered by chance (!) at the last minute, that in the x86_64 version Cockpit did not work properly (and probably also in the aarch64 default install version, we didn't and probably couldn’t even check that afterwards). We have not solved the underlying issue for this until today, although the factual reason has been clear for a long time (issue #32). Similar problems had emerged after the release with the switch to systemd-resolved, where "surprisingly" problems with some server configurations were encountered, especially with elaborate use of KVM virtualization on a server. These events are clear violations of our release criteria. In principle, a release must be at least successfully installable and basically working. For me, this brings up a few questions: (1) Did any of us actually have Fedora Beta installed on a ARM device (SBC or other) using the image file and on which model? Or are we just flying blind with that deliverable? (2) What about the two aarch64 install iso files that target SBSA hardware? Does anyone have such a beast at hand and tested the isos? Or is that (also) flying blind? (3) And what about x86_64 installation? Most of us will be in possession of this hardware. But what about tests? When I started a discussion about testing a year ago, Adam reassured us, release building and testing is heavily automated these days. No need to worry too much about testing it manually ourselves. But did anyone of us at least worry a bit? I would like to discuss how we can gain some improvement. Regarding arch architecture, could some kind of cooperation with arm group be beneficial? And what can we offer? Is it testing? Is it documentation? Or something else? If we want to take SBC devices seriously, perhaps we could identify a few reference systems where we can actually ensure, i.e. test, whether a successful installation and basic functionality is met. If we don't want that, we should not distribute the image file under the Fedora Server Edition branding. And in terms of our "main" architecture, we should agree on what QA actually expects in terms of non-automated testing and how we want to tackle that in the next round. Based on Adam's comments, we have relied heavily on automation for the last few releases. So it's not clear to me what, for example, the page https://fedoraproject.org/wiki/Test_Results:Fedora_35_RC_1.2_Server means in detail in terms of work. Happy Sunday Peter

8 12

Ongoing Fedora website revamp - FEEDBACK needed!
by Peter Boy 03 Nov '21

03 Nov '21

After a longer time of preparations the work on the website-revamp is starting now. The first session is Wednesday 27. In a first step will rebuild the Fedora landing page (fedoraproject.org) and the download page (getfedora.org) See: https://fedoraproject.org/wiki/Websites/Fedora_Website_Revamp Currently the Fedora landing page is simple a redirect on the download page. In the future the landing page will be the main page with central information about Fedora and a download link to the download page. For the design and content of the main page Máirín Duffy made a proposal. https://discussion.fedoraproject.org/t/a-new-conceptual-model-for-fedora/33… Her proposal is "meant to represent 'the story' of Fedora and how you would use it, and serve as a model from which we will build the narrative for Fedora and its web presence.“ In this model Fedora is - either a desktop user using Silverblue - or a Web/App Developer using local container based development or Fedora CoreOs remotely, - or an IoT Developer using IoT device IMHO that story is a bit short. Nevertheless, I need feedback what members of or working group are expecting from the central Fedora website and the Download page.

6 9

Future of Fedora Cloud as an Edition?
by Matthew Miller 28 Oct '21

28 Oct '21

Today I learned that some people are quite surprised (and not in a happy way) that Fedora Cloud base is no longer considered an Edition. Please see discussion here, both on the history and the potential futures: https://discussion.fedoraproject.org/t/fedora-cloud-edition-not-an-edition-… -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

1 0

dnf upgrade for Fedora Server 34 ->35 failed
by Peter Boy 27 Oct '21

27 Oct '21

I just tried to upgrade one of my test boxes F34 to F35 using dnf system-upgrade download --refresh --releasever=35 It failed at transaction test: /usr/libexec/osbuild-composer/dnf-json (from Installation of) osbuild-composer-core-31-1.fc35.x86_64 ( collides with file from package) osbuild-composer-dnf-json-36-1.fc34.x86_64 (the message here was localised in German, my translation here) On 2 other test boxes the upgrade completed without error (one without any additions to the basic install and the other with just postgresql installed). The test box was basic install an lvm virtualisation. Did someone else tested an update of Server with kvm installed? And what is the way to get around that issue? Best Peter

3 4

Cockpit 256, cockpit-machines 255
by Jelle van der Waa 27 Oct '21

27 Oct '21

Happy Wednesday! Cockpit is the modern Linux admin interface. We release regularly. Here are the release notes from Cockpit version 256, cockpit-machines version 255: https://cockpit-project.org/blog/cockpit-256.html Summary: - Clean up old self-signed certificates - Storage: Add support for Stratis - Cockpit-machines: translation updates Cockpit 256 is available for download here: - source: https://github.com/cockpit-project/cockpit/releases/tag/256 - Fedora 35: https://bodhi.fedoraproject.org/updates/FEDORA-2021-d0454f82b0 - Fedora 34: https://bodhi.fedoraproject.org/updates/FEDORA-2021-42ab01f71d cockpit-machines 255 is available for download here: - source: https://github.com/cockpit-project/cockpit-machines/releases/tag/255 - Fedora 35: https://bodhi.fedoraproject.org/updates/FEDORA-2021-cd7d707018 - Fedora 34: https://bodhi.fedoraproject.org/updates/FEDORA-2021-0a0bce1577

1 0

update F34 - f35 postgresql module issue
by Peter Boy 26 Oct '21

26 Oct '21

I just tested the dnf upgrade procedure on one of our standby backup systems which happens to have the F34 postgresql module version 9.6 installed. The module was overwritten with version 13 without warning. Given the data incompatibility, this is a very unattractive practice. As far as I remember, one could rely on the fact that with an upgrade the respective module was updated in the installed version. Fedora 35 comes obviously without Postgres module 9.6. Unfortunately, the release change set doesn’t mention that. We need a clear indication and warning of this. Peter

2 1

Python and PHP packages during update to F35
by Łukasz Posadowski 21 Oct '21

21 Oct '21

Hi. Did any of You had dependency problems while updating F34 to F35? It happens sometimes with Python, Perl, or PHP packages. Today it were: php-pecl-msgpack php-pecl-memcached php-pecl-redis5 php-pecl-apcu php- pecl-imagick php-pecl-igbinary php-common php-pdo php-cli php-fpm php- json php-mbstring php-opcache php-sodium php-xml php-intl php php- mysqlnd php-bcmath php-gd php-gmp php-process php-pecl-zip php-fedora- autoloader php-pear and certbot fail2ban fail2ban-firewalld fail2ban-sendmail fail2ban-server fail2ban-systemd python3-acme python3-certbot python3-certbot-apache python3-josepy python3-ndg_httpsclient python3-pyOpenSSL python3- pyrfc3339 python3-pytz python3-service-identity python3-twisted+tls I had to reinstall those to fully upgrade system to 35 branch, which involved rewrite of php.ini file. The best part is: Fedora never broke for me after partial update, even it Perl and PHP remained behind from N-1 release. It reboots like nothing happened, sometimes with minor quirks on the Gnome desktop. -- Łukasz Posadowski

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

server October 2021