Fedora 34 compose report: 20210228.n.0 changes
by Fedora Rawhide Report
OLD: Fedora-34-20210227.n.0
NEW: Fedora-34-20210228.n.0
===== SUMMARY =====
Added images: 2
Dropped images: 0
Added packages: 0
Dropped packages: 0
Upgraded packages: 0
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages: 0 B
Size of upgraded packages: 0 B
Size of downgraded packages: 0 B
Size change of upgraded packages: 0 B
Size change of downgraded packages: 0 B
===== ADDED IMAGES =====
Image: SoaS raw-xz aarch64
Path: Spins/aarch64/images/Fedora-SoaS-34-20210228.n.0.aarch64.raw.xz
Image: KDE raw-xz aarch64
Path: Spins/aarch64/images/Fedora-KDE-34-20210228.n.0.aarch64.raw.xz
===== DROPPED IMAGES =====
===== ADDED PACKAGES =====
===== DROPPED PACKAGES =====
===== UPGRADED PACKAGES =====
===== DOWNGRADED PACKAGES =====
3 years, 1 month
Self Introduction: Masoud
by masoud bolhassani
Hi,
This is Masoud,
I am interested in c, and Linux with no experience in open source
contributing.
I like to spend some time in the community and hope to be helpful.
Thanks.
3 years, 1 month
systemd-resolved fallback DNS servers: usability vs. GDPR
by Tadej Janež
Hi,
I would like to question the decision that was made by systemd
maintainers to remove the fallback DNS server list:
https://src.fedoraproject.org/rpms/systemd/c/14b2fafb3688a4170a9c15235d1c...
And then backported to F33:
https://src.fedoraproject.org/rpms/systemd/c/ed795fb1fc9a2c20ebcac34bdf7e...
On F33, this actually breaks a working vanilla cloud instance by
removing the fallback DNS server list in a systemd upgrade, effectively
leaving the system with no DNS servers configured.
I described this in more detail here:
https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.o...
Zbigniew Jędrzejewski-Szmek wrote the following in the commit message
accompanying the fallback DNS server list removal:
> So hopefully users will not see any effect from the change done in
> this patch. Right now I think it is better to avoid the legal and
> privacy risk. If it turns out this change causes noticable problems,
> we might want to reconsider. In particular we could use the fallback
> servers only in containers and such which are not "personal" machines
> and there is no particular person attached to them.
I would argue that the change causes noticeable problems and we want to
reconsider this change.
In particular, I think cloud image users would prefer to have their
cloud instances usable out of the box, i.e. have DNS working out-of-the
box.
Don't get me wrong, I understand the privacy concerns and I think
Fedora should strive to protect the privacy of its users as much as
possible, but at the same time, the circumstances of a cloud instance
are probably very different from a e.g. workstation instance.
Possible solutions that come to mind:
1) Use different defaults for different Fedora editions, e.g. container
and cloud images include the fallback DNS servers list while
workstation (and similar) images don't.
2) Pick a reputable DNS resolver that preserves users' privacy and
doesn't log anything and configure it as a fallback DNS server.
Here is a good summary of DNS resolvers and their privacy:
https://privacytools.io/providers/dns/#dns
Thoughts?
Regards,
Tadej
P.S. I'm subscribed, but please keep me in Cc so I'll notice replies
sooner.
3 years, 1 month
sssd: No %post/%preun/%postun?!?
by Richard Shaw
Per the packaging guidelines these don't seem to be optional:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_sy...
Additionally, at a minimum systemctl daemon-reload should be run. It looks
like there is some sort of default behavior but it's not correct.
Warning: The unit file, source configuration file or drop-ins of
sssd-kcm.socket changed on disk. Run 'systemctl daemon-reload' to reload
units.
Warning: The unit file, source configuration file or drop-ins of
sssd-kcm.service changed on disk. Run 'systemctl daemon-reload' to reload
units.
Even the base sssd service seems to be missing daemon-reload:
Warning: The unit file, source configuration file or drop-ins of
sssd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
For the other services provided the default behavior seems to be of the
try-restart variety but all (most?) of these are indirectly started by
socket activation so should be using %systemd_postun and not
%systemd_postun_with_restart:
Failed to try-restart sssd-autofs.service: Operation refused, unit
sssd-autofs.service may be requested by dependency only (it is configured
to refuse manual start/stop).
See system logs and 'systemctl status sssd-autofs.service' for details.
Failed to try-restart sssd-nss.service: Operation refused, unit
sssd-nss.service may be requested by dependency only (it is configured to
refuse manual start/stop).
See system logs and 'systemctl status sssd-nss.service' for details.
Failed to try-restart sssd-pac.service: Operation refused, unit
sssd-pac.service may be requested by dependency only (it is configured to
refuse manual start/stop).
See system logs and 'systemctl status sssd-pac.service' for details.
Failed to try-restart sssd-pam.service: Operation refused, unit
sssd-pam.service may be requested by dependency only (it is configured to
refuse manual start/stop).
See system logs and 'systemctl status sssd-pam.service' for details.
Failed to try-restart sssd-ssh.service: Operation refused, unit
sssd-ssh.service may be requested by dependency only (it is configured to
refuse manual start/stop).
See system logs and 'systemctl status sssd-ssh.service' for details.
Failed to try-restart sssd-sudo.service: Operation refused, unit
sssd-sudo.service may be requested by dependency only (it is configured to
refuse manual start/stop).
See system logs and 'systemctl status sssd-sudo.service' for details.
Looking at my dnf rpm log, this seems to have been going on for quite some
time and I can't believe I'm the first to notice...
Thanks,
Richard
3 years, 1 month
split-DNS, resolvconf on Fedora
by Petr Menšík
Hi,
I have submitted new package openresolv [1], which provides resolvconf
tool, similar to Debian's resolvconf package.
Why? I thought about common interface to various DNS cache
implementations for workstations and different VPN providers available.
While I think the best place to direct, which interface resolvers should
handle given domains. resolvconf handles conflicting requests from
different interfaces, when multiple DNS resolver providers are
configured by connection.
Current Fedora 33 already has /usr/sbin/resolvconf provided by
systemd-resolved. It provides split-DNS implementation in default Fedora
installation[2]. Problem is this is useful only in case systemd-resolved
service is running and used. When it is disabled, its resolvconf just
fails. But because systemd-resolved does not have its own subpackage,
the daemon can be only disabled, not uninstalled.
My question is, how should dhclient or vpn provider check resolvconf is
installed and enabled? It usually checks [ -x /usr/sbin/resolvconf ] in
Debian from shell, but because resolvconf is always present on Fedora,
it cannot work. Unlike Debian, where systemd does not provide
resolvconf. How could it therefore check, how should be /etc/resolv.conf
updated? How would dhclient know, when to rewrite /etc/resolv.conf
itself or when to use resolvconf for coordinated changes?
I think Network Manager should manage DNS domains list per connection
IMO. But in cases VPN provider is not configured via NM or NM is not
even used, I think resolvconf is good alternative to set and restore the
system's /etc/resolv.conf, when any VPN service is started. Only
systemd-resolved and dnsmasq can support split-DNS from NM.
openresolv is written only in shell, has no other dependencies. It could
support multiple DNS implementations as a local cache[3]. It currently
breaks systemd's symlink /usr/sbin/resolvconf, it uses alternatives
links. But systemd package does not use it, so after uninstallation of
openresolv, resolvconf remains broken. I think this has to be solved by
systemd package.
Do you have any opinion, how should resolvconf be supported on Fedora?
Any opinion against it?
1. https://src.fedoraproject.org/rpms/openresolv
2. https://fedoraproject.org/wiki/Changes/systemd-resolved#Split_DNS
3. https://roy.marples.name/projects/openresolv/configuration/
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik(a)redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
3 years, 1 month
