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…
Folks, as discussed on our last meeting I put a first draft on hacked.io
https://hackmd.io/7saRpaD_RvGaw1FB3La01Q?both
It’s a first draft and not complete yet, of course.
When logged in to hackmd.io you can comment and edit the text.
Let’s discuss it on our next meeting.
And of course, any comment here on our mailing list is welcome!
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
PBoy(a)fedoraproject.org
Timezone: CET (UTC+1) / CEST /UTC+2)
Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast
Folks,
We decided for „Fedora Server in a virtualized runtime environment“ as our second priority work project. As a first step I consider to send a mail to user list and to "Ask Fedora“ and probably discussion #server-wg to collect experiences with this.
Maybe, a mail like:
> - - - - - - - - - - - <
Subj.: Who has experience with Fedora as VPS at a hosting provider?
Text Body:
The Server WG is looking for users who run or have run Fedora, especially Fedora Server, as a virtual private server (VPS/VDS) with hosting providers such as Contabo, netcup VPS, or AWS (Lightsail) and others. We are interested in providing/accepting custom images for installation as well as Fedora offerings by the host provider (Completeness, up-to-dateness).
Would you share with us your experiences? How can we make it easier? What were / are you missing in Fedora?
Please, reply to this mail or share your knowledge in the server-wg channel https://discussion.fedoraproject.org/tags/c/project/7/server-wg
> - - - - - - - - - - - <
Any ideas? Comments? Better ideas? Better wording? Objections?
What are the best locations to send such a message to?
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
PBoy(a)fedoraproject.org
Timezone: CET (UTC+1) / CEST /UTC+2)
Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast
Folks,
Just as a reminder: Our last meeting was 2 weeks ago. Nevertheless, our next meeting is the 1st Wednesday in June, which is June 7, 2023. 17:00 UTC. We have a 3 week gap again this time.
I’ll send the agenda around, soon.
Peter
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
PBoy(a)fedoraproject.org
Timezone: CET (UTC+1) / CEST /UTC+2)
Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast
Cockpit offers a new module, the Cockpit Navigator, a file system browser. This offers especially for new server users a comfortable, graphical way to explore the server and eases the getting started with the server. Including it in the standard installation makes the server more attractive for new users.
Cockpit is configured in comps-f39.xml.in, group headless-management. Group headless-management is used by fedora-disk-server.ks and fedora-server-vm-full.ks only. I didn't find it in any other Kickstart file. So no other installation media is affected by a change.
We have to add a line:
<packagereq type="default">cockpit-navigator</packagereq>
to the headless-management group.
I think, we just have to create a PR accordningly. A change request should not be required for this.
I have created ticket #111 (https://pagure.io/fedora-server/issue/111)
Unfortunately our IRC meeting last Wednesday had to be cancelled. I think the change is a simple matter and not controversial. Therefore, if no one raises concerns, I will initiate the process on Monday, May 29.
Nevertheless, it would be helpful if everyone adds a vote to the ticket to make the intent of the Working Group completely clear!
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
PBoy(a)fedoraproject.org
Timezone: CET (UTC+1) / CEST /UTC+2)
Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast
Folks,
On our May 03 meeting we decided:
"WG will pursue ... for F39 ... 'Fedora Server Edition in virtualized environments' with 2nd priority."
I wrote a proposal of a project description:
------
So far, both documentation as well as installation media are very much focused on running a Fedora server on hardware or as a virtualized guest of a Fedora host on hardware. In both cases, the system administrator has the most extensive configuration options.
In view of the enormous increases in hardware performance, an individual server project is often no longer able to exploit this performance. A market has developed where professionalized service providers offer a virtualized runtime environment for individual servers, known as "virtual private server" (VPS) or "virtual dedicated server" (VDS). In this case, the setup options of an administrator are significantly more limited. For example, the installation must follow the provider's specifications and organizational requirements.
The =goal= is
(a) to facilitate and simplify the operation of a Fedora server in such a runtime environment by providing special documentation and
(b) also provide customized installation media, if useful.
———
Ticket: https://pagure.io/fedora-server/issue/110
Discussion of our first priority project via hacked.io is not so successful, so far. Maybe it’s easier using the Mailing List.
As a =next step= I suggest to post on the user mailing list and on discussion and ask for experiences running Fedora Server in a (commercial) VPS / VDS.
It would be really helpful if we could reach agreement on the project plan as well as the next step in the next few days. The dead line for a change proposal (if we want to offer a customized installation medium) is July 18, 2023. That's still a little way off, but not too long either.
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
PBoy(a)fedoraproject.org
Timezone: CET (UTC+1) / CEST /UTC+2)
Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast
Again, for everyone's convenience, a brief summary of our IRC meeting right here.
For greater details see meetbot
== Summary: ==
https://meetbot.fedoraproject.org/fedora-meeting/2023-02-01/fedora-server.2…
== Full log: ==
https://meetbot.fedoraproject.org/fedora-meeting/2023-02-01/fedora-server.2…
== Essentials ==
We agreed: WG will pursue 'Fedora Server Edition on SBC' as first priority for F39, and 'Fedora Server Edition in virtualized environments' as 2nd priority.
ACTION: pboy will post a first draft regarding 'Fedora Server Edition on SBCs' on hackmd.io for further discussion.
The same priority list applies to the action "Each Edition has a story for each release" regarding F39.
== Next Action ==
We need a catchy (marketable) wording for the project titles 'Fedora Server Edition on SBC' and 'Fedora Server Edition in virtualized environments'.
Native english speakers: You are in demand!
We agreed last meeting to evaluate
* ServerVM support for various hosting services
and
* Usage of SBC as a Server device
as short term goals for F39.
Here some ideas about those
Fedor's server in the virtualized environment of hosting providers
==================================================================
Why?
----
We are currently very focused on installation and operation on bare metal. There are 2 different media, successfully optimized to make the installation on different hardware as simple and straightforward as possible. For years, the number of hosting providers that offer Virtual Private Server (VPS) rsp. Verutal Dedicated Server (VDS) has been growing. We do not offer comparable support for this in any way - unlike other distributions.
It is time to support the various virtualized environments as well. Thus, we can strengthen the ddissemination and use of Fedora Server. At the same time, there are requests from the community about installing on VPS/VDS offerings.
The target environment(s)
-------------------------
There are a large number of VPS/VDS providers.
* Some offer pre-configured distributions and custom images
* Some offer only pre-configured images, all offer Ubuntu/Debian, often also RockyLinux/AlmaLinux, some (few) also Fedora
In a first step wie should target custom images..
Outcome
-------
The result would be additional installation images and target-specific documentation. In a first step, a limitation to 2-3 providers would make sense, e.g. Contabo and Amazon AWS (Lightsail).
We thus have the option to allocate different providcer among us and work on them in parallel.
Preparatory work
----------------
We have an existing (and working) test and development system to develop additionional Server VMs using ImageFactory and Kickstart. The resulting kickstart file can be used on koji without any problems. We thus have the option to allocate different providcer among us and work on them in parallel.
Ressources
----------
We need just temporary ( cost-free ) test accounts. In my experience, this is generally not a problem. Thus, each of us could participate in it. No one would be excluded because of a lack of resources.
Fedora Server on ARM Single Board Computers (SBC)
=================================================
Why?
----
Single board computers are currently a much discussed topic. In many cases, they are associated with the hope of good performance adapted to the task at hand, combined with sustainability and reasonable costs. Therefore, it is not surprising that a Fedora Server Edition installation image has also been available for these devices for a long time, without, however, attracting much attention so far.
Over the last years, the technology greatly evolved and differentiated into a large number of different devices. Still, what's a solid, professional server system like Fedora Server Edition doing on such a device? Criteria for the selection of a suitable device are to be compiled, possible application scenarios determined, and configuration and installation support developed for this purpose.
Outcome
-------
The result would essentially be documentation and recommendations, possibly also scripts or Ansible support for specific configuration and installation steps. In the longer term, better support for the use of SATA or VNMe devices, which would currently allow easier handling of SPI modules and switching to these types of memory.
In the longer term, better support for the use of SATA or NVMe devices would be required, which would currently mean easier handling for SPI modules and switching to the aforementioned storage types after finishing booting from mSD or eMMC storage.
We could also revive the proposal to create an article in Fedora Magazine.
Preparatory work
----------------
We already have a draft on an article which specifies some criteria and considerations of potential usage.
Ressources
----------
The selection of target devixces is certainly arbitrary and depends on what equipment is available to us. However, an assessment of available devices can also be made "theoretically" on the basis of the product description. Or we can re-assess devices that are recommended in relevant special publications (e.g. https://www.androidpimp.com/embedded/best-single-board-computers-2023/ or similiar). Perhaps the possibility of gaining access to test devices will also open up.
Of course, we don’t need do decide for one over the other. We can also pursue both. That might even be more sensible, in order to possibly have alternative options.