Ed Greshko writes:
When I tested reverting to the previous behavior I simply started with an empty /etc/resolv.conf.No symlink. No selinux troubles. Everything just worked.
Well, then how do the apps that need to talk to the DNS server find it? Maybe something in the glibc resolver knows to look in the alternate locations if /etc/resolv.conf is empty.
But there are apps that read /etc/resolv.conf themselves (Firefox without a proxy?). They'll be hosed now.
Several years ago there was an issue with the network-online target being broken. Don't recall the exact technical cause, but the end result was that in some cases the network-online target was reached several seconds before, well, local network interfaces were actually configured. So, stuff that was configured to bind to a local IP address failed. It's beginning to come back to me – I think it's when you had static IP addresses, no dhcp, and I'm pretty sure that on one of my servers that are like that, and has sshd- server configured to be bound to an explicit local IP, and it still fails to start immediatley upon boot because the IP address is not configured, and then comes up only 42 seconds later when sshd-server tries again.
Anyhow, I was able to implement a workaround by installing a service that was After=NetworkManager-wait-online.service Before=network-online.targetand which ran a script that attempted to bind to the local IP address, every second, and terminated only when it succeeded.
Well, so far I'm seeing these selinux denials myself, but don't seem to suffer any actual fallout from that. If I ever do, and none of the quick hacks I mentioned will help, I guess I have to write another service that uses inotify to monitor no-stub-resolv.conf, and update /etc/resolv.conf. Or maybe a one-shot service that fixes the selinux context on no-stub- resolv.conf
That's life with systemd.
Attachment:
pgpaIdnUa2FkO.pgp
Description: PGP signature
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/users@xxxxxxxxxxxxxxxxxxxxxxx