Call for agenda Items on 2023-03-15 18:00 ==UTC== meeting
by Peter Boy
===========================================================
Fedora Server IRC meeting Wednesday, March 15 18:00 ==UTC==
irc.libera.chat #fedora-meeting
===========================================================
ATTEWNTION: Daylight saving time changeover
===========================================
Following an overview provided by Ben, in the US, Canada and parts of Mexico summertime changeover has started this week. For membersin these countries our meeting is **shifted by one hour**!
Please, check your local time using date -d '2023-03-15 18:00UTC'
With our subsequent meeting at April 4 (after a THREE week gap this time) all countries will have done the changeover. We should shift our meeting time again, this time to 17:00 UTC so it is the same time at local time as during winter (and summer last year).
==== Agenda ====
#link https://pagure.io/fedora-server/report/Meeting
To be able to discuss all topics on the agenda and to prevent us from repeatedly putting off topics that have not been dealt with, we should set time limits for the individual items on the agenda. If we need more time, we should continue on the mailing list.
1. === Follow up actions === 5 mins at max
2. === Change of timing of our meetings in summer === 5 mins at max
Proposal: Meeting time 17:00 - 18:00 UTC starting April 4, 2023 until the fall (same as last summer).
3. === F38 Beta testing === 15 mins at max
#link https://pagure.io/fedora-server/issue/99
Current status: Server VM doesn’t work correctly, waiting for the fix PR to get processed.
4. === Shorter Shutdown Timer === 20 mins at max
#link issue #96: https://pagure.io/fedora-server/issue/96
Mailing list discussion:
#link https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject....
#link https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
#link https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject....
5. === Fedora Website revamp – Fedora Server Edition pages === 10 mins max
#link Issue #66: https://pagure.io/fedora-server/issue/66
Mailing List:
#link https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject....
The project is in it's final stage, so we must make final decisions
* about wording
* about graphical elements
6. === Using Ansible to install and configure Wildfly === about 10 mins
#link https://pagure.io/fedora-server/issue/60
Mailing List:
#link https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject....
(step through the posts using „newer“ and „older“, I can’t manage to get a link to the complete thread)
#link https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject....
We have to discuss how to proceed.
5. === Open floor ===
For any additions or changes, please reply to this email.
For an overview about current tasks look at:
https://pagure.io/fedora-server/boards/Works%20in%20progress
1 year, 1 month
meeting 2023-03-15 shutdown timeout proposal
by Peter Boy
Systemd maintains a shutdown time, previously set to 120 secs, now changed to 45 secs (if I remember correctly).
It a process doesn't completly terminates in case of a shutdown in 120 secs max, systemd kills the process forcefully.
That means:
Case 1: Everything works normally and as expected
=================================================
All processes terminate in a short time as safely possible, and the system shutdown completes in a correspondingly short time frame. Systemd does not wait x secs until it completes shutdown and has no effect at all and is superfluous.
If a process has overwritten the default timeout, systemd waits that time before it kills the process. Processes that did not overwrite the default, get killed after default 120 secs (or now default 45 secs). 120 secs is pretty long. So, as long as everythins works normally, nothing bad should happen.
Anyway, the system comes down as fast as possible, no shorter time possible.
The default time out does not matter!
Case 2: Some processes "hang" due to an error and stop with termination
=======================================================================
This is an unrecoverable error and termination must be forced, either by systemd (i.e. forcefully kill the process) or otherwise. Question is, how do you determine whether a process is "hanging".
A default timeout value if *properly* determined may be useful. A wildly guessed value is more harmful than beneficial.
Case 3: Some processes take unexpectedly longer to terminate
============================================================
As long as a program is working, it is not wise to cancel it. The risk of significant damage (data loss) is too high.
To ensure that a default timeout value does not do more harm than good, it must be calculated with sufficient generosity.
A timeout value is either harmful or ineffective at best.
In summary:
===========
(a) A short default timeout does not bring any advantage to a functioning system. With a slowed down or otherwise impaired system, a short timeout value brings a high risk of damage.
(b) Even if some process(es) correctly requests a longer timeout, other processes that do not, but rely on a reasonable behavior of the overall system, can still be abruptly terminated prematurely and with damage.
The situation for server and workstation differs.
On the one hand: In the case of workstations, your own data may no longer be usable. With a server, it is usually the data of third parties. The responsibility is much heavier.
On the other hand, a server under heavy load reacts far more unpredictably than a workstation. The distinction between case 2 and 3 above is much more difficult. Collin Walter (CoreOS) points this out with much more detailed technical knowledge than I do (https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...) .
However, the motto must be: If in doubt, wait a bit longer to see if the system shuts down safely, rather than forcing an end prematurely and risking damage.
Accordingly, CoreOS has (responsibly in my view) decided to retain the previous timeout value and override the change.
Proposal: Server should do the same.
1 year, 1 month
List of our core services
by Peter Boy
As of our IRC meeting 2023-02-15 we want to create a list of our core services in order to check their proper shutdown value status.
I determined the following list:
• KVM/Libvirt VM's host
• KVM/libvirt VM instances
• Podman container host
• Podman container instances
• Systemd-nspawn container host
• Systemd-nspawn container instances
• Libvirt LXC container host
• Libvirt LXC container instances
• Domain Controller
• IPA service
• PostgreSQL database server
• Samba file server
• NFS file server
• Apache Web server
• Web application service: Tomcat
• Web application service: Wildfly
• Postfix/Dovecot mail service
See issue #96
https://pagure.io/fedora-server/issue/96#comment-841351
Please comment here or comment / edit the issue.
1 year, 1 month
Federa 35 Server default editor
by Peter Boy
In Fedora 34 the default editor was nano, for Workstation and also for Server. In my latest default F35 Server installation I noticed vim-default-editor was installed.
Did some good soul take pity and bring vim back to us or did something go wrong with my installation?
Best
Peter
1 year, 1 month
Ansible/Wildfly on Fedora
by John W. Himpel
Good morning,
Peter has kindly created am VM at sisyphos.redigita.eu running Fedora
Linux 37 (Server Edition).
Using the gitlab repository at:
https://gitlab.com/jwhimpel/ansible-wildfly
I am able to run the ansible script wildfly_service_test.sh to a
successful completion.
However when I attempt to startup Wildfly, I get an error. See
/opt/wildfly/wf27/standalone/log/server.log for details. The
configuration file is at:
/opt/wildfly/wf27/standalone/configuration/standalone.xml.
The version of java installed in the VM is java-1.17.0-openjdk-
headless.
The version of Wildfly that I am trying to run is 27.0.1-Final.
On my local host, I am able to get Wildfly 26.0.1.Final to install and
run fine. So I suspect there is a configuration change between v26 and
v27.
Unfortunately, I will be away from my computer for the next 4 or 5
days.
If you are willing to help in this effort to ansibleize (sp?) Wildfly,
I am sure if you contact Peter at <pboy(a)uni-bremen.de>, he would be
glad to give you access to this VM.
If you discover the cause of the issue, please feel free to submit a PR
to gitlab.
JOhn
1 year, 1 month
jwhimpel/ansible_wildfly repo at github updated
by John W. Himpel
All,
As stated in today's Server WG meeting, I updated the
jwhimpel/ansible_wildfly repo at gitlab.
Most of the changes were better documenting in README.md
1) The variables in defaults/main.yml that need modification
2) The variables in vars/main.yml that need modification
3) Document the requirement for the installation of java (headless)
4) Document which shell script to run to perform the installation
Rework the contents of the inventories directory:
1) Remove the files in and under group_vars as they are not needed
for this test
2) Remove the encoded vault.yml files as clear-text values for the
variables in those files are now in vars.yml
I was able to install this in my home datacenter. The only changes
made before the commit were to sanitize the userids and passwords in
defaults/main.yml and vars/main.yml.
While not documented anywhere, the tests in the "test" directory are
NOT run.
If you have questions or issues, please post on the server mailing
list.
John
1 year, 1 month