Re: Starting raid-check.timer renders system unusable
On 22/03/2021 03:46, Jonathan Dieter wrote: On Sun, 2021-03-21 at 17:52 +, Jonathan Dieter wrote: I'm really hoping that I'm missing something obvious here, but I fear that a good chunk of our Fedora systems will be unbootable if they're rebooted without disabling raid-check.timer. Just to follow up on this, it appears that the problem is limited to systems in the Europe/Dublin time zone. Not good, but not the disaster I was fearing. Never been so glad to miss something obvious. ;) Also, with raid-check.timer enabled I get [egreshko@f33g ~]$ sudo timedatectl set-timezone Europe/Dublin [egreshko@f33g ~]$ date Sun Mar 21 22:49:06 GMT 2021 [egreshko@f33g ~]$ sudo timedatectl set-timezone Asia/Taipei Appears to hang at this point. But a minute or so later Failed to set time zone: Connection timed out -- People who believe they don't make mistakes have already made one. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On 02/03/2021 17:30, Alexander Bokovoy wrote: On ti, 02 maalis 2021, Ed Greshko wrote: On 02/03/2021 06:03, Lennart Poettering wrote: On Fr, 26.02.21 21:01, Alexander Bokovoy (aboko...@redhat.com) wrote: Digital Ocean updates pushed with cloud-init use. Cloud-init does not have any native support for systemd-resolved. It means it writes something that systemd-resolved imports into own state. I would argue that your arguments for systemd-wide configuration rules do not apply here. Either you'd need to fix cloud-init or allow for a variance in input data that comes to systemd-resolved from third parties. Hmm, cloud-init has no direct support for resolved.conf? But how is it then that that file is modified? I don't get it? Pardon my "editorial" comment here. I'm rather down on Digital Ocean. Servers in their network have been responsible for the majority of sustained brute force ssh attacks on my systems. I find myself filing multiple abuse reports with them weekly. This can be said about pretty much every public cloud provider with 'cheap' systems that easy to deploy and remove. I see 'ssh' attacks everywhere to any just created machine. While I do see attacks from "everywhere" the attacks are generally short lived. With Digital Ocean I get attacks that last for hours. I would think these kind of providers could detect outgoing attacks. Oh, well. -- People who believe they don't make mistakes have already made one. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On 02/03/2021 06:03, Lennart Poettering wrote: On Fr, 26.02.21 21:01, Alexander Bokovoy (aboko...@redhat.com) wrote: Digital Ocean updates pushed with cloud-init use. Cloud-init does not have any native support for systemd-resolved. It means it writes something that systemd-resolved imports into own state. I would argue that your arguments for systemd-wide configuration rules do not apply here. Either you'd need to fix cloud-init or allow for a variance in input data that comes to systemd-resolved from third parties. Hmm, cloud-init has no direct support for resolved.conf? But how is it then that that file is modified? I don't get it? Pardon my "editorial" comment here. I'm rather down on Digital Ocean. Servers in their network have been responsible for the majority of sustained brute force ssh attacks on my systems. I find myself filing multiple abuse reports with them weekly. -- People who believe they don't make mistakes have already made one. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Don't update to the latest f33!
On 18/02/2021 09:18, Steve Dickson wrote: On 2/17/21 6:55 PM, Ed Greshko wrote: On 18/02/2021 05:11, Steve Dickson wrote: I agree... ignoring syntax error or parsing error just does not seem like the appropriate thing to do... Error out! Tell me what is broken so I can fix it!! Replace the "," with a " " in the DNS= entry of /etc/systemd/resolved.conf file. And if you didn't format it that way, find out who did. That is the question!!! I upgraded and DNS broke! I didn't even know there was a /etc/systemd/resolved.conf file until this unfortunate experience... I know this won't make you feel any better. But the problem you've seen has probably always existed on your system but was "hidden" from view. Previously the default for FallbackDNS as shown in /etc/systemd/resolved.conf was #FallbackDNS=1.1.1.1 8.8.8.8 1.0.0.1 8.8.4.4 2606:4700:4700:: 2001:4860:4860:: 2606:4700:4700::1001 2001:4860:4860::884 But many folks complained that they didn't want a Fallback defined pointing to Google or other "services". So, it was removed and is now #FallbackDNS= Meaning none are defined. So, previously, if your DNS= entry was incorrect you'd be protected by the existence of the Fallback being defined. Now, they are not. So, whoever supplied the badly formatted /etc/systemd/resolved.conf file is the "real" culprit. If I recall, you're using a VM supplied by a vendor? If so, have you notified them? -- People who believe they don't make mistakes have already made one. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Don't update to the latest f33!
On 18/02/2021 05:11, Steve Dickson wrote: I agree... ignoring syntax error or parsing error just does not seem like the appropriate thing to do... Error out! Tell me what is broken so I can fix it!! Replace the "," with a " " in the DNS= entry of /etc/systemd/resolved.conf file. And if you didn't format it that way, find out who did. And, if you've never made an incorrect format in a configuration file in your life, consider yourself lucky. The worst ones are formatting failures which occur silently yet things don't work. -- People who believe they don't make mistakes have already made one. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Don't update to the latest f33!
On 17/02/2021 04:24, Marius Schwarz wrote: Am 16.02.21 um 15:03 schrieb Ed Greshko: Thanks for the help! FWIW, I suppose I don't know why a BZ is needed since the /etc/systemd/resolved.conf has a sample for the DNS= parameter showing: I think that "," is received by a dhcp answere from the dhcpd, which knows two dns and sets it that way. Maybe a mistake in the dhcp implementation or config line. IMHO systemd should be fail-tolerant to this kind of "bug", so a br is a good idea. The file in question is /etc/systemd/resolved.conf. This file isn't changed/managed by DHCP. -- People who believe they don't make mistakes have already made one. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Don't update to the latest f33!
On 16/02/2021 21:37, Steve Dickson wrote: On 2/15/21 9:16 PM, Dominique Martinet wrote: Steve Dickson wrote on Mon, Feb 15, 2021 at 09:04:52PM -0500: I think if no IP was successfully parsed the fallback ought to kick in, so it's a systemd-resolved bug -- do you want to report this upstream or shall I now I've had a look? Fedora bz or an upstream bz? If is the latter where do I report it? We have systemd devs in fedora so I think either would work out. upstream is on github: https://github.com/systemd/systemd/issues https://bugzilla.redhat.com/show_bug.cgi?id=1929212 Thanks for the help! FWIW, I suppose I don't know why a BZ is needed since the /etc/systemd/resolved.conf has a sample for the DNS= parameter showing: # Some examples of DNS servers which may be used for DNS= and FallbackDNS=: # Cloudflare: 1.1.1.1 1.0.0.1 2606:4700:4700:: 2606:4700:4700::1001 # Google: 8.8.8.8 8.8.4.4 2001:4860:4860:: 2001:4860:4860::884 And the man page for resolved.conf explicitly states: DNS= A space-separated list of IPv4 and IPv6 addresses to use as system DNS servers. Is the expectation that any character which may be considered a delimiter should be acceptable? Wouldn't the more appropriate course of action be to correct format? -- People who believe they don't make mistakes have already made one. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Don't update to the latest f33!
On 16/02/2021 09:10, Steve Dickson wrote: On 2/15/21 7:55 PM, Ed Greshko wrote: On 16/02/2021 08:50, Steve Dickson wrote: But I think this is the problem... systemctl start systemd-resolved systemctl -o cat status systemd-resolved Starting Network Name Resolution... Positive Trust Anchors: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.i> Failed to add DNS server address '67.207.67.2,67.207.67.3', ignoring: Invalid argument Using system hostname 'steved-v4dev-f33.nfsv4.dev'. Started Network Name Resolution. What has changed in the parsing of DNS server addresses??? I get... Positive Trust Anchors: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 1> Using system hostname 'meimei.greshko.com'. I don't see where your DNS servers are defined from the previous post you showed. My primary interface is enp2s0 and I get... [egreshko@meimei ~]$ nmcli device show enp2s0 | grep -i dns IP4.DNS[1]: 192.168.1.142 IP6.DNS[1]: 2001:b030:112f::19 Does something get returned for your eth0 device? No... nmcli device show eth0 | grep -i dns nmcli device show eth1 | grep -i dns but... after changing /etc/systemd/resolved.conf to DNS=8.8.8.8 Then doing a systemctl restart systemd-resolved The dns started to work... There is an issue with the latest systemd-resolved I don't think so In my /etc/systemd/resolved.conf I have #DNS= So, you're just manually adding a DNS server. You're interface still doesn't have a DNS server defined. As Far As I can Tell. Why don't you try adding servers to your network configuration instead? I have systemd-246.10-1.fc33.x86_64 installed on all systems with no problems. -- People who believe they don't make mistakes have already made one. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Don't update to the latest f33!
On 16/02/2021 08:50, Steve Dickson wrote: But I think this is the problem... systemctl start systemd-resolved systemctl -o cat status systemd-resolved Starting Network Name Resolution... Positive Trust Anchors: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.i> Failed to add DNS server address '67.207.67.2,67.207.67.3', ignoring: Invalid argument Using system hostname 'steved-v4dev-f33.nfsv4.dev'. Started Network Name Resolution. What has changed in the parsing of DNS server addresses??? I get... Positive Trust Anchors: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 1> Using system hostname 'meimei.greshko.com'. I don't see where your DNS servers are defined from the previous post you showed. My primary interface is enp2s0 and I get... [egreshko@meimei ~]$ nmcli device show enp2s0 | grep -i dns IP4.DNS[1]: 192.168.1.142 IP6.DNS[1]: 2001:b030:112f::19 Does something get returned for your eth0 device? -- People who believe they don't make mistakes have already made one. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Don't update to the latest f33!
On 16/02/2021 08:35, Steve Dickson wrote: On 2/15/21 7:24 PM, Ed Greshko wrote: On 16/02/2021 08:17, Steve Dickson wrote: On 2/15/21 7:12 PM, Ed Greshko wrote: On 16/02/2021 06:40, Steve Dickson wrote: I just updated to latest Fedora 33 and I no longer have any DNS name solution. The network is up... but... $ pingwww.yahoo.com ping:www.yahoo.com: Name or service not known I changed nothing! How would be the bet way to debug this??? What is the output of resolvectl status # resolvectl status Global Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: missing Link 2 (eth0) Current Scopes: LLMNR/IPv4 LLMNR/IPv6 Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Link 3 (eth1) Current Scopes: LLMNR/IPv4 LLMNR/IPv6 Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Well, that is an indication of a problem as it should return something like Link 2 (enp2s0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 192.168.1.142 DNS Servers: 192.168.1.142 2001:b030:112f::19 DNS Domain: greshko.com The question then is how your eth0 and/or eth1 obtain their IP addresses. Are they configured statically or via DHCP? Both Statically: BOOTPROTO=none DEFROUTE=yes DEVICE=eth0 GATEWAY=164.90.128.1 HWADDR=22:df:7b:34:93:fe IPADDR=164.90.129.207 IPADDR6=2604:a880:800:c1::470:e001/64 IPV6ADDR=2604:a880:800:c1::470:e001/64 IPV6INIT=yes IPV6_DEFAULTGW=2604:A880:0800:00C1::::0001 NETMASK=255.255.240.0 NETMASK1=255.255.0.0 ONBOOT=yes STARTMODE=auto TYPE=Ethernet USERCTL=yes BOOTPROTO=none DEVICE=eth1 HWADDR=a6:91:39:b6:3c:7e IPADDR=10.108.0.2 NETMASK=255.255.240.0 ONBOOT=yes STARTMODE=auto TYPE=Ethernet USERCTL=no steved. What happened to (for example) DNS1=192.168.1.142 DOMAIN=greshko.com ??? -- People who believe they don't make mistakes have already made one. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Don't update to the latest f33!
I think I may have sent this off-list On 16/02/2021 08:17, Steve Dickson wrote: On 2/15/21 7:12 PM, Ed Greshko wrote: On 16/02/2021 06:40, Steve Dickson wrote: I just updated to latest Fedora 33 and I no longer have any DNS name solution. The network is up... but... $ pingwww.yahoo.com ping:www.yahoo.com: Name or service not known I changed nothing! How would be the bet way to debug this??? What is the output of resolvectl status # resolvectl status Global Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: missing Link 2 (eth0) Current Scopes: LLMNR/IPv4 LLMNR/IPv6 Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Link 3 (eth1) Current Scopes: LLMNR/IPv4 LLMNR/IPv6 Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Well, that is an indication of a problem as it should return something like Link 2 (enp2s0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 192.168.1.142 DNS Servers: 192.168.1.142 2001:b030:112f::19 DNS Domain: greshko.com The question then is how your eth0 and/or eth1 obtain their IP addresses. Are they configured statically or via DHCP? -- People who believe they don't make mistakes have already made one. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Don't update to the latest f33!
On 16/02/2021 08:17, Steve Dickson wrote: On 2/15/21 7:12 PM, Ed Greshko wrote: On 16/02/2021 06:40, Steve Dickson wrote: I just updated to latest Fedora 33 and I no longer have any DNS name solution. The network is up... but... $ pingwww.yahoo.com ping:www.yahoo.com: Name or service not known I changed nothing! How would be the bet way to debug this??? What is the output of resolvectl status # resolvectl status Global Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: missing Link 2 (eth0) Current Scopes: LLMNR/IPv4 LLMNR/IPv6 Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Link 3 (eth1) Current Scopes: LLMNR/IPv4 LLMNR/IPv6 Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Well, that is an indication of a problem as it should return something like Link 2 (enp2s0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 192.168.1.142 DNS Servers: 192.168.1.142 2001:b030:112f::19 DNS Domain: greshko.com The question then is how your eth0 and/or eth1 obtain their IP addresses. Are they configured statically or via DHCP? -- People who believe they don't make mistakes have already made one. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Don't update to the latest f33!
On 16/02/2021 06:40, Steve Dickson wrote: I just updated to latest Fedora 33 and I no longer have any DNS name solution. The network is up... but... $ pingwww.yahoo.com ping:www.yahoo.com: Name or service not known I changed nothing! How would be the bet way to debug this??? What is the output of resolvectl status -- People who believe they don't make mistakes have already made one. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Rawhide hangs booting 5.11.0-rc2
On 10/01/2021 09:39, Ian Laurie wrote: I just updated a VirtualBox Rawhide guest with latest updates which included the 5.11.0-rc2 kernel and the system hangs on boot (pic attached). The system was updated a few days ago so was reasonably up to date before today. Booting the previous kernel 5.10.0-rc6 still works OK. In case something weird happened in the update, I reverted to a backed up copy of the vm (also reasonably up to date) and updated kernel* and rebooted with the exact same results. Is anyone else seeing this problem with VirtualBox guests? FWIW, a qemu VM boots just fine with that kernel. --- The key to getting good answers is to ask good questions. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: GNU Guix
On 2020-09-29 21:42, Kevin Fenzi wrote: > On Tue, Sep 29, 2020 at 01:30:01PM +, Zbigniew Jędrzejewski-Szmek wrote: >> On Tue, Sep 29, 2020 at 06:26:46AM -0700, Kevin Fenzi wrote: >>> On Tue, Sep 29, 2020 at 11:12:40AM +, Cuckoo's Calling via devel wrote: Hello All, I came across an amazing project called GNU Guix. So, I made an animation to introduce the novel concepts of this project. Here is the link for the video, https://gnuguix-drive.mycozy.cloud/public?sharecode=YvERPGX14g5S Please leave me a feedback on your experience. >>> This is not on topic for the fedora-devel list. >> I think that's just spam. There were more posts in unrelated threads. > Yeah, also the email bounces. > > I've moderated them in case they send anymore. > On the "users" list as well, I hope? -- The key to getting good answers is to ask good questions. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On 2020-09-02 11:00, Neal Gompa wrote: > On Tue, Sep 1, 2020 at 10:51 PM Nico Kadel-Garcia wrote: >> On Tue, Sep 1, 2020 at 10:21 PM John M. Harris Jr >> wrote: >>> On Tuesday, September 1, 2020 7:14:35 AM MST Michael Catanzaro wrote: On Mon, Aug 31, 2020 at 11:49 pm, John M. Harris Jr wrote: > Michael, > > The file is /etc/nsswitch.conf. You're wasting everyone's time with these low-effort spam posts. >>> I don't see how this could possibly be spam. This is where the file is, is >>> it >>> not? >>> Lest anyone become confused, there is a big warning at the top of that file warning you that it is managed by authselect, and that manual changes will be overwritten. >>> I don't know what you're talking about here. Am I missing something? Is >>> this a >>> F33 Change? Exact content of my /etc/nsswitch: >> Stated in the file or not, it is in fact edited by authconfig, >> sometimes as part of RPM installation. Manual editing of it is not and >> has never been stable without setting up some kind of configuration >> management to restore RPM based modifications. Been there, done that, >> with one of those 10-year solo admins who decided to hand-edit tweaks >> but refused to permit management of the file. >> >> And oh, "files" always comes first because local config files should >> always take priority over upstream network based services. > authconfig is dead. But yes, nsswitch is managed by authselect. > I would state that slightly differently. nsswitch.conf is now managed by authselect by default. I say that since, as I've already mentioned, I have a F32 system which has been upgraded over time from versions without authselect. The upgrade didn't changed that. So, to become more conforming to current practice I did just run... authselect select --force sssd -- The key to getting good answers is to ask good questions. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On 2020-09-02 11:06, John M. Harris Jr wrote: > On Tuesday, September 1, 2020 7:29:44 PM MST Ed Greshko wrote: >> On 2020-09-02 10:21, John M. Harris Jr wrote: >> >>> I don't know what you're talking about here. Am I missing something? Is >>> this a F33 Change? Exact content of my /etc/nsswitch: >> >> Is your system an upgrade of an earlier version? >> >> In my case I have an F32 system which has been around for a few years. It >> has the text you cite. > >> I also have an F32 system which was a fresh install as well as a F31 fresh >> install. Both have > >> # Generated by authselect on Fri Jul 31 09:40:00 2020 >> # Do not modify this file manually. >> >> # If you want to make changes to nsswitch.conf please modify >> # /etc/authselect/user-nsswitch.conf and run 'authselect apply-changes'. >> >> In /etc/nsswitch.conf. So, the default use of authselect has been around >> since at least F31. > My system was originally F24. So, which of these is the actual configuration > file at this point? > Upgrades didn't change how things are done. I think it may have been F29 or F30 when authselect was introduced and made the default method to manage nsswitch.conf. FWIW, on this old system of mine I did just run authselect select --force sssd to bring it forward to the current practice. -- The key to getting good answers is to ask good questions. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On 2020-09-02 10:21, John M. Harris Jr wrote: > I don't know what you're talking about here. Am I missing something? Is this > a > F33 Change? Exact content of my /etc/nsswitch: Is your system an upgrade of an earlier version? In my case I have an F32 system which has been around for a few years. It has the text you cite. I also have an F32 system which was a fresh install as well as a F31 fresh install. Both have # Generated by authselect on Fri Jul 31 09:40:00 2020 # Do not modify this file manually. # If you want to make changes to nsswitch.conf please modify # /etc/authselect/user-nsswitch.conf and run 'authselect apply-changes'. In /etc/nsswitch.conf. So, the default use of authselect has been around since at least F31. -- The key to getting good answers is to ask good questions. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On 2020-09-01 01:18, Michael Catanzaro wrote: > > On Mon, Aug 31, 2020 at 9:36 pm, Ed Greshko wrote: >> But with that symlink it seems there is no integration with NetworkManager. >> So, if one has configured (which is >> the default) to acquire addresses automatically then DNS server info >> supplied by DHCP is ignored. >> >> Is my take incorrect? > > Hopefully. NetworkManager should be pushing DNS configuration from DHCP to > systemd-resolved. Sounds like you might be encountering some strange bug > OK, I looked a bit closer at the issue. Indeed, systemd-resolved is getting the DNS server information. The actual issue is a lack of a DNS Domain. (a.k.a. "search" setting) I don't think the DHCP server for the QEMU VMs is supplying a domain. However, Network Manager will add a "search" option to resolv.conf when "hostname" returns a FQDN. This is using F33 Workstation. [egreshko@f33g ~]$ hostname f33g.greshko.com [egreshko@f33g ~]$ host nas Host nas not found: 2(SERVFAIL) [egreshko@f33g ~]$ host nas.greshko.com nas.greshko.com has address 192.168.1.142 nas.greshko.com has IPv6 address 2001:b030:112f::19 [egreshko@f33g ~]$ resolvectl Global LLMNR setting: resolve MulticastDNS setting: resolve DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no Fallback DNS Servers: 1.1.1.1 8.8.8.8 1.0.0.1 8.8.4.4 2606:4700:4700:: 2001:4860:4860:: 2606:4700:4700::1001 2001:4860:4860::8844 Link 2 (enp1s0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 DefaultRoute setting: yes LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no Current DNS Server: 192.168.122.1 DNS Servers: 192.168.122.1 DNS Domain: ~. -- The key to getting good answers is to ask good questions. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On 2020-08-31 21:40, John M. Harris Jr wrote: > On Monday, August 31, 2020 1:22:58 AM MST Ed Greshko wrote: >> On 2020-08-30 18:30, Andreas Tunek wrote: >> >>> On my F33 test system (new install yesterday) I can see my NAS but I can't >>> connect to it. Could that be due to this change? >> Could you me a bit more specific? >> >> I just installed from Fedora-Workstation-Live-x86_64-33-20200829.n.0.iso to >> a VM and everything seems working just fine for me. >> >> [egreshko@f33g ~]$ resolvectl >> Global >>LLMNR setting: resolve >> MulticastDNS setting: resolve >> DNSOverTLS setting: no >> DNSSEC setting: no >> DNSSEC supported: no >> Current DNS Server: 192.168.122.1 >> DNS Servers: 192.168.122.1 >> Fallback DNS Servers: 1.1.1.1 >> 8.8.8.8 >> 1.0.0.1 >> 8.8.4.4 >> 2606:4700:4700:: >> 2001:4860:4860:: >> 2606:4700:4700::1001 >> 2001:4860:4860::8844 >> DNS Domain: greshko.com >> >> Link 2 (enp1s0) >> Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 >> >> [egreshko@f33g ~]$ ll /etc/resolv.conf >> -rw-r--r--. 1 root root 74 Aug 31 10:33 /etc/resolv.conf >> >> [egreshko@f33g ~]$ cat /etc/resolv.conf >> # Generated by NetworkManager >> search greshko.com >> nameserver 192.168.122.1 >> >> [egreshko@f33g ~]$ df -T >> Filesystem Type 1K-blocks Used Available Use% Mounted on >> /dev/vda2btrfs 325048326213600 26109168 20% / >> /dev/vda2btrfs 325048326213600 26109168 20% /home >> /dev/vda1ext4 999320 184228 746280 20% /boot >> nas:/volume1/aux nfs4 5621463168 1920182016 3701281152 35% /aux > Ed, > > Where did you set these fallback servers? This is something that you > specifically chose to do, and not systemd, right? > My understanding is the Fallback Servers are hard coded. From the resolved.conf man page FallbackDNS= A space-separated list of IPv4 and IPv6 addresses to use as the fallback DNS servers. Please see DNS= for acceptable format of adddresses. Any per-link DNS servers obtained from systemd- networkd.service(8) take precedence over this setting, as do any servers set via DNS= above or /etc/resolv.conf. This setting is hence only used if no other DNS server information is known. If this option is not given, a compiled-in list of DNS servers is used instead. -- The key to getting good answers is to ask good questions. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On 2020-08-31 21:18, Michael Catanzaro wrote: > On Mon, Aug 31, 2020 at 1:09 pm, Vitaly Zaitsev via devel > wrote: >> You system is not using systemd-resolved. > > It mostly is, though, via nss-resolve. Only stuff that uses resolv.conf > directly is broken and not using resolved, which is > https://bugzilla.redhat.com/show_bug.cgi?id=1873856. Anything using glibc > should be fine. OK, I went to using a rawhide VM. That system does have the symlink to /run/systemd/resolve/stub-resolv.conf. But with that symlink it seems there is no integration with NetworkManager. So, if one has configured (which is the default) to acquire addresses automatically then DNS server info supplied by DHCP is ignored. Is my take incorrect? -- The key to getting good answers is to ask good questions. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On 2020-08-30 18:30, Andreas Tunek wrote: > On my F33 test system (new install yesterday) I can see my NAS but I can't > connect to it. Could that be due to this change? Could you me a bit more specific? I just installed from Fedora-Workstation-Live-x86_64-33-20200829.n.0.iso to a VM and everything seems working just fine for me. [egreshko@f33g ~]$ resolvectl Global LLMNR setting: resolve MulticastDNS setting: resolve DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no Current DNS Server: 192.168.122.1 DNS Servers: 192.168.122.1 Fallback DNS Servers: 1.1.1.1 8.8.8.8 1.0.0.1 8.8.4.4 2606:4700:4700:: 2001:4860:4860:: 2606:4700:4700::1001 2001:4860:4860::8844 DNS Domain: greshko.com Link 2 (enp1s0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 [egreshko@f33g ~]$ ll /etc/resolv.conf -rw-r--r--. 1 root root 74 Aug 31 10:33 /etc/resolv.conf [egreshko@f33g ~]$ cat /etc/resolv.conf # Generated by NetworkManager search greshko.com nameserver 192.168.122.1 [egreshko@f33g ~]$ df -T Filesystem Type 1K-blocks Used Available Use% Mounted on /dev/vda2 btrfs 32504832 6213600 26109168 20% / /dev/vda2 btrfs 32504832 6213600 26109168 20% /home /dev/vda1 ext4 999320 184228 746280 20% /boot nas:/volume1/aux nfs4 5621463168 1920182016 3701281152 35% /aux -- The key to getting good answers is to ask good questions. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Unsubscribe
On 2020-03-28 08:24, wen rei do wrote: > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- The key to getting good answers is to ask good questions. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
