F38 servers will auto-suspend if GNOME is installed
by Kamil Paral
GNOME developers enabled auto-suspend by default, even when on AC power,
after 15 minutes of inactivity. I just tested that this will also affect
Fedora Server, if you install GNOME packages manually, and boot into the
graphical.target. I don't know how rare or common this scenario is, but I
want to highlight this change. If Server WG thinks this is a problematic
change for the Fedora Server user base, please start making noise about it
now, because we're only 1 month from F38 Final release :-)
Cheers,
Kamil
Fedora QA
1 day, 23 hours
F38 dnf modules isn't going to be functional
by Sumantro Mukherjee
DNF5 test day is running and we have figured that dnf modules command
is being worked on.
The functionality can be tracked [0] and this is targeted to be complete in F39.
If users, have modules enabled in F37 and upgrade to F38, things will be fine.
However, fresh installs or installations which wanna play with modules
in F38 won't be
able to do that.
DNF team suggests a workaround how to modify modules without using any
tool - modify files in /etc/dnf/modules.d. if you want to reset nodejs
module you can use rm /etc/dnf/modules.d/nodejs
If this is a problematic thing, we should communicate this to the users.
[0] https://github.com/rpm-software-management/dnf5/issues/146
--
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
6 days, 20 hours
Re: F38 dnf modules isn't going to be functional
by Peter Robinson
On Wed, Mar 15, 2023 at 2:20 PM Frantisek Zatloukal <fzatlouk(a)redhat.com>
wrote:
> But that's microdnf, not the current default dnf. I don't think microdnf
> was used by default in any of our blocking spins/images.
>
We ship microdnf in the arm minimal image due to issues with dnf and memory
usage[1] and it's used quite widely on devices like the Raspberry Pi
Zero2W. The Minimal image is blocking.
https://bugzilla.redhat.com/show_bug.cgi?id=1907030
> On Wed, Mar 15, 2023 at 1:44 PM Sumantro Mukherjee <sumukher(a)redhat.com>
> wrote:
>
>>
>>
>> On Wed, Mar 15, 2023 at 2:09 PM Frantisek Zatloukal <fzatlouk(a)redhat.com>
>> wrote:
>>
>>> But the dnf > dnf5 switch will happen in F39, not F38, so that shouldn't
>>> be an issue that it's not supported in DNF 5, no?
>>>
>>
>> I checked and it says F38 as target release
>> https://fedoraproject.org/wiki/Changes/MajorUpgradeOfMicrodnf
>>
>>
>>>
>>> On Wed, Mar 15, 2023 at 8:32 AM Sumantro Mukherjee <sumukher(a)redhat.com>
>>> wrote:
>>>
>>>> DNF5 test day is running and we have figured that dnf modules command
>>>> is being worked on.
>>>> The functionality can be tracked [0] and this is targeted to be
>>>> complete in F39.
>>>> If users, have modules enabled in F37 and upgrade to F38, things will
>>>> be fine.
>>>> However, fresh installs or installations which wanna play with modules
>>>> in F38 won't be
>>>> able to do that.
>>>>
>>>> DNF team suggests a workaround how to modify modules without using any
>>>> tool - modify files in /etc/dnf/modules.d. if you want to reset nodejs
>>>> module you can use rm /etc/dnf/modules.d/nodejs
>>>>
>>>> If this is a problematic thing, we should communicate this to the users.
>>>>
>>>> [0] https://github.com/rpm-software-management/dnf5/issues/146
>>>>
>>>> --
>>>> //sumantro
>>>> Fedora QE
>>>> TRIED AND PERSONALLY TESTED, ERGO TRUSTED
>>>> _______________________________________________
>>>> test mailing list -- test(a)lists.fedoraproject.org
>>>> To unsubscribe send an email to test-leave(a)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/test@lists.fedoraproject.org
>>>> Do not reply to spam, report it:
>>>> https://pagure.io/fedora-infrastructure/new_issue
>>>>
>>>
>>>
>>> --
>>>
>>> Best regards / S pozdravem,
>>>
>>> František Zatloukal
>>> Senior Quality Engineer
>>> Red Hat
>>> _______________________________________________
>>> test mailing list -- test(a)lists.fedoraproject.org
>>> To unsubscribe send an email to test-leave(a)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/test@lists.fedoraproject.org
>>> Do not reply to spam, report it:
>>> https://pagure.io/fedora-infrastructure/new_issue
>>>
>>
>>
>> --
>> //sumantro
>> Fedora QE
>> TRIED AND PERSONALLY TESTED, ERGO TRUSTED <https://redhat.com/trusted>
>> _______________________________________________
>> test mailing list -- test(a)lists.fedoraproject.org
>> To unsubscribe send an email to test-leave(a)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/test@lists.fedoraproject.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>>
>
>
> --
>
> Best regards / S pozdravem,
>
> František Zatloukal
> Senior Quality Engineer
> Red Hat
> _______________________________________________
> test mailing list -- test(a)lists.fedoraproject.org
> To unsubscribe send an email to test-leave(a)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/test@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
6 days, 22 hours
Re: F38 dnf modules isn't going to be functional
by Lukas Ruzicka
On Wed, Mar 15, 2023 at 3:20 PM Frantisek Zatloukal <fzatlouk(a)redhat.com>
wrote:
> But that's microdnf, not the current default dnf. I don't think microdnf
> was used by default in any of our blocking spins/images.
>
Totally correct. Thanks for the clarification.
1 week
Our most important features for the new web page
by Peter Boy
The current draft:
https://fedora.gitlab.io/websites-apps/fedora-websites/fedora-websites-3....
Discussion about development
https://discussion.fedoraproject.org/t/fedora-server-front-page-revamp-lo...
We have to check and discuss
* The graphical representations
* The wording of the mission statements
* specific properties in the Fedora universe
* specific properties in relation to other distributions
> - - - - - - - - - - - <
According for various discussions and our PRD (Product Requirement Document) our central intentions are:
(a)
=Flexibility= and =customizable=, can be =tailored to the specific needs= of the local admin / customer / owner
(Universalitiy and Flexibility are the main difference to CoreOS and IoT)
"provides a ... flexible, and universally-adaptable base for the everyday provisioning of services and applications by organizations and individuals,
"Deploy the services you need under your own control, and customized to your own requirements"
"A great variety of available software, ... opens up a wide range of possibilities for flexibility in building a server according to the specific needs and wishes of a customer or end-user.
A platform for deploying containerized applications supporting multiple container technologies, among which **the system administrator can choose according to custom requirements**.
(b)
==Stable but nevertheless latest technology==
"Fedora Server provides a stable ... based on the latest technology and is available quickly after the upstream releases.
"Fedora Server provides a stable foundation, with balanced resource utilization, yet delivering the latest technologies giving administrators every day exposure to the latest tooling as soon as it is usable"
(c)
A platform for important infrastructure tasks and basic services (DNS, DHCP, FreeIPA, and others)
A platform for various important, dedicated server applications (file/storage server, database server, user-developed web applications, etc.)
(d)
=Security=
"enterprise-grade security, resulting in carefully pre-configured releases, offering uncompromising security without extensive configuration work by system administrators.
Security-minded: secure by design - extending into TPM support, disk encryption enablement
(e)
Admin friendly
easy update and upgrade to next release without re-installation
(f)
For developers:
" implementation of the latest server technology for exploring and evaluating."
" Developers find an excellent development environment for the next generation server as well as application software with the latest software versions available. "
1 week
Re: F38 dnf modules isn't going to be functional
by Sumantro Mukherjee
On Wed, Mar 15, 2023 at 2:09 PM Frantisek Zatloukal <fzatlouk(a)redhat.com>
wrote:
> But the dnf > dnf5 switch will happen in F39, not F38, so that shouldn't
> be an issue that it's not supported in DNF 5, no?
>
I checked and it says F38 as target release
https://fedoraproject.org/wiki/Changes/MajorUpgradeOfMicrodnf
>
> On Wed, Mar 15, 2023 at 8:32 AM Sumantro Mukherjee <sumukher(a)redhat.com>
> wrote:
>
>> DNF5 test day is running and we have figured that dnf modules command
>> is being worked on.
>> The functionality can be tracked [0] and this is targeted to be complete
>> in F39.
>> If users, have modules enabled in F37 and upgrade to F38, things will be
>> fine.
>> However, fresh installs or installations which wanna play with modules
>> in F38 won't be
>> able to do that.
>>
>> DNF team suggests a workaround how to modify modules without using any
>> tool - modify files in /etc/dnf/modules.d. if you want to reset nodejs
>> module you can use rm /etc/dnf/modules.d/nodejs
>>
>> If this is a problematic thing, we should communicate this to the users.
>>
>> [0] https://github.com/rpm-software-management/dnf5/issues/146
>>
>> --
>> //sumantro
>> Fedora QE
>> TRIED AND PERSONALLY TESTED, ERGO TRUSTED
>> _______________________________________________
>> test mailing list -- test(a)lists.fedoraproject.org
>> To unsubscribe send an email to test-leave(a)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/test@lists.fedoraproject.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>>
>
>
> --
>
> Best regards / S pozdravem,
>
> František Zatloukal
> Senior Quality Engineer
> Red Hat
> _______________________________________________
> test mailing list -- test(a)lists.fedoraproject.org
> To unsubscribe send an email to test-leave(a)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/test@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED <https://redhat.com/trusted>
1 week
Wildfy - Install and Configure Wildfly
by John W. Himpel
Good news! I have an ansible role that installs a standalone version of
Wildfly 27 (latest release of Wildfly).
I also was able to follow the instructions found at:
https://developer.jboss.org/people/fjuma/blog/2018/08/31/obtaining-certif...
for adding ssl to Wildfly. I followed the steps for add SSL manually.
I have not yet found the time to "ansify" those steps, but that
shouldn't be too much of a problem. That will be my next effort.
After that, I plan to configure apache as a reverse proxy as a frontend
for Wildfly.
Thanks to Peter for creating the VM for testing/correcting my ansible
role. I hope he can keep the VM operational for now as it is an
invaluable test-bed.
I have taken on the task of doing the IT work for a new fledgling non-
profit corporation that I have formed to provide home/yard services to
those persons in our area who are unable to perform or hire those
services themselves. That means my time may be limited for working on
this effort until late in April 2023.
John Himpel
1 week
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 week, 1 day
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 week, 1 day
