Hi folks,
Now through November 29th, you may nominate candidates for the open seats
on the Fedora Engineering Steering Committee (FESCo).
To nominate yourself or others, visit
https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
If you are nominating someone else, make sure you get their approval :)
For more information, see the Community Blog post
https://communityblog.fedoraproject.org/f39-elections-now-open/
Kindest regards,
Aoife
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Hi folks,
Now through November 29th, you may nominate candidates for the open seats
on the Fedora Mindshare Committee.
To nominate yourself or others, visit
https://fedoraproject.org/wiki/Mindshare/Nominations
If you are nominating someone else, make sure you get their approval :)
For more information, see the Community Blog post
https://communityblog.fedoraproject.org/f39-elections-now-open/
Kindest regards,
Aoife
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Hi folks,
Now through November 29th, you may nominate candidates for the open seats
on the Fedora Council.
To nominate yourself or others, visit
https://fedoraproject.org/wiki/Council/Nominations
If you are nominating someone else, make sure you get their approval :)
For more information, see the Community Blog post
https://communityblog.fedoraproject.org/f39-elections-now-open/
Kindest regards,
Aoife
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki: https://fedoraproject.org/wiki/Changes/389_Directory_Server_3.0.0
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
389-ds-base upgrade from version 2.4.4 to the latest upstream version
3.0.0 in Fedora.
Newly created instances now are using LDMB database by default instead
of BerkeleyDB.
== Owner ==
* Name: 389 Directory Server Development Team
* Email: 389-devel (at) lists (dot) fedoraproject (dot) org
Primary contact:
* Name: [[User:progier| Pierre Rogier]]
* Email: progier (at) redhat (dot) com
== Detailed Description ==
Since Fedora 36 (389-ds-base 2.1.0), the 389 Directory Server supports
two kinds of underlying database:
* Berkeley Database (BDB)
* Lightning Memory-Mapped Database Manager (LMDB)
Newly created instances are still created with BDB by default while
libdb is flagged as [[Changes/Libdb deprecated - Fedora Project
Wiki|deprecated since Fedora 33]], this change is about to create
instances with LMDB by default.
== Feedback ==
No feedback yet.
== Benefit to Fedora ==
A step on the way to remove a deprecated piece of software no longer
supported by the upstream community.
(See https://fedoraproject.org/wiki/Changes/Libdb_deprecated)
== Scope ==
The change is quite limited in terms of development and interface
impact, but it impacts a critical component: FreeIPA.
[1] Impact on software that uses generic LDAP interface without any
specific 389DS features (like configuration tools and monitoring
entries):
No interface impact, but there may be some impact in terms of dynamic
(i.e: response time, maximum throughput). Especially if browsing (i.e
VLV) indexes are used on big lists.
[2] Impact on software that explicitly creates 389DS instances (like
FreeIPA) may also have to change the way the database is tuned.
(Especially the database maximum size: `nsslapd-mdb-max-size`)
[3] Impact on software that explicitly uses backend monitoring LDAP
entries: new attributes about LMDB specific data are present.
There are no packages in [3] case and FreeIPA is the only one in [2]
case but there is likely an unknown number of software in [1] case
that use the LDAP interface without needing a specific LDAP server.
So, in summary, the main risk is to see some regression in tests.
* Proposal owners:
Development impact:
- Change of a default value of one parameter of the instance creation
utility (`dscreate`)
- Provide a better visibility of that parameter in configuration tools
(`dscreate` and `dsconf`)
The above changes have already been done to be able to build the test
packages, so the remaining work is to merge the commit in the upstream
branch and rebase it to rawhide.
The larger impact is to determine if there are any regressions while
running 389DS and FreeIPA tests and fix them (with the help of the
FreeIPA team).
* Other developers:
The FreeIPA team is involved to help us diagnose any potential FreeIPA
test regressions.
Other QA teams may also be involved to test that there are no regressions.
* Release engineering: N/A (not needed for this Change): No strong
coordination is needed as only a single group of package is directly
impacted.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
No impact on upgrade because existing instances still use the
previously installed backend interface.
There should not be any compatibility issues (bugs excepted) with the
LDAP requests, but performance may be impacted.
There may be issues with applications that explicitly:
* Configure 389 Directory Server instances (like FreeIPA) because the
set of configuration attributes for the backend depends on the
underlying database implementation.
The unused parameters are ignored, so it should not impact the compatibility.
But there is a risk with the new parameters: the "20 GB" default value
for the LMDB database maximum size may not be large enough for the
application's needs.
* Monitor 389 Directory Server backends because the set of attributes
in the monitoring entries also depends on the underlying database
implementation.
More details about these points are described in
[https://www.port389.org/docs/389ds/FAQ/Berkeley-DB-deprecation.html
389 Directory Server FAQ - BerkeleyDB backend deprecation]
== How To Test ==
[https://copr.fedorainfracloud.org/coprs/g/389ds/389-ds-base-freeipa-tests/
COPR project] contains builds that can be tested (F37, F38, F39,
rawhide on x86_64 and s390x).
So you can install them by using:
<pre>
sudo dnf copr enable -y @389ds/389-ds-base-freeipa-tests
sudo dnf install 389-ds-base-3.0.0
</pre>
Then you can create new directory server instances and use them.
== User Experience ==
Prepare for the removal of an obsolete piece of software that is no
longer supported by the upstream community. This process aims to
provide more visibility to its replacement.
== Dependencies ==
All the dependent packages are owned by 389DS and FreeIPA teams:
`dnf repoquery --whatrequires 389-ds-base --recursive`
{| class="wikitable"
|+
|-
! Package !! Owner !! Tests
|-
| 389-ds-base-snmp || 389DS || Tested by 389DS CI test
|-
| cockpit-389-ds || 389DS || Tested by 389DS CI test
|-
| freeipa-fas || FreeIPA || Tested by FreeIPA CI test
|-
| freeipa-healthcheck || FreeIPA || Tested by FreeIPA CI test
|-
| freeipa-server || FreeIPA || Tested by FreeIPA CI test
|-
| freeipa-server-dns || FreeIPA || Tested by FreeIPA CI test
|-
| freeipa-server-trust-ad || FreeIPA || Tested by FreeIPA CI test
|-
| migrationtools || 389DS || Not impacted by the change
|-
| slapi-nis || FreeIPA || Tested by FreeIPA CI test
|}
== Contingency Plan ==
* Contingency mechanism:
* Revert the default backend implementation to Berkeley Database
* If libdb-5.3 or libdb-devel is no longer shipped in Fedora:
The plan is to build libdb static library as part of 389-ds-base build
process and link libback-ldbm statically with it
(as described in
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_statically_link…)
The risk is that we may have to generate patches in case of CVE that
impacts 389-ds or in case of build environment changes until we can
remove the support of the bdb backend. libdb-5.3.28-55.fc38.src shows
that the risk is quite limited (1 cve and one set of patches related
to c99 since 2017).
* Contingency deadline: Fedora 40 beta freeze (2024-02-20)
* Blocks release? No
== Documentation ==
[https://www.port389.org/docs/389ds/FAQ/Berkeley-DB-deprecation.html
Directory Server FAQ - BerkeleyDB backend deprecation]
== Release Notes ==
Need to write release notes for 3.0.0 in
https://www.port389.org/docs/389ds/releases/release-notes.html as
usual for 389DS.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
https://fedoraproject.org/wiki/Changes/SystemdSecurityHardening
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Improve security by enabling some of the high level systemd security
hardening settings that isolate and sandbox default system services.
== Owner ==
* Name: [[User:Sundaram| Rahul Sundaram]]
* Email: metherid(a)gmail.com
== Detailed Description ==
systemd provides a number of settings that can harden security for
services. We are selecting a few high level ones to enable by default
on a service by service basis as suitable for that particular service.
* `PrivateTmp=yes`
* `ProtectSystem=yes/full/strict`
* `ProtectHome=yes/read-only`
* `ProtectClock=yes`
* `ProtectHostname=yes`
* `ProtectControlGroups=yes`
* `ProtectHostname=yes`
* `ProtectKernelLogs=yes`
* `ProtectKernelModules=yes`
* `ProtectKernelTunables=yes`
* `ProtectProc=invisible`
* `PrivateDevices=yes`
* `PrivateNetwork=yes`
* `NoNewPrivileges=yes`
* `User=`
If we want to go further, we could also consider:
* `CapabilityBoundingSet=`
* `DevicePolicy=closed`
* `KeyringMode=private`
* `LockPersonality=yes`
* `MemoryDenyWriteExecute=yes`
* `PrivateUsers=yes`
* `RemoveIPC=yes`
* `RestrictAddressFamilies=`
* `RestrictNamespaces=yes`
* `RestrictRealtime=yes`
* `RestrictSUIDSGID=yes`
* `SystemCallFilter=`
* `SystemCallArchitectures=native`
We will aim to cover all the default system services as well as some
of the high profile services such as Nginx or PostgreSQL. All of these
settings need to be configured on a per service basis instead of using
a global override to facilitate fine tuning the settings based on
service requirements and limit the impact for users on upgrades.
Certain services have a very targeted scope. For instance, a service
that only needs to read or write from only one directory could
leverage more fine grained settings to restrict access even further.
We will enable as many of these as feasible for the services but not
every knob is going to be applicable to every service. For example,
`PrivateNetwork=yes` can only be used for services that does not need
network connectivity by default. We have to choose between
`DynamicUser=yes` or `User` if either is feasible for the service to
use. As a base starting point, from Fedora 39 workstation, we have the
following system services installed by default which should considered
within the scope of the change (excluding systemd associated ones
which already have a number of these security settings enabled). We
may also consider doing this for some of the high profile services
including say Nginx and PostgreSQL permitting time considerations and
other contributors if any joining this effort. We will prioritize
critical or long running services.
* `abrtd.service`
* `abrt-journal-core.service`
* `abrt-oops.service`
* `abrt-pstoreoops.service`
* `abrt-vmcore.service`
* `abrt-xorg.service`
* `accounts-daemon.service`
* `alsa-restore.service`
* `alsa-state.service`
* `anaconda-direct.service`
* `anaconda-fips.service`
* `anaconda-nm-config.service`
* `anaconda-nm-disable-autocons.service`
* `anaconda-noshell.service`
* `anaconda-pre.service`
* `anaconda.service`
* `anaconda-sshd.service`
* `arp-ethers.service`
* `auditd.service`
* `auth-rpcgss-module.service`
* `avahi-daemon.service`
* `blivet.service`
* `blk-availability.service`
* `bluetooth.service`
* `bolt.service`
* `brltty.service`
* `canberra-system-bootup.service`
* `canberra-system-shutdown-reboot.service`
* `canberra-system-shutdown.service`
* `chronyd-restricted.service`
* `chronyd.service`
* `chrony-wait.service`
* `colord.service`
* `console-getty.service`
* `cups-browsed.service`
* `cups.service`
* `dbus-broker.service`
* `dbus-daemon.service`
* `dbus-org.freedesktop.hostname1.service`
* `dbus-org.freedesktop.import1.service`
* `dbus-org.freedesktop.locale1.service`
* `dbus-org.freedesktop.login1.service`
* `dbus-org.freedesktop.machine1.service`
* `dbus-org.freedesktop.portable1.service`
* `dbus-org.freedesktop.timedate1.service`
* <strike>`debug-shell.service`</strike> (opens a user shell that must
be able to do arbitrary stuff)
* `dm-event.service`
* `dnf-makecache.service`
* `dnf-system-upgrade-cleanup.service`
* `dnf-system-upgrade.service`
* `dnsmasq.service`
* `dracut-cmdline.service`
* `dracut-initqueue.service`
* `dracut-mount.service`
* `dracut-pre-mount.service`
* `dracut-pre-pivot.service`
* `dracut-pre-trigger.service`
* `dracut-pre-udev.service`
* `dracut-shutdown-onfailure.service`
* `dracut-shutdown.service`
* <strike>`emergency.service`</strike> (opens a user shell that must
be able to do arbitrary stuff)
* `fedora-third-party-refresh.service`
* `firewalld.service`
* `flatpak-add-fedora-repos.service`
* `flatpak-system-helper.service`
* `fprintd.service`
* `fsidd.service`
* `fstrim.service`
* `fwupd-offline-update.service`
* `fwupd-refresh.service`
* `fwupd.service`
* `gdm.service`
* `geoclue.service`
* `grub-boot-indeterminate.service`
* `gssproxy.service`
* `htcacheclean.service`
* `httpd.service`
* `hypervfcopyd.service`
* `hypervkvpd.service`
* `hypervvssd.service`
* `iio-sensor-proxy.service`
* `import-state.service`
* `initrd-cleanup.service`
* `initrd-parse-etc.service`
* `initrd-switch-root.service`
* `initrd-udevadm-cleanup-db.service`
* `instperf.service`
* `ipp-usb.service`
* `iscsid.service`
* `iscsi-init.service`
* `iscsi-onboot.service`
* `iscsi.service`
* `iscsi-shutdown.service`
* `iscsi-starter.service`
* `iscsiuio.service`
* `kdump.service`
* `kmod-static-nodes.service`
* `ldconfig.service`
* `libvirtd.service`
* `libvirt-guests.service`
* `livesys-late.service`
* `livesys.service`
* `loadmodules.service`
* `logrotate.service`
* `low-memory-monitor.service`
* `lvm2-lvmdbusd.service`
* `lvm2-lvmpolld.service`
* `lvm2-monitor.service`
* `man-db-cache-update.service`
* `man-db-restart-cache-update.service`
* `mcelog.service`
* `mdcheck_continue.service`
* `mdcheck_start.service`
* `mdmonitor-oneshot.service`
* `mdmonitor.service`
* `ModemManager.service`
* `ndctl-monitor.service`
* `netavark-dhcp-proxy.service`
* `NetworkManager-dispatcher.service`
* `NetworkManager.service`
* `NetworkManager-wait-online.service`
* `nfs-blkmap.service`
* `nfsdcld.service`
* `nfs-idmapd.service`
* `nfs-mountd.service`
* `nfs-server.service`
* `nfs-utils.service`
* `nftables.service`
* `nis-domainname.service`
* `nm-priv-helper.service`
* `numad.service`
* `nvmefc-boot-connections.service`
* `nvmf-autoconnect.service`
* `ostree-boot-complete.service`
* `ostree-finalize-staged-hold.service`
* `ostree-finalize-staged.service`
* `ostree-prepare-root.service`
* `ostree-remount.service`
* `packagekit-offline-update.service`
* `packagekit.service`
* `pam_namespace.service`
* `pcscd.service`
* `plocate-updatedb.service`
* `plymouth-halt.service`
* `plymouth-kexec.service`
* `plymouth-poweroff.service`
* `plymouth-quit.service`
* `plymouth-quit-wait.service`
* `plymouth-read-write.service`
* `plymouth-reboot.service`
* `plymouth-start.service`
* `plymouth-switch-root-initramfs.service`
* `plymouth-switch-root.service`
* `podman-auto-update.service`
* `podman-clean-transient.service`
* `podman-restart.service`
* `podman.service`
* `polkit.service`
* `power-profiles-daemon.service`
* `psacct.service`
* `qemu-guest-agent.service`
* `qemu-pr-helper.service`
* `quotaon.service`
* `raid-check.service`
* <strike>`rc-local.service`</strike> (this can do arbitrary stuff)
* `realmd.service`
* `rescue.service`
* `rpcbind.service`
* `rpc-gssd.service`
* `rpc-statd-notify.service`
* `rpc-statd.service`
* `rpmdb-migrate.service`
* `rpmdb-rebuild.service`
* `rtkit-daemon.service`
* `saslauthd.service`
* `selinux-autorelabel-mark.service`
* `selinux-autorelabel.service`
* `selinux-check-proper-disable.service`
* `speech-dispatcherd.service`
* `spice-vdagentd.service`
* `spice-webdavd.service`
* `sshd.service`
* `ssh-host-keys-migration.service`
* `sssd-autofs.service`
* `sssd-kcm.service`
* `sssd-nss.service`
* `sssd-pac.service`
* `sssd-pam.service`
* `sssd.service`
* `sssd-ssh.service`
* `sssd-sudo.service`
* `switcheroo-control.service`
* `system-update-cleanup.service`
* `tcsd.service`
* `thermald.service`
* `udisks2.service`
* `unbound-anchor.service`
* `upower.service`
* `uresourced.service`
* `usbmuxd.service`
* `vboxclient.service`
* `vboxservice.service`
* `vgauthd.service`
* `virtinterfaced.service`
* `virtlockd.service`
* `virtlogd.service`
* `virtnetworkd.service`
* `virtnodedevd.service`
* `virtnwfilterd.service`
* `virtproxyd.service`
* `virtqemud.service`
* `virtsecretd.service`
* `virtstoraged.service`
* `vmtoolsd.service`
* `wpa_supplicant.service`
* `zfs-fuse-scrub.service`
* `zfs-fuse.service`
* `zvbid.service`
We will also coordinate with upstream following
https://docs.fedoraproject.org/en-US/packaging-guidelines/PatchUpstreamStat…
and encourage package maintainers to upstream these changes. Systemd
will ignore any of these settings it does not understand on older
versions. Hence this should be safe for upstream to merge on any
services.
== Feedback ==
== Benefit to Fedora ==
Fedora services will get a significant security boost by default by
avoiding or mitigating any unknown security vulnerabilities in default
system services.
== Scope ==
* Proposal owners: Individual per service pull requests to enable
various security features as applicable.
* Other developers: Review PRs as needed
* Release engineering: https://pagure.io/releng/issue/11785
* Policies and guidelines:
Packaging guidelines will have to be modified to add recommendations
to use more of the systemd security features by default. In
particular, we should add a security settings section in
https://fedoraproject.org/wiki/Packaging:Systemd. Current the
guidance only recommends a couple of settings for long running
services. Sample text:
Systemd services included in Fedora are recommended to use as many of
the following security settings as applicable while maintaining the
default functionality of the service.
* `PrivateTmp=yes`
* `ProtectSystem=yes/full/strict`
* `ProtectHome=yes`
* `PrivateDevices=yes`
* `ProtectKernelTunables=yes`
* `ProtectKernelModules=yes`
* `ProtectKernelLogs=yes`
* `ProtectControlGroups=yes`
* `NoNewPrivileges=yes`
* `PrivateNetwork=yes`
The full list of sandboxing features are available in
https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#S….
Note that if you are submitting changes to upstream as recommended,
systemd will warn and ignore any of these features it doesn't support.
So it should be safe for upstream to enable as many of these features
as applicable and not worry about distribution support for ones using
older versions of systemd.
* Trademark approval: N/A
== Upgrade/compatibility impact ==
Packages will automatically get additional security features enabled
by default transparently. In limited circumstances, they may need to
override the defaults. Refer to user experience section for details.
== How To Test ==
You can use tools like `systemd-analyze security` and `systemctl cat`
to verify that specific security features are enabled by default.
Default services with the default features should have no adverse
impact and users shouldn't have to do anything beyond using the
software as intended and report any regressions. High profile
services not installed by default that gain these security features
would benefit from more targeting testing to spot any unintended
consequences especially for niche or advanced functionality. If
advanced non-default functionality requires overrides default
settings, we can document those in the release notes to provide
guidance.
== User Experience ==
This should be largely transparent change for users. The goal is to
have the services work as expected with the default functionality but
to potentially require tweaking the settings if the configuration is
changed by users after installation. For instance, if we add
`ProtectHome=yes` to Apache httpd.service and the user wishes to serve
files out of their home directory, they will need to override the
systemd setting to `ProtectHome=read-only` to allow for the service to
read from the user home directory in addition to changing the service
specific configuration files to enable this feature.
== Dependencies ==
None. We are merely enabling some of systemd security features by
default for default system services and potentially some high profile
services.
== Contingency Plan ==
* Contingency mechanism: These settings can be enabled/disabled at a
per service level. No wholesale reverts is necessary. If we don't
finish the work for all the services, we can follow up in future
releases.
* Contingency deadline: N/A
* Blocks release? No
== Documentation ==
* https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#S…
* https://docs.arbitrary.ch/security/systemd.html
* https://www.redhat.com/sysadmin/systemd-secure-services
* https://www.redhat.com/sysadmin/mastering-systemd
== Release Notes ==
systemd security hardening features are enabled for default system
services and following high profile services.
* PostgreSQL
* Apache Httpd
* Nginx
* MariaDB
....
If you wish to turn off any particular settings, you can follow the
standard systemd method of overriding the config. For example,
`$ cat /etc/systemd/system/httpd.service.d/override.conf
[Service]
ProtectHome=no`
`
$ sudo systemctl daemon-reload
$ sudo systemctl restart httpd.service`
`$ systemctl status httpd.service
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled;
vendor preset: disabled)
Drop-In: /etc/systemd/system/httpd.service.d
└─override.conf
Active: active (running) since Mon 2023-11-15 18:29:25 EST; 3min 30s ago`
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
https://fedoraproject.org/wiki/Changes/Wget2asWget
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Replace wget with wget2 (a modern implementation of wget intended to
replace wget 1.x) as the provider of wget.
== Owner ==
* Name: [[User:Ngompa| Neal Gompa]], [[User:Mruprich| Michal Ruprich]]
* Email: ngompa13(a)gmail.com, mruprich(a)redhat.com
== Detailed Description ==
GNU Wget2 is the successor to GNU Wget providing a modern
implementation of <code>wget</code> backed by a new library: libwget2.
The intent to switch from wget 1.x to wget2 is to switch to an
implementation that is more actively developed and provides a richer
interface for leveraging wget's functionality.
== Feedback ==
== Benefit to Fedora ==
The major benefit of switching to wget2 is leveraging the cleaner
codebase that leverages modern practices for development and
maintainability, including unit tests and fuzzing as a
security-sensitive component. Users will also see better support for
newer protocols over time as they are more easily and quickly plumbed
into wget2 than wget.
== Scope ==
* Proposal owners: Add a <code>wget2-wget</code> subpackage that
replaces {{package|wget}} and ensure things don't break during mass
build. Then retire {{package|wget}}.
* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issue/11790 #11790]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
When upgrading to Fedora Linux 40, systems with {{package|wget}}
installed will be switched to {{package|wget2}} via the
<code>wget2-wget</code> package. The change should be mostly
transparent to users.
== How To Test ==
Users can test {{package|wget2}} now by installing the package and
using the <code>wget2</code> command. The interface will be the
interface users have with <code>wget</code> on upgrade.
== User Experience ==
This change should be largely transparent to users. Some of the more
esoteric options and behaviors may have changed, but the commonly used
ones mostly work as they did in 1.x.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: Change owners will disable
<code>wget2-wget</code> subpackage and restore {{package|wget}}
* Contingency deadline: Final Freeze
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
The <code>wget</code> command is now based on GNU Wget2, a modern
implementation of GNU Wget.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Planned Outage - pagure.io network switch updates - 2023-11-17 13:00 UTC
There will be an outage starting at 2023-11-17 13:00UTC,
which will last approximately 4 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2023-11-17 13:00UTC'
Reason for outage:
Network switches in the datacenter that hosts pagure.io will be
updated and rebooted. This should result in a small (~20m) break
in connectivity sometime in the outage window.
Affected Services:
pagure.io
Ticket Link:
https://pagure.io/fedora-infrastructure/issue/11626
Please join #fedora-admin or #fedora-noc on irc.libera.chat
or #admin:fedoraproject.org / #noc:fedoraproject.org on matrix.
Please add comments to the ticket for this outage above.
Updated status for this outage may be available at
https://www.fedorastatus.org/