This is a post where I suggest work without any commitment to helping. I'm
I'm trying to help someone here:
... where they're trying to set up an NFS/Samba share using Cockpit. That
seems like it _should_ be easy. Now, this particular person is new and
there's some basic concepts to work on first, but... also, it turns out
Cockpit doesn't actually have an included tool for doing that. This kind of
surprises me, but is also the kind of thing I just don't know because I'm
not a working sysadmin anymore. (I kind of miss it sometimes....)
I talked to Stephen Gallagher and this is something he was looking at but
doesn't have time for. There is a third-party add-on
https://github.com/45Drives/cockpit-file-sharing which looks pretty great,
but is specifically made for 45Drives, and may be difficult to generalize
and package for Fedora Server.
But that seems _really_ worth doing. Anyone interested in taking that on?
Fedora Project Leader
I have chosen to address this effort in the mailing list, so as not to consume all of the oxygen during our IRC
I started this effort by cloning https://github.com:KAMI911/ansible-role-wildfly .
It soon became apparent the cloned role supported RHEL 6 (currently no longer receiving updates) and older versions of
Wildfly no longer supported by the Wildfly Project. Also the support for server startup/shutdown using systemd did not
The cloned project also used the legacy security system provided by Picketbox. This security system was dropped from
Wildfly 25 which was released on October 05, 2021. The new security system is provided by Elytron.
As a result of all of the above, I decided to refactor ansible-role-wildfly into more manageable pieces (the old version
has some very long and complex task files). I also removed all of the code that supported RHEL 6. I have updated the
minimum requirements for RHEL to 7 and Wildfly to release 25. I have removed the support for init.d (SYSV)
startup/shutdown and fixed the issues with using systemd for startup/shutdown.
Currently, the refactoring only supports "standalone" server configuration. The cloned "domain" server configurations
(master/slave) seems to have fallen out of favor and the Wildfly Project now supports HostControllers (one of which acts
as a DomainController) along with Server instances (and optional Server Groups). As soon as I complete the efforts to
enable SSL and Elytron (as described below), I plan to circle back and work on supporting this new "domain"
The refactored module currently installs, configures, starts and stops Wildfly 25 in standalone mode.
I propose configuring Wildfly's SSL capabilities in a separate Ansible role. That is my plan unless someone with more
Wildfly experience that I possess, suggests otherwise.
The new Elytron security system supports a single unified front-end interface. The storage mechanism can be provided by
several different backend storage methods. Those methods include properties files, filesystem directories and files,
LDAP, database, and Kerberos. Rather than develop a single complicated Elytron role, I propose implementing each
storage mechanism in it's own Ansible role.
1) Does my plan for SSL and Elytron make sense?
2) Which Elytron storage mechanism should be the "recommended" for sites new to Wildfly?
3) Is there a need to provide for configuring multiple standalone instances on the same server? This would require some
reworking of port number assignments inside the Ansible role.
4) Is Fedora's pagure mature enough to host an effort like this? If so, would someone kindly provide a pointer for a
novice to begin learning how to access and use it? Or should we use github or gitlab instead?
5) The Wildfly Project provides several different configuration files (full, full-ha, ha, load-balancer, microprofile,
and microprofile-ha) in addition to standalone.xml for standalone servers. I have chosen to only update and support
standalone.xml. Is there a significant demand to support any of the others standalone configurations?
6) Should support for third party certificates and Lets Encrypt certificates be separated into separate Ansible roles or
just have a single role for installing certificates?
7) Does anyone have experience using JCliff to configure Wildfly instances?
PS: The work progresses slowly because Wildfly documentation often assumes configuration and operational support via a
GUI or via jboss-cli.sh commands (which are often difficult to make imdepotent). Hopefully, by doing some reverse-
engineering, I can figure out how to use the community.general.xml module to update the standalone.xml file.
The meeting is scheduled:
Fedora Server IRC meeting Wednesday, December 01 17:00 ==UTC==
#fedora-meeting at irc.libera.chat
Please, check your local time using date -d '2021-11-17 17:00UTC‘
According to my notes we have to discuss
== Agenda ==
1. = Follow up actions =
2. New WG Doc Landing Page and Navigation Items
3. == Migration of unmodified Wiki content ==
4. == Decommissioning of (old) SIG Wiki pages ==
5. == Review current Fedora Server Technical Specification ==
Commentable version at hackmd.io: https://hackmd.io/qBGmKuZPQ5OloAec3_Nh3w
6. == Facilitated and improved support for Fedora Server Edition VMs ==
7. == Using Ansible to install and configure Wildfly ==
8. == Open Floor ==
It is a relatively large number of topics for a meeting. Items 3 and 4 can perhaps be dealt with very quickly and item 5 is only intended to serve as an initial discussion.
Nevertheless, if you wish to add a topic, please reply to this message.
Please everyone, provide feedback!! Either here on mailing list or by commenting on the issue. This concerns topics that are considered to be of particular interest / relevance as well as those that should discarded / don’t need a IRC meeting.
=== Other upcoming topics in the books ===
(I’m preparing but *not yet* finished)
= Revisiting our release criteria =
As proposed by Stephen Gallagher sometimes ago
= Preparation of a SBC reference list =
As discussed on mailing list
= Revisiting our quality criteria and procedures =
As discussed on mailing list
= Specifying F36 manual test requirements =
As discussed on mailing list
= Adding Upgrade notification (dns-automatic) to install image =
As discussed on mailing list
= Fedora Website Revamp =
Ongoing work, we will need content related to Fedora Server sometime soon.
= Evaluating Fedora Server Working Group =
We have some members who never showed up nor contributed any work. Others have obviously evolved other interests in the meantime. And we have (new) contributors formally not members.
Nov. 17, 2021:
= Revisiting "Software Selection" options in Server Installation
= Fedora Server Edition default editor
Last IRC meeting we decided to migrate our Wiki to Fedora docs / engineering teams, mowestusa and me was designated to take charge of the organizational matters.
As you may have noticed everything moved faster as expected (many thanks to Ben Cotton). We have a correct entry on the Engineering Teams page (https://docs.fedoraproject.org/en-US/engineering/) and most importantly we already have an address for our new pages:
There is also a preliminary landing page and a suggestion for a site navigation. The navigation items are without linked pages (except Communication and Meeting)and are only meant to give an impression.
At our next meeting, we need to discuss and decide on this.
It would be helpful to discuss this here in preparation before our IRC meeting. We must at least agree about the content of the landing page, because it is already linked on docs public site.
already includes a kind of placeholder for Fedora Server Working Group, currently ponting to our Wiki page.
We would like to get the future address (probably https://docs.fedoraproject.org/en-US/server-working-group/ in analogy to the Workstation group) link to subdirectory „wg" of our repository (https://pagure.io/fedora-server/blob/main/f/wg)
The current link to our Wiki page could be replaced by the new address. The current landing page is short, but contains a link to the wiki page either. So no information is lost, even if the state of the index page at the moment makes a somewhat imperfect impression.
If possible, we would like to have a staging address as well, eg. https://docs.stg.fedoraproject.org/en-US/server-working-group/ in analogy to the staging version of our user documentation.
And last but not least we would like to have the name of our group in bold like the other entries in the list and as description the text "Information about the work on Fedora Server Edition".
It may be worth considering systematically keeping our official ‚branding' for the group names, which would be "Fedora Workstation Edition Working Group" , "Fedora Server Edition Working Group“ , „Fedora IoT“ etc.
For example, we also have a generic minimal server, and especially a 'Fedora Server Edition' with a specific set of programs and tools, and a specific default configuration and property profile (Well, it's kinda a marketing issue and maybe nothing worth for an engineering perspective),
Most fitness enthusiasts have favorite apps to track activities and
share with friends. Often, advanced features need a paid membership.
Still, it is limited to fixed features and I get distracted or let
down by certain features, which I don't need. Feature mismatch
I have 7+ years of fitness data in Strava. The main sport is cycling.
I want to keep the data in my control and design a custom dashboard
using the Fedora server and R Pi. It's not huge data, so I'll stay
away from the cloud. This is proof of concept if I want to expand this
further in the future.
Build data pipeline with fitness API (start with Strava).
Set up a database server on R Pi.
Write SQL scripts for data ingest and metrics.
Add Python scripts for calculation and display,
Connect to Dash apps (or equivalent open-source analytics tool).
(Optional) Expand data source to fitness sensors (cycling computer and
Heart rate monitor) for richer metrics.
Will this be of any use or interest to the Fedora community?
Happy Thanksgiving day!
I'm working on a backup server for home using R Pi.
My take-on with the ARM server and R Pi is
A low-power space-saving backup server with Fedora ARM server 35
Central access of files wherever
Data loss prevention of creative work: A simple 3-2-1 backup strategy at
Test scenarios & reporting
With imagination and budget, this could scale out to a high-performance
backup server for your home lab.
FYI, I'll be at the Open Source Experience event in Paris, France over
the next two days.
I'm hoping to be able to talk to the people at the Centreon and Itop
booths about supporting Fedora Server as a platform.