Today there was an IRC discussion about the next tasks Fedora Server WG has to work on. I would like to give here a short overview in the hope that many may contribute their ideas here. The wording is unimportant, short sketches of ideas are sufficient. A editorial group has been established to edit a proposal for a revised draft. But we need input from the server community!
Our current PRD is here: https://fedoraproject.org/wiki/Server/Product_Requirements_Document , general considerations on the structure of such a document are here: https://en.wikipedia.org/wiki/Product_requirements_document
The current PRD is from 2014. Urgently needs to be revised along the following general objectives:
- We want the target audience and server edition goals to keep up to date as the computing world changes - But there are also big changes in how servers are used and deployed. Fedora should be at the forefront.
This leads to at least 4 questions: - What are the high level goals? - What is our *market*? - how server relate to curent developments, coreos cloud, etc.? - merging in the Cloud Base image so it's basically just an alternate deploy of server?
Please, contribute your ideas!
Some detailed opinions were thrown in:
- Server should forcus on mostly headless services - single node deployments, and multi node deployments
- A goal might also be pushing for text-only mechanisms for all relevant administrative functions (cf. the gpg-agent discussion)
- focus on soho rather than enterprise at this point.
- strong container support in "my basement" and in "soho".. including things like openshift
- are server roles still a thing? (The Server Roles in PRD were abandoned?)
- are tools/app included supporting industry change (e.g. IPMI is deprecated, Redfish is the future)
Any inout greatly appreciated.
Peter (One of those to draft an updated proposal)
On Wed, Dec 16, 2020 at 11:01:42PM +0100, Peter Boy wrote:
Today there was an IRC discussion about the next tasks Fedora Server WG has to work on. I would like to give here a short overview in the hope that many may contribute their ideas here. The wording is unimportant, short sketches of ideas are sufficient. A editorial group has been established to edit a proposal for a revised draft. But we need input from the server community!
Awesome -- thanks for putting this together!
Take the following as just my opinion, not an FPL directive of any sort...
- A goal might also be pushing for text-only mechanisms for all relevant administrative functions (cf. the gpg-agent discussion)
I agree everything should be doable from the command-line (and tools like Ansible). But I also think Cockpit is a nice part of our story. It fits into the small/home environment and can help make things as easy as Windows while still making the power of Linux available. And it works great as a remote GUI.
On Mi, Dez 16, 2020 at 23:01, Peter Boy pboy@uni-bremen.de wrote:
The current PRD is from 2014. Urgently needs to be revised along the following general objectives:
- We want the target audience and server edition goals to keep up to
date as the computing world changes
- But there are also big changes in how servers are used and
deployed. Fedora should be at the forefront.
This leads to at least 4 questions:
- What are the high level goals?
- What is our *market*?
- how server relate to curent developments, coreos cloud, etc.?
- merging in the Cloud Base image so it's basically just an alternate
deploy of server?
Hi y'all,
thank you for the opportunity to attend to the meeting yesterday.
There was a lot of impressions and ideas, which left me a bit puzzled in the end. Below I have tried to address my questions and to address the questions. Please keep in mind, that this is my very personal view. Leaving my background at Ansible aside, I have no knowledge of earlier decisions, discussions or processes. I would appreciate feedback, critiques, questions and a lot of patience on your side :) Hopefully I will be helpful at some point in time.
Thanks a lot in advance for your time.
---------------------------------------------
# 1) My questions
- Is there a general difference between SIG Server and Server WG? - Is there some general scope of both and overlaps to other SIGs and WGs?
---------------------------------------------
# 2) My view on the above questions
## High Level goals
For me, it is quite hard to define high level goals. But maybe I can provide my intention, why I started to use Fedora as a Server distribution.
I am a IT/Dev/Ops/DevOps Consultant working mostly for companies, that are having the below issues:
- developers require new software (php, node, ruby, java, name-it) - operators need to maintain 2-3 hardware vendors, 2-3 major versions of OS, 2-3 different OS types - business has several demands to developers and operators (yesterday!!!11)
The bottleneck very often was a situation of "we need to maintain A, B is running only on C, D is to old for E, F is so old - nobody wants to touch it, G takes ages, because somebody needs to backport H. Other issues are often something coming from Security and Audits, which require: Audit Tools, Log Monitoring, regular Patches, Firewall, SELinux/Apparmor, Hardening for X, etc.
Many of these problems were solvable with Fedora as a plattform and/or/optional RHEL'ish ecosystem.
- many security tools out of the box (usbguard, SELinux, firewalld, auditd, aide, etc.) - kernel is very new and therefore supports tons of hardware - software is very new and supports tons of developer demand - additional software like cockpit, pcp, tuned, etc. is very handy for small to larger environments (nobody wants to use cockpit to manage 100s of servers, but providing a UI for devs/unexperienced ops/hosting customers is quite nice) - fedora-minimal is quite nice container base to build upon - the awareness of EOL and mitigation plans are immediatly a thing, if the lifetime is 13 month only - the awareness of single instance SLA is a thing, if you should patch at least every 90 days AND reboot - developers are able to use the same tools on their notebook/workstation they can use on the servers/images
"But there is this 10 year old ERP/CRM/Connector, that nobody wants to touch."
- Why touching it then? - Is it worth the effort? - What does it cost to migrate to a new OS compared to migrate to a new ERP? - If nothing fits, RHEL/CentOS is basically the same ecosystem and will run for 10 years support.
## Market
I can see at least the following personas (all of them is me to some degree) using Fedora Server:
### The Tinkerer
I have a raspberry/intel nuc/etc. and playing a bit with new stuff. I need a lot of "cool" packages. Newest nodejs, php8, GPIO support, build tools, containers, vms, name-it. Give me all of this, in BETA please. I want the newest shit and I want to break it.
### The Home Admin
I need a somewhat stable machine, with a graphical interface (cockpit) and just want to start a couple of containers and/or VMs to have nextcloud running on it. I need some gitea here, some gitlab there, some jenkins, some photoprism, minecraft, etc. Can I build a NAS easily? I am ok with updates and reboots over night, but it should work. It would be awesome to have mDNS and a Web UI.
### The Developer
I need to have a plattform, that feels like my workstation. I want to build containers, start them, test them and push them. If I can have nodejs, ruby, php in a decently current version, that would be awesome. I am ok pulling stuff from "the interwebs", as long as it works and does not bother me too much with: "This container will not run on RHEL, because it requires X or Y." Yesterday I read something about "remote podman", can I use it? Why isn't podman dnsname plugin working on the servers, but on my Fedora Workstation? What does the admin mean with "prepare the image for virtualization/cloning/templating"?
### The Operator
I want to have a reliable plattform for virtualization, core services and container. It should be out of my way, so I can focus on scaling, monitoring, implementation. I want to automate configurations for hostname, timeserver, hardening, etc. In addition I want to deploy typical services like mariadb, httpd, nginx, redis, nodejs, java, etc. in a reproducible way. To see what the machines are doing, I need a well documented way to manage, monitor and backup them. My Security Team also wants me to disable unneeded services, disable legacy protocols, enable hardening on several levels.
### The "Let's make a distribution" / "Let's build upon it"
I love how Fedora works and I want to create something upon it. My new distro will feature all the cool fedora things and I want to add some software on top of it. I need a very well documented build process and maybe tools to produce new install images and packages. Removing the branding should be possible with some compiler flags or variables, so I don't need to mess with the code itself.
This will allow me to build my new distribution which will be the perfect:
- NAS - CloudStorage - media server - gaming server - home server - SOHO distribution - etc.
## Relation to cloud, coreos, etc.
I am not very deeply involved in these projects. But some examples are coming to my mind.
For example, the IoT Edition features 2 tools (greenboot and zezere), which may be a nice addition for smaller environments or edge computing. Both tools are currently meant for IoT only, but can be easily adopted. Zezere for example can be used to add SSH Keys (or else) to remote edge servers and greenboot is capable to trigger scripts if something goes wrong.
For the cloud/coreos approach, there is even more stuff in both ecosystems. podman, docker and kubernetes are a thing that are present on both platforms. Ignition on the other hand shares some of the capabilities of kickstart (at least from a user perspective). I am not sure why 2 different deployment approaches, that basically do the same (preconfigure a system) should co-exist on the long run. To be honest coreOS in its current state lacks some features, that I personally love and even Fedora IoT or Silverblue feel more "mature". For example installing cockpit on Fedora IoT is basically the same as in fedora server. The cockpit deployment on coreos does not work the way it is documented and the IoT way does not work either. CoreOS (at least for now) seems somewhat out of place.
Supporting each other to have a coherent experience, where everything "feels" well known would be the only correct step from my perspective.
---
### Contact
daniel@while-true-do.io while-true-do.io
### Web
style-cheat.io while-true-do.io
### Code
github.com/while-true-do/ github.com/style-cheat/ github.com/kudos-txt/ github.cim/daniel-wtd/
### Social
twitter.com/daniel_wtd reddit.com/u/daniel-wtd daniel-wtd @freenode
### Disclaimer
If not stated otherwise all of my work is licensed under a Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/).
On Thu, Dec 17, 2020 at 07:36:44PM +0100, daniel-wtd wrote:
- Is there a general difference between SIG Server and Server WG?
Both "SIG" (Special Interest Group) and "Working Group" are labels we use for Teams within the Fedora Project. Generally, a SIG is very informal and membership just a matter of saying you're interested, while a Working Group has more formal membership with rules for who votes and how votes are counted on important issues.
I hope that clears that up a little?
(And thanks for the other user-focused insights!)
On Do, Dez 17, 2020 at 13:44, Matthew Miller mattdm@fedoraproject.org wrote:
I hope that clears that up a little?
Absolutely :) Thanks a lot. ---
### Contact
daniel@while-true-do.io while-true-do.io
### Web
style-cheat.io while-true-do.io
### Code
github.com/while-true-do/ github.com/style-cheat/ github.com/kudos-txt/ github.cim/daniel-wtd/
### Social
twitter.com/daniel_wtd reddit.com/u/daniel-wtd daniel-wtd @freenode
### Disclaimer
If not stated otherwise all of my work is licensed under a Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/).
Some awesome thoughts in this thread. :)
I'll share my Fedora use cases (which overlap several others that have already posted):
1. Home server. I run Fedora server as my main virthost + gateway + Fedora server vm's on it for various services.
2. Fedora infrastructure: We run a lot of Fedora in fedora infrastructure. All the builders are Fedora, many of our application servers are Fedora when they need newer tools than RHEL, many of our applications in openshift run in Fedora containers, our proxy servers, etc.
I think we could pull in the cloud image (If the cloud sig agrees/joins us or we join them), but possibly we could target it for clouds + a vm raw image.
kevin
I think one important question is WHY we use Fedora.
In my case, I started using Fedora because it had the latest stable drivers for the newest hardware. With today's hardware performances and the widespread use of virtualization, that is no longer an issue (or at least not a big issue).
I still use Fedora because it has the latest stable version of most packages and modern sysadmin tools (i.e. cockpit, dnf, systemd were all "tested" with Fedora).
What I mean by "stable" is that Fedora is not bleeding edge (like Rawhide), but stable enough to put in production and give it a try.
As for roles, I don't think Fedora Server can compete in the hypervisor/hyperconvergence arena against Proxmox or Xen.
Taking all this into account, this is how I view "Fedora Server" goals:
- Provide a minimalistic server install (for instance, NetworkManager is overkill for a server, and in many cases a hindrance). - Key packages like databases, languages, Web infrastructure must be solid and pre-configured for high loads (things like php-fpm, nginx, Postgres, etc.). - Provide kernels tuned for large RAM, high storage I/O and high network I/O. - Provide easy integration into multi-node environments, with tools like Ansible (we may have to favor one such tool, like we favor cockpit). - We must keep upgrades smooth, as they are now with dnf. - A "Security Profile" may be suitable. For instance at a minimum a nice Firewalld+Fail2Ban configuration, then go up with Snort, Tripwire, SELinux.
In short, have a distro that can be deployed in 5min in a small VM and start doing something useful half an hour later :-)
Carlos
On Wed, Dec 16, 2020 at 11:02 PM Peter Boy pboy@uni-bremen.de wrote:
Today there was an IRC discussion about the next tasks Fedora Server WG has to work on. I would like to give here a short overview in the hope that many may contribute their ideas here. The wording is unimportant, short sketches of ideas are sufficient. A editorial group has been established to edit a proposal for a revised draft. But we need input from the server community!
Our current PRD is here: https://fedoraproject.org/wiki/Server/Product_Requirements_Document , general considerations on the structure of such a document are here: https://en.wikipedia.org/wiki/Product_requirements_document
The current PRD is from 2014. Urgently needs to be revised along the following general objectives:
- We want the target audience and server edition goals to keep up to date
as the computing world changes
- But there are also big changes in how servers are used and deployed.
Fedora should be at the forefront.
This leads to at least 4 questions:
- What are the high level goals?
- What is our *market*?
- how server relate to curent developments, coreos cloud, etc.?
- merging in the Cloud Base image so it's basically just an alternate
deploy of server?
Please, contribute your ideas!
Some detailed opinions were thrown in:
- Server should forcus on mostly headless services - single node
deployments, and multi node deployments
- A goal might also be pushing for text-only mechanisms for all relevant
administrative functions (cf. the gpg-agent discussion)
focus on soho rather than enterprise at this point.
strong container support in "my basement" and in "soho".. including
things like openshift
are server roles still a thing? (The Server Roles in PRD were abandoned?)
are tools/app included supporting industry change (e.g. IPMI is
deprecated, Redfish is the future)
Any inout greatly appreciated.
Peter (One of those to draft an updated proposal) _______________________________________________ server mailing list -- server@lists.fedoraproject.org To unsubscribe send an email to server-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org
On 18/12/20 10:14, Carlos Vidal wrote:
I think one important question is WHY we use Fedora.
In my case, I started using Fedora because it had the latest stable drivers for the newest hardware. With today's hardware performances and the widespread use of virtualization, that is no longer an issue (or at least not a big issue).
I still use Fedora because it has the latest stable version of most packages and modern sysadmin tools (i.e. cockpit, dnf, systemd were all "tested" with Fedora).
What I mean by "stable" is that Fedora is not bleeding edge (like Rawhide), but stable enough to put in production and give it a try.
As for roles, I don't think Fedora Server can compete in the hypervisor/hyperconvergence arena against Proxmox or Xen.
Taking all this into account, this is how I view "Fedora Server" goals:
- Provide a minimalistic server install (for instance, NetworkManager is
overkill for a server, and in many cases a hindrance).
- Key packages like databases, languages, Web infrastructure must be solid
and pre-configured for high loads (things like php-fpm, nginx, Postgres, etc.).
- Provide kernels tuned for large RAM, high storage I/O and high network I/O.
- Provide easy integration into multi-node environments, with tools like
Ansible (we may have to favor one such tool, like we favor cockpit).
- We must keep upgrades smooth, as they are now with dnf.
- A "Security Profile" may be suitable. For instance at a minimum a nice
Firewalld+Fail2Ban configuration, then go up with Snort, Tripwire, SELinux.
In short, have a distro that can be deployed in 5min in a small VM and start doing something useful half an hour later :-)
Carlos
+1
Elio
@daniel-wtd, @Carlos Vidal, @Elio Tondo Thank you very much for your input. I am relieved and somewhat excited and motivated by it. All too often "we all care" turns into "nobody does“. And yes, even just a +1 to a specific topic helps a lot because it provides direction of what has broad support and where further work should be directed.
I hope others will also be motivated (and activated - wink wink).
I have a query and I hope it is well received. Due to what happened with CentOS, will it be very crazy that Fedora Server can take, in part, certain missions and visions of CentOS? Certainly Fedora has stability, at the same time it manages to be up-to-date, however it can perfectly find a place for many who used CentOS.
At least as Carlos Vidal said, you can perfectly focus on services such as databases, languages, Web infrastructure, pre-configured and with a kernel tuned for performance.
It would also be nice to have a minimal and hardening version, in terms of security.
El vie, 18 dic 2020 a las 7:02, Peter Boy (pboy@uni-bremen.de) escribió:
@daniel-wtd, @Carlos Vidal, @Elio Tondo Thank you very much for your input. I am relieved and somewhat excited and motivated by it. All too often "we all care" turns into "nobody does“. And yes, even just a +1 to a specific topic helps a lot because it provides direction of what has broad support and where further work should be directed.
I hope others will also be motivated (and activated - wink wink). _______________________________________________ server mailing list -- server@lists.fedoraproject.org To unsubscribe send an email to server-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org
On Fri, Dec 18, 2020 at 10:14:47AM +0100, Carlos Vidal wrote:
I think one important question is WHY we use Fedora.
In my case, I started using Fedora because it had the latest stable drivers for the newest hardware. With today's hardware performances and the widespread use of virtualization, that is no longer an issue (or at least not a big issue).
I still use Fedora because it has the latest stable version of most packages and modern sysadmin tools (i.e. cockpit, dnf, systemd were all "tested" with Fedora).
What I mean by "stable" is that Fedora is not bleeding edge (like Rawhide), but stable enough to put in production and give it a try.
As for roles, I don't think Fedora Server can compete in the hypervisor/hyperconvergence arena against Proxmox or Xen.
Taking all this into account, this is how I view "Fedora Server" goals:
- Provide a minimalistic server install (for instance, NetworkManager is
overkill for a server, and in many cases a hindrance).
In favor of... ? systemd-networkd might make sense I guess.
Do note that NetworkManager has gotten vastly better in recent years (IMHO). It can run and exit after setting things up, it has a really nice cli/tui, etc. I find it handy on servers too if you need to setup a vpn, or the like.
- Key packages like databases, languages, Web infrastructure must be solid
and pre-configured for high loads (things like php-fpm, nginx, Postgres, etc.).
- Provide kernels tuned for large RAM, high storage I/O and high network
I/O.
Do note that we can urge maintainers to do things for us, but not sure we can ship seperate kernels and packages. Generally it's better to make the packages usefull for many use cases and easy to tune/change/configure.
- Provide easy integration into multi-node environments, with tools like
Ansible (we may have to favor one such tool, like we favor cockpit).
- We must keep upgrades smooth, as they are now with dnf.
- A "Security Profile" may be suitable. For instance at a minimum a nice
Firewalld+Fail2Ban configuration, then go up with Snort, Tripwire, SELinux.
In short, have a distro that can be deployed in 5min in a small VM and start doing something useful half an hour later :-)
Yep. We have that now and we should keep pushing it forward.
Good ideas. :)
kevin
Am 19.12.2020 um 20:08 schrieb Kevin Fenzi kevin@scrye.com:
On Fri, Dec 18, 2020 at 10:14:47AM +0100, Carlos Vidal wrote:
I think one important question is WHY we use Fedora.
- Provide a minimalistic server install (for instance, NetworkManager is
overkill for a server, and in many cases a hindrance).
In favor of... ? systemd-networkd might make sense I guess.
Do note that NetworkManager has gotten vastly better in recent years (IMHO). It can run and exit after setting things up, it has a really nice cli/tui, etc. I find it handy on servers too if you need to setup a vpn, or the like.
We may be in a kind of quandary here. Fedora switched to systemd-resolved for DNS and dismissed NetworkManager. According to various posts, this led to misconfiguration on systems using NetworkManager DNS plugin. Systemd-networkd would be a solution. But a lot of packages have NetworkManager as a dependency. In this respect, NetworkManager cannot be replaced so easily.
On Sat, Dec 19, 2020 at 10:55:37PM +0100, Peter Boy wrote:
We may be in a kind of quandary here. Fedora switched to systemd-resolved for DNS and dismissed NetworkManager. According to various posts, this led to misconfiguration on systems using NetworkManager DNS plugin. Systemd-networkd would be a solution. But a lot of packages have NetworkManager as a dependency. In this respect, NetworkManager cannot be replaced so easily.
NetworkManager isn't replaced -- the feature is actualyl turning on systemd-resolved support in NetworkManager. https://fedoraproject.org/wiki/Changes/systemd-resolved#Detailed_Description
On Sat, Dec 19, 2020 at 10:55:37PM +0100, Peter Boy wrote:
We may be in a kind of quandary here. Fedora switched to systemd-resolved for DNS and dismissed NetworkManager. According to various posts, this led to misconfiguration on systems using NetworkManager DNS plugin. Systemd-networkd would be a solution.
NetworkManager wasn't dismissed. ;) It's still the primary way to configure networking in lots of media. The NM dns plugin can and does talk just fine to systemd-resolved. The only issues I have heard of are misconfiguration on the user end or problems upgrading a system that used something else before. :)
But a lot of packages have NetworkManager as a dependency. In this respect, NetworkManager cannot be replaced so easily.
The installer (anaconda) needs it, but you don't have to have anaconda still on an installed machine, you could remove it.
In any case, I personally would be fine sticking with NM, but I know others may disagree.
And I've pulled the conversation from high level to details... sorry about that.
kevin
Am 19.12.2020 um 23:11 schrieb Kevin Fenzi kevin@scrye.com:
On Sat, Dec 19, 2020 at 10:55:37PM +0100, Peter Boy wrote:
We may be in a kind of quandary here. Fedora switched to systemd-resolved for DNS and dismissed NetworkManager. According to various posts, this led to misconfiguration on systems using NetworkManager DNS plugin. Systemd-networkd would be a solution.
NetworkManager wasn't dismissed. ;) It's still the primary way to configure networking in lots of media.
Sorry, I have phrased this in a misleading way. I meant "dismissed" to handle DNS / resolv.conf, not dismissed at all. But that is also wrong as I have learned, NetworkManager is "systemd-resolved aware". Very reassuring (I have a lot of scripts to configure NM for my servers).
And I've pulled the conversation from high level to details... sorry about that.
At some point we have to go into details. :-)
Peter
server@lists.fedoraproject.org
-
Carlos Vidal -
daniel-wtd -
Elio Tondo -
Felipe Saez -
Kevin Fenzi -
Matthew Miller -
Peter Boy