This seems to repeat every 6 months: rawhide mock is broken on stable
Fedora, people are scrambling to install the right gpg keys, dnf reports
unsigned packages.
Looking at https://bodhi.fedoraproject.org/updates/?packages=fedora-repos,
there is still no F30 package with the right keys.
Can we *please* send out the FN+1 and FN+2 keys a month before branching,
to *all* releases of Fedora, so we can avoid this pointless scramble?
Zbyszek
Too many people (like also me) try to use samba-dc on fedora for deploy
a production AD DC controller, without know that MIT kerberos is
experimental and some useful things cannot work (es. win to win
access).
An recent last example:
https://lists.samba.org/archive/samba/2019-November/226845.html
> On 01/11/2019 22:23, Vex Mage wrote:
> > The script is expecting dpkg however this is a Red Hat
> > derived distro (Fedora Server.)
>
> Where did you get the Samba packages from ?
>
> If they are the default OS packages, then you should stop using
> them, they use MIT kerberos and are experimental.
There is many approach for resolve this issue:
a) Stop use MIT kerberos and rebuild samba with Heimdal Kerberos.
b) Produce a samba alternative package version (like, for example,
firefox-x11) build it with Heimdal Kerberos (es samba-hk-*)
c) Stop enable DC on Fedora, like RH/Centos do.
d) Notify users at the end of the installation that Fedora Samba DC is
experimental.
e) Solve the problems that make MIT kerberos experimental and put us in
a position to ask for help on the samba team.
f) ... some other proposal ?
What is the best approach chosen by Fedora ?
Many thanks
--
Dario Lesca
(inviato dal mio Linux Fedora 31 Workstation)
Il giorno gio 24 ott 2019 alle ore 19:28 Strahil <hunter86_bg(a)yahoo.com> ha
scritto:
> Hi Sandro,All,
>
> Can I upgrade the tools on existing VM , or it requires a fresh one? Best
> Regards
>
If you have oVirt windows guest tools already installed suggestion is to
uninstall it before installing this new installer.
> Best Regards,
> Strahil Nikolov
> On Oct 24, 2019 14:35, Sandro Bonazzola <sbonazzo(a)redhat.com> wrote:
>
> Hi,
> as part of the work on oVirt 4.4, the team rewrote the VirtiIO Windows
> Drivers installer using the open source framework WiX.
> Thanks to the virtio-win maintainer, the new installer is not shipped
> anymore within oVirt Guest Tools ISO: it's shipped now directly into VirtIO
> Windows ISO[1]
>
> Please give it a run on your testing environment / testing VMs and let us
> know about your experience at devel(a)ovirt.org.
> Thanks,
>
>
> [1]
> https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-vi…
>
> --
>
> Sandro Bonazzola
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
>
> Red Hat EMEA <https://www.redhat.com/>
>
> sbonazzo(a)redhat.com
> <https://www.redhat.com/>*Red Hat respects your work life balance.
> Therefore there is no need to answer this email out of your office hours.*
>
>
--
Sandro Bonazzola
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo(a)redhat.com
<https://www.redhat.com/>*Red Hat respects your work life balance.
Therefore there is no need to answer this email out of your office hours.
<https://mojo.redhat.com/docs/DOC-1199578>*
https://fedoraproject.org/wiki/Changes/firewalld_default_to_nftables
== Summary ==
This change will toggle the default firewalld backend from iptables to
nftables. All of firewalld's primitives will use nftables while direct
rules continue to use iptables/ebtables.
== Owner ==
* Name: [[User:erig0| Eric Garver]]
* Email: egarver(a)redhat.com
== Detailed Description ==
Firewalld upstream has used nftables as the default backend for the
past two minor releases. It is also the default in other distributions
(e.g. RHEL-8). This change will bring Fedora in line with upstream.
Using nftables bring many advantages. See firewalld's upstream
[https://firewalld.org/2018/07/nftables-backend blog post]. It also
highlights a few behavioral changes.
== Benefit to Fedora ==
* Fewer firewall rules (rule consolidation)
All of firewalld's primitives will use the same underlying firewall
(nftables) instead of duplicating rules both in iptables and
ip6tables. In nftables rules can match both IPv4 and IPv6 packets.
This reduces the number of firewall rules by half.
* firewalld's rules are namespaced
With nftables firewalld's rules are isolated to a "firewalld" table. A
separate firewall (or user) can create its own independent ruleset and
firewalld will never touch it.
* Netfilter upstream is focusing on nftables, not iptables
== Scope ==
* Proposal owners: firewalld (erig0, Eric Garver)
Currently the firewalld package has a Fedora downstream patch to hide
the nftables backend. The only firewalld change required is to remove
that patch from the package and rebuild.
* Other developers: libvirt, podman, docker
** libvirt
*** libvirt already cooperates with the firewalld nftables backend.
The only thing needed is to test/verify.
** podman
*** libvirt already cooperates with the firewalld nftables backend.
The only thing needed is to test/verify.
** docker
*** Docker currently does not cooperate with the nftables backend. It
currently side-steps firewalld by injecting its own rules in iptables
ahead of firewalld's rules. However, with the nftables backend
firewalld's rule will still be evaluated. Netfilter in the kernel will
call iptables, then nftables for the same packet. This means
firewalld/nftables is likely to drop the packet even if docker has
iptables rules to ACCEPT.
*** Proposed fix 1: Docker package should provide a firewalld zone
definition that includes the docker interfaces (e.g. docker0). The
zone should use the "ACCEPT" policy (firewalld --set-target). This
will allow docker's traffic to pass through firewalld/nftables.
**** Issue 1: If a user has configured a different docker bridge name,
then they'll have to manually add the bridge to the docker zone (or
firewalld's trusted zone).
*** Proposed fix 2: Just like "Proposed fix 1", but instead of adding
the zone definition to docker we created a "docker-firewalld" (or
firewalld-docker?) package that has the zone definition. This could be
installed by default when docker is installed.
* Policies and guidelines: No updated needed.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
When users are upgraded to firewalld with nftables enabled (f32) all
their firewall rules will exist in nftables instead of iptables. All
of firewalld's primitives (zones, services, ports, rich rules, etc.)
are 100% compatible between backends.
Users of direct rules may need to consider the
[https://firewalld.org/2018/07/nftables-backend behavioral changes]
that were announced upstream. Some are also highlighted here:
* direct rules execute before _all_ firewalld rules
** This has been requested by users
* packets dropped in iptables (or direct rules) will never be seen by firewalld
* packets accepted in iptables (or direct rules) are still subject to
firewalld's rules
== How To Test ==
Testing should mostly be integration based. Firewalld upstream has a
fairly comprehensive testsuite that covers functional testing.
The following are packages known to integrate with firewalld. They
should be tested with the nftables backend.
* libvirt
** verify VMs with different network types (bridged, routed) have
working network access
** newer version of libvirt should create and use a "libvirt"
firewalld zone. Interfaces should be dynamically added to the zone.
* podman
** verify podman adds container bridge interface to the "trusted" zone
** verify container still has network access
* docker
** known to not work with the firewalld nftables backend out of the box
** verify new package docker-firewalld installs firewalld docker zone
and has "docker0" interface added
** verify container still has network access
* fail2ban-firewalld
** verify the direct rules added to firewalld by fail2ban still block traffic
== User Experience ==
In general users shouldn't notice the change. Occasional a user will
look at the iptables rule that firewalld generates. They'll now have
to look at nftables instead.
== Dependencies ==
* libvirt >= 5.1.0
* CNI >= 0.8.0 (used by podman)
* docker-firewalld (new package)
== Contingency Plan ==
* Contingency mechanism: firewalld maintainer (erig0) will reinstate
the current patch to default to the iptables backend.
* Contingency deadline: beta freeze
== Documentation ==
* [https://firewalld.org/2018/07/nftables-backend Firewalld blog post]
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Hi,
a new systemd has been sent to rawhide. I don't expect any major
trouble, but please report any issues.
Quoting %changelog:
Biggest items: cgroups v2 cpuset controller, fido_id builtin in udev,
systemd-networkd does not create a default route for link local addressing,
systemd-networkd supports dynamic reconfiguration and a bunch of new settings.
Network files support matching on WLAN SSID and BSSID.
... or in other words: networkctl reload, networkctl renew, networkctl reconfigure wlan0.
I think this is pretty nice functionality for networkd users on the desktop.
This version has support for disabling watchdogs at configuration time
for services bundled with systemd. I want to do that in Fedora, because almost
all "crash" reports that we get are about the watchdog firing on resource
starvation, which is not good, but having the watchdog terminate the process
has very little benefit for the users, and spams bugzilla with useless reports.
I didn't actually disable the watchdogs yet, but I'll plan to do it on Monday
if the version that was built now seems OK.
For full NEWS, see https://github.com/systemd/systemd/blob/master/NEWS#L3.
Zbyszek
https://fedoraproject.org/wiki/Changes/DisallowEmptyPasswordsByDefault
== Summary ==
Remove ''nullok'' parameter from pam_unix module in default PAM
configuration in order to disallow authentication with empty password.
== Owner ==
* Name: [[User:pbrezina| Pavel Březina]]
* Email: <pbrezina(a)redhat.com>
== Detailed Description ==
Current default configuration allows users to login with an empty
password by setting nullok parameter to pam_unix module. This affects
only logins to local machine, it does not affect ssh logins as this
must be explicitly allowed in sshd_config. We want to disallow empty
password by default for local logins as well to improve system
hardening.
Note: It is possible to disallow empty passwords with authselect call
(authselect enable-feature without-nullok) or by removing nullok
manually, however it creates possible issues in other components that
must be addressed.
=== Affected Components ===
* '''passwd''' - calling passwd -d to remove users password must be
denied if empty passwords are disallowed otherwise the user will be
locked out of the system
* '''AccountService''' - D-Bus methods ''SetPassword'' and
''SetPasswordMode'' on ''org.freedesktop.Accounts.User'' interface can
remove user’s password and lock the user out of the system if empty
password is disallowed. These calls must be denied in this case.
Additionally, these methods can be run by normal users as opposed to
''passwd -d'' and ''chage -d 0'' which can be run only by root.
Therefore only root should be able to call these methods.
* '''Gnome’s Control Center''' - when creating new users, it provides
an option to “require password to be set on first login” which creates
user with expired empty password. This would again lock the user out
of the system.
* '''Other Desktop Environments''' - may have the same issue as Gnome
Control Center
=== Solution Step by Step ===
==== Step 1) Provide a unified way to read if nullok is enabled or not ====
We will create an authselect library call that would parse existing
PAM configuration (not necessarily generated by authselect) and return
list of enabled/disabled features. We will implement only ''nullok''
feature in the scope of this change but if needed it can be extended
in the future.
==== Step 2) Fix passwd -d ====
Calling ''passwd -d'' to remove user's password will fail if
''nullok'' is disabled.
==== Step 3) Fix AccountService ====
These methods on ''org.freedesktop.Accounts.User'' D-Bus interface
will be callable only by ''root'' and must return an error if
''nullok'' is disabled.
SetPasswordMode
SetPassword(“”, hint)
==== Step 4) Fix Desktop Environments ====
“Require password change on next login” must keep working. This
feature currently relies on setting an empty password. A new option
''nullresetok'' will be implemented for ''pam_unix'' module that will
allow user to authenticate with empty password only if a password
change for this user is enforced upon login. Authentication with empty
passwords which are not expired will be prohibited (unless ''nullok''
is set).
==== Step 5) Update PAM configuration to disable nullok by default ====
In authselect and pam components for new installations. Upgrading from
older systems will keep nullok present.
== Benefit to Fedora ==
Changes in described components (Step 1 - Step 4) are necessary to
implement in order to make sure that user accounts and tools works
correctly when authentication with empty password is disabled by
system administrator. Changing system default to disallow
authentication with empty passwords (Step 5) improves system
hardening.
== Scope ==
* Proposal owners: Coordinate the work. Make sure all required changes
are implemented.
* Other developers: All affected component must be fixed. Changes are
described in ''Detailed Description''
* Release engineering: [https://pagure.io/releng/issue/9038 #9038] (a
check of an impact with Release Engineering is needed) <!-- REQUIRED
FOR SYSTEM WIDE CHANGES -->
<!-- Does this feature require coordination with release engineering
(e.g. changes to installer image generation or update package
delivery)? Is a mass rebuild required? include a link to the releng
issue.
The issue is required to be filed prior to feature submission, to
ensure that someone is on board to do any process development work and
testing, and that all changes make it into the pipeline; a bullet
point in a change is not sufficient communication -->
* Policies and guidelines: No updates needed.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This does not affect system upgrades because only new installation
will have changed default.
== How To Test ==
* Calling ''passwd -d user'' as root must fail with default configuration.
* Calling ''org.freedesktop.Accounts.User.SetPassword("", hint)'' and
''org.freedesktop.Accounts.User.SetPasswordMode(x)'' must fail with
default configuration.
* "require password reset on first login" must keep working when
creating users from Desktop Environment's GUI tools
== User Experience ==
Users will no longer be able to use empty passwords by default.
== Dependencies ==
None.
== Contingency Plan ==
* Contingency mechanism: Default behavior will not be changed.
* Contingency deadline: Beta
* Blocks release? No
* Blocks product? No
== Documentation ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis