Re: goal: booting with an empty /etc
I think I understand the immediate goal here, but I am still confused. What is the objective of achieving this "boot with empty /etc"? What does it accomplish? What problem does it solve? Is it a solution for a small use case such as containers or something else? What problem does it solve for me - a sysadmin with a few servers and some workstations? If the answer is in one of the early bits of this thread, could you point me to it please? Thanks! -- * David P. Both, RHCE He/Him/His * www.both.org - My personal web site www.Linux-Databook.info - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * The value of any software lies in its usefulness not in its price. — Linus Torvalds * On Mon, 11 Dec 2023, Zbigniew Jędrzejewski-Szmek wrote: Date: Mon, 11 Dec 2023 08:35:08 From: Zbigniew Jędrzejewski-Szmek Reply-To: Development discussions related to Fedora To: Florian Weimer Cc: Development discussions related to Fedora Subject: SPAM (302.2) Re: goal: booting with an empty /etc On Mon, Dec 11, 2023 at 09:58:04AM +0100, Florian Weimer wrote: * Zbigniew Jędrzejewski-Szmek: No, it would be the other way round. We might have a /usr/share/glibc/services which contains :include: /etc/services somewhere in it. Ah, OK. I understand how the format would look, but I don't understand why you'd want to implement it rather than something simpler. /etc/services is essentially a flat file that is scanned from top to bottom until a matching entry is found. In the proposed syntax, it'd need to have ':include: /etc/services' at the very top, so that the local config in /etc/services has higher priority. Consider the following alternative: each of [/etc/services, /usr/etc/services] is scanned in order, if the file exists. This is simpler to implement and allows either of the files to exist independently of the other. A stanza like ':include:' also opens the door for additional complications like different paths on different distros and include loops. It is _possible_, but the simpler scheme has the properties that we want. I want to replace nss_wrapper with a simple set of environment variables. Once we have a multi-file search path, it's no longer so simple because it's not clear if the default search path is amended or replaced when the environment variable is set. nss_wrapper currently fully overrides the system config. I think it'd be reasonable to keep that behaviour. But anyway: having to make that choice here is not a great argument against having multiple files, we just have to remember about the issue and implement and document one of the possibilities, whatever makes the most sense. Loop detection on traditional file systems wouldn't be very difficult to implement, except that we increasingly have file systems which have dev_t/ino_t values that are not unique. But that impacts any form of loop detection, so I'm not overly concerned. Yes, it certainly _can_ be done… The systemd-style drop-in mechanism works well and is at this point widely documented and understood. We also have cases where alternative mechanisms based on 'include' were implemented, and, at least in my opinion, they have proven to work less well. (E.g. sshd, sudo). Anyway, I think that at this point the technical arguments have been laid out, and we're down to questions of style. I _like_ the proposal with a fixed set of file paths better, but I'd be happy to take the version with include directives too, if it means we move some files out of /etc. Zbyszek -- ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Color Bash Prompt (System Wide)
I agree that blue is not good. It was impossible to read the welcome messages during boot and startup. The cyan/teal is much better. I typically use amber on black but sometimes use green on black so I'm not sure that green would help those who also use green font color. For me, on a black background, #54 works really well for both. Not so well on light backgrounds though. -- * David P. Both, RHCE He/Him/His * www.both.org - My personal web site www.Linux-Databook.info - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * The value of any software lies in its usefulness not in its price. — Linus Torvalds * On Fri, 7 Jul 2023, Chris Adams wrote: Date: Fri, 7 Jul 2023 08:56:00 From: Chris Adams Reply-To: Development discussions related to Fedora To: devel@lists.fedoraproject.org Subject: Re: F39 Change Proposal: Color Bash Prompt (System Wide) Once upon a time, Vít Ondruch said: Shouldn't blue be the default for Fedora? Blue is probably a bad idea in a prompt, as the human eye doesn't perceive blue as strongly as green. The prompt isn't about art/style, it's purely about functionality. ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: UW-IMAP
Yes, 14 days would be fine. Sehr gut. -- * David P. Both, RHCE He/Him/His * www.both.org - My personal web site www.Linux-Databook.info - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * The value of any software lies in its usefulness not in its price. — Linus Torvalds * On Thu, 29 Jun 2023, Peter Boy wrote: Date: Thu, 29 Jun 2023 14:53:20 From: Peter Boy Reply-To: Development discussions related to Fedora To: David Both , Development discussions related to Fedora Subject: Re: UW-IMAP Am 29.06.2023 um 18:15 schrieb David Both : @Peter Boy: I would truly appreciate your step-by-step guide. That would be incredibly helpful. I'm sure I can figure out connecting it with SendMail. There is lots of information out there but - as I said - it needs some work. If you make it CC-by-SA it should be unencumbered and I will be sure to attribute that section to you. With your guide I would gladly use Dovecot. I do have a deadline. Do you have an estimate of when you might finish the translation? I know a little German from uni but not nearly enough to do a translation. Danke und guten Tag. -- Das klingt schon mal gut. Well, I’m quite flexible at the moment. Maybe I have to prepare some contribution to FLOCK, just in case a proposal would get accepted. It’s quite comfortable for me to do it in the next 14 days. If that’s OK for your deadline. Otherwise I would reorganize my planning a bit more. Generally it’s not so much work using DeepL and some fine-tuning. But I would like to update the text slightly and do a final test - just to be sure (and I have to do that anyway for the planned tutorial). And CC-by-SA is OK for me (I just don’t remember what we sign with FAS account). Peter -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST /UTC+2) Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: UW-IMAP
@Peter Boy: I would truly appreciate your step-by-step guide. That would be incredibly helpful. I'm sure I can figure out connecting it with SendMail. There is lots of information out there but - as I said - it needs some work. If you make it CC-by-SA it should be unencumbered and I will be sure to attribute that section to you. With your guide I would gladly use Dovecot. I do have a deadline. Do you have an estimate of when you might finish the translation? I know a little German from uni but not nearly enough to do a translation. Danke und guten Tag. -- * David P. Both, RHCE He/Him/His * www.both.org - My personal web site www.Linux-Databook.info - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * The value of any software lies in its usefulness not in its price. — Linus Torvalds * On Thu, 29 Jun 2023, Peter Boy wrote: Date: Thu, 29 Jun 2023 11:38:42 From: Peter Boy Reply-To: Development discussions related to Fedora To: David Both , Development discussions related to Fedora Subject: Re: UW-IMAP Hi, Am 29.06.2023 um 16:27 schrieb David Both : ... I also spent about 4 days trying to get Dovecot to work with SendMail in a test VM setup. I'm either missing one or more important bits or its just too complex for me. None of the docs I have found anywhere has a complete start-to-finish picture. I find no accurate list of here's exactly what needs to be in place and configured in this way to make it work. The docs I find are incomplete because they assume much about my knowledge or just skip parts that are needed. Others are just plain wrong after trying them. Just in case you decide for dovecot (which would be preferable, IMHO), I could contribute a step-by-step guide to create a workable configuration of dovecot (it is Part of a solution for a rather full-fledged mail service). However, the instructions use Postfix, not Sendmail. But because the connection runs via milter, the replacement with Sendmail should not be a difficult. At the moment everything is (still) in German. But I have to translate it anyway, because I want to create a tutorial for Fedora Server from it. [1] http://www.both.org/?page_id=1183 What a coincidence, actually found this in my ePub library (though still unread, sorry :-) ). -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST /UTC+2) Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: UW-IMAP
OK - I had no idea about any of that drama. I did find Panda IMAP and a couple others. I also spent about 4 days trying to get Dovecot to work with SendMail in a test VM setup. I'm either missing one or more important bits or its just too complex for me. None of the docs I have found anywhere has a complete start-to-finish picture. I find no accurate list of here's exactly what needs to be in place and configured in this way to make it work. The docs I find are incomplete because they assume much about my knowledge or just skip parts that are needed. Others are just plain wrong after trying them. I know I don't have a lot of cruft to get in the way because I can use the last snapshot before I started trying to install IMAP. Although I am trying to do this for my own SendMail server, I am also trying to find a simple IMAP server I can use for the email chapters in the next edition of my books[1], "Using and Administering Linux." That's why I really want something easy and simple. I've also looked at Courier as it seems a simple AIO but that's not part of any current Fedora repo. I might check it out in more detail for my book. Anyway - thanks for the responses. I appreciate knowing that history. [1] http://www.both.org/?page_id=1183 -- * David P. Both, RHCE He/Him/His * www.both.org - My personal web site www.Linux-Databook.info - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * The value of any software lies in its usefulness not in its price. — Linus Torvalds * On Thu, 29 Jun 2023, Nico Kadel-Garcia wrote: Date: Thu, 29 Jun 2023 09:42:13 From: Nico Kadel-Garcia Reply-To: Development discussions related to Fedora To: Development discussions related to Fedora Subject: Re: UW-IMAP On Thu, Jun 29, 2023 at 9:18 AM Marcin Juszkiewicz wrote: W dniu 29.06.2023 o 14:57, David Both pisze: I have noticed that uw-imap is no longer in the Fedora repo and that the last was F33. I like it far better than the other options because it is the IMAP server that best "does one things and does it well." It also requires the least amount of configuration and it just works so it also meets the KISS test. UW IMAP development ended in 2008. Development of Panda IMAP (successor) ended in 2012 when Mark Crispin died. https://github.com/jonabbey/panda-imap holds complete public history. I would rather go Dovecot rather than revive 11 years old project. Did setup of it once, about 10 years, and it serves my private mail since then. uw-imap got pretty weird, with Mark Crispin getting very, very upset and accusing people of stealing his university's code if they merely *pointed to* off-shore repositories where SSL patches were published and could be legally imported without running into US export laws. He had SSL hooks which he refused to publish, except for his university's internal use. The arguments got *weird*, and heated, and some of us were very grateful to be able to switch to dovecot and avoid the issues. David, have you tried dovecot as a "simple IMAP server"? ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
UW-IMAP
I have noticed that uw-imap is no longer in the Fedora repo and that the last was F33. I like it far better than the other options because it is the IMAP server that best "does one things and does it well." It also requires the least amount of configuration and it just works so it also meets the KISS test. I am willing to take it on to fix the problems that prevent it being properly built and to ensure that it continues to be available for future Fedora releases. I can take the F33 RPM, and a couple libs from F33, install them on F38 and it works very well. So I know that much. Hopefully it will be as simple as getting it to build and packaging it. My objectives are in sequence: 1. Fork uw-imap and give it a new name. I would keep the current "provides" as uw-mail for compatibility. 2. Get it to build and install along with xinetd which is still required for it. 3. Migrate it to systemd as quickly as possible. 4. Learn a lot! 5. Don't change anything else unless absolutely necessary. That means no new "features." 6. Fix any newly encountered bugs. 7. Build a small team to keep it going in the future. If anyone has an interest in being part of the small team, please let me know. If you have any information at all about the specific problems that currently keep it from being built, please let me know what those are and any thoughts you might have about that. I am looking at the github repo, but is it the best/most recent? I will try to figure out how to take that over and will go from there. Any comments, pointers, and suggestions are welcome. Thanks! -- * David P. Both, RHCE He/Him/His * www.both.org - My personal web site www.Linux-Databook.info - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * The value of any software lies in its usefulness not in its price. — Linus Torvalds * ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
I live in a 1st world country and have lots of new computers that this change would not affect. However I still have some older computers that fall outside the UEFI range and use only BIOS. I would still like to keep these computers running and up to date so that they are secure and have the most recent fixes. I also know many people who only have access to 2nd or 3rd hand computers. I do have a strong opinion and I say that it is too early to drop BIOS support. There will probably be BIOS-only computers out there for years. And one of the things I tell people when getting them to try Linux is that it can extend the useful lives of those really old computers. Thanks for considering my opinion. -- * David P. Both, RHCE He/Him/His * www.both.org - My personal web site www.Linux-Databook.info - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * The value of any software lies in its usefulness not in its price. — Linus Torvalds * On Wed, 6 Apr 2022, JT wrote: Date: Wed, 6 Apr 2022 08:50:18 From: JT Reply-To: Development discussions related to Fedora To: Development discussions related to Fedora Cc: laolux laolux Subject: Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal) On Wed, Apr 6, 2022 at 4:06 AM laolux laolux via devel < devel@lists.fedoraproject.org> wrote: I have no strong opinion on this, and not much say anyways, but I thought I could share my little piece of info. My currently one and only computer is a 2012 MSI GE60 0ND, with a core i7-3630QM, 16GB RAM and retrofitted with a SSD. So I would say fast enough for using Fedora. At least according to notebookcheck.com the CPU is supposed to be faster than a rather recent Core i3-1110G4, which is still being used in new notebooks in 2022. Unfortunately it only supports legacy BIOS, and not UEFI. Thus I do not like the wording of the change proposal. Fedora already requires a 2GHz dual core CPU at minimum (and therefore mandates that machines must have been made after 2006). Like the already accepted Fedora 37 change to retire ARMv7 support, the hardware targeted tends to be rather underpowered by today’s standards, and the world has moved on from it. Intel stopped shipping the last vestiges of BIOS support in 2020 (as have other vendors, and Apple and Microsoft), so this is clearly the way things are heading - and therefore aligns with Fedora’s “First” objective. This seems to imply that only rather old and weak hardware would be affected, when clearly the cutoff is (at maximum) only 10 years back. Please don't get me wrong, I am perfectly fine about Fedora dropping "old" hardware, and I am willing to throw away my still working notebook, producing a little bit electronic waste when the time comes. But I think one should be more open and explicit about it. At the risk of being 'that guy' it's worth pointing out that not everyone lives in a 1st world country and has access to cheap powerful hardware. I have good friends in Namibia and Cote d'Ivoire who are still using Fedora on Core2Duo systems from pre 2010, because the machines are still perfectly functional and do what they need them to do. I realize some will have the attitude of "they can just not upgrade and keep using their old Fedora versions". Ok, that's a possible solution, except that Fedora versions get EOL'd pretty quickly, so we'd basically be taking the stance of 'buy new hardware if you want updates'. Fedora has made a big deal about being considered a "Digital Public Good"; and we are right to be proud of that. But if we're going to be proud of that, let's not also decide to screw over areas that are not as economically strong as where most of us are lucky enough to live. It's kind of arrogant of us to expect that everyone who uses Fedora is financially able to go out and replace their hardware all the time even when there's nothing wrong with it. Are we only making Fedora for those with lots of spare money or is Fedora for everyone? /end being that guy ___ 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!
No problem - I need to know this. Thanks! -- * David P. Both, RHCE He/Him/His * www.both.org - My personal web site www.Linux-Databook.info - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * The value of any software lies in its usefulness not in its price. — Linus Torvalds * On Mon, 22 Feb 2021, Michael Catanzaro wrote: Date: Mon, 22 Feb 2021 18:02:08 From: Michael Catanzaro Reply-To: Development discussions related to Fedora To: David Both Cc: Development discussions related to Fedora , Steve Dickson Subject: Re: Don't update to the latest f33! On Mon, Feb 22, 2021 at 5:43 pm, David Both wrote: I will check because I thought I had TLS up and working. Apparently not. How did you discover this? I will fix it as soon as possible. All of my mails to you are bouncing. Notice you don't have any direct mails from me in your inbox. You're reading this via my reply to devel@lists.fedoraproject.org, right? : TLS is required, but was not offered by host mail.both.org[45.20.209.41] Normally I would send mail that doesn't need to be read by the entire list in a private reply, but... well, see above. ___ 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 ___ 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 will check because I thought I had TLS up and working. Apparently not. How did you discover this? I will fix it as soon as possible. I need to get one of my hosts to fail. When I do that I will send the results from that as well. These two examples have the correct data from my DHCP server. From a working VM. Note that this originally had no ifcfg file and now has one that specifies DHCP (as opposed to "none") but no DNS entries. 192.168.0.52 is my internal name server. This VM uses a single bridged NIC and gets its network configuration from 192.168.0.52 rather than the VirtualBox virtual DHCP server. Note that /run/NetworkManager also contains a resolv.conf file. Some of my systems are pointed to that. I know that I need to get everything consistent no matter what else I do. ;-) [root@testvm1 ~]# resolvectl Global Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub Link 2 (enp0s3) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 192.168.0.52 DNS Servers: 192.168.0.52 8.8.8.8 8.8.4.4 DNS Domain: both.org ~. [root@testvm1 ~]# From a laptop that has always worked with systemd-resolved [root@sm-voyager etc]# ll /run/systemd/resolve total 8 drwx-- 2 systemd-resolve systemd-resolve 60 Feb 19 21:26 netif -rw-r--r-- 1 systemd-resolve systemd-resolve 655 Feb 19 21:26 resolv.conf -rw-r--r-- 1 systemd-resolve systemd-resolve 745 Feb 19 21:26 stub-resolv.conf [root@sm-voyager etc]# resolvectl Global Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub Link 2 (enp41s0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 192.168.0.52 DNS Servers: 192.168.0.52 8.8.8.8 8.8.4.4 DNS Domain: both.org Link 3 (wlp0s20f3) Current Scopes: none Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported [root@sm-voyager etc]# Thanks! -- * David P. Both, RHCE He/Him/His * www.both.org - My personal web site www.Linux-Databook.info - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * The value of any software lies in its usefulness not in its price. — Linus Torvalds * On Mon, 22 Feb 2021, Michael Catanzaro wrote: Date: Mon, 22 Feb 2021 15:47:22 From: Michael Catanzaro Reply-To: Development discussions related to Fedora To: David Both Cc: Development discussions related to Fedora , Steve Dickson Subject: Re: Don't update to the latest f33! On Mon, Feb 22, 2021 at 1:45 pm, David Both wrote: Do you have any suggestions? Run 'resolvectl' and post the output so we can see what your configuration is. I hinted at this in my previous mail but it seems I didn't explicitly ask you to post what it outputs. Please post it so we can see what has happened. (Also: upgrade your mail server to support TLS!) ___ 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 ___ 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!
So here is my plan.
Over the next few days I plan to use one or more VMs to test various
configurations using systemd-resolved to see which ones work and which do not.
Then we should be
able to track down why.
Do you have any suggestions?
Thanks.
--
*
David P. Both, RHCE
He/Him/His
*
www.both.org - My personal web site
www.Linux-Databook.info - Home of the DataBook for Linux
DataBook is a Registered Trademark of David Both
*
The value of any software lies in its usefulness
not in its price.
— Linus Torvalds
*
On Thu, 18 Feb 2021, Michael Catanzaro wrote:
Date: Thu, 18 Feb 2021 10:46:53
From: Michael Catanzaro
Reply-To: Development discussions related to Fedora
To: David Both
Cc: Development discussions related to Fedora ,
Steve Dickson
Subject: Re: Don't update to the latest f33!
On Thu, Feb 18, 2021 at 10:39 am, David Both wrote:
Ok, so I manage my network using DHCP on an internal server for all except
that server and my Linux firewall/router which both use a complete static
configuration for networking.
My DHCP server does provide DNS resolver information which, in order, is
my internal BIND server (same physical server host), 8.8.8.8, and 8.8.4.4.
But my hosts were not getting that information. I think the difference
between the working and failing hosts is possibly (experiments required)
left-over ifcfg files some of which specified DHCP but also name servers
while others specified DHCP but did not specify name servers, as well as
some newer hosts that do not have any ifcfg files. I have also noticed
that ifcfg files are no longer created automatically but work when
created. I missed that information also.
OK, so DHCP is not working somehow. Are you running NetworkManager? That is
my #1 guess right now, because without NetworkManager, you have no easy way
to get DNS configuration from DHCP to systemd-resolved. systemd-resolved
doesn't configure itself: that's the responsibility of a higher-level
management layer, usually NetworkManager, or alternatively systemd-networkd.
You can configure it manually with your own scripts if you're really
hardcore. But if you have disabled NetworkManager, then my recommendation
would be to disable systemd-resolved as well. If you *are* running
NetworkManager, then unfortunately we're probably going to need to debug
NetworkManager to figure out why the configuration from DHCP is getting
dropped. I don't know how to help with that, but that also seems unlikely
because nobody has reported bugs related to that as far as I know.
If you are running NetworkManager, here are some more general troubleshooting
steps that I had typed up to send before reading the above:
The most important thing to do is to check the output of 'resolvectl' and
look for anything suspicious. Ideally the DNS server you want things going to
will be listed under each desired network interface with +DefaultRoute set.
Hopefully something will be obviously wrong there, but if not, you can post
the output of 'resolvectl' here for us to take a look.
To ensure systemd-resolved's configuration doesn't get bypassed, you'll also
want to ensure you're running Fedora's new default configuration, which you
should be, since users should be automatically upgraded. But just in case,
it's good to check:
* Ensure NetworkManager is running ('systemctl status
NetworkManager.service'). If not, you're on your own and should consider
disabling systemd-resolved since it's not worth trying to use manually.
* Ensure systemd-resolved is running: 'systemctl status
systemd-resolved.service'
* Ensure /etc/resolv.conf is symlinked to
/run/systemd/resolve/stub-resolv.conf (this ensures anything reading it
manually gets pointed to systemd-resolved's IP address, 127.0.0.53)
* Ensure the hosts line in /etc/nsswitch.conf looks like this: files
mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] myhostname dns
(Remember to never edit /etc/nsswitch.conf manually, instead edit
/etc/authselect/user-nsswitch.conf and then run 'sudo authselect
apply-changes'.)
___
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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
I do not think this is a cloud-init problem. None of my hosts are in any cloud and most failed to resolve after upgrade to F33. Only after reverting to nss resolver by disabling systemd-resolved did the problem disappear. I did investigate the new resolver but none of the options worked no matter which one I linked /etc/resolv.conf to. They all failed in one way or another. To me, this seems to be a problem with systemd-resolved not some external service. Thanks! -- * David P. Both, RHCE He/Him/His * www.both.org - My personal web site www.Linux-Databook.info - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * The value of any software lies in its usefulness not in its price. — Linus Torvalds * On Mon, 22 Feb 2021, Michael Catanzaro wrote: Date: Mon, 22 Feb 2021 10:45:58 From: Michael Catanzaro Reply-To: Development discussions related to Fedora To: Development discussions related to Fedora Cc: Tadej Janež Subject: Re: systemd-resolved fallback DNS servers: usability vs. GDPR On Mon, Feb 22, 2021 at 12:05 pm, Tomasz Torcz wrote: 3) Configure DNS resolvers if you want to use DNS. Or dig deeper: why cloud-init disabled DNS on your installation? I'm pretty sure cloud-init just doesn't know how to configure systemd-resolved at all. So I suspect this is a cloud-init bug. See: https://pagure.io/fedora-server/issue/10. I have no strong opinion on whether the fallback should have been removed or not. The fallback was only hiding the real problem, after all. ___ 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 ___ 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! (fwd)
Thanks for this information. See in-line.
--
*
David P. Both, RHCE
He/Him/His
*
www.both.org - My personal web site
www.Linux-Databook.info - Home of the DataBook for Linux
DataBook is a Registered Trademark of David Both
*
The value of any software lies in its usefulness
not in its price.
— Linus Torvalds
*
On Thu, 18 Feb 2021, Michael Catanzaro wrote:
Date: Thu, 18 Feb 2021 10:46:53
From: Michael Catanzaro
Reply-To: Development discussions related to Fedora
To: David Both
Cc: Development discussions related to Fedora
,
Steve Dickson
Subject: Re: Don't update to the latest f33!
On Thu, Feb 18, 2021 at 10:39 am, David Both wrote:
Ok, so I manage my network using DHCP on an internal server for all except
that server and my Linux firewall/router which both use a complete static
configuration for networking.
My DHCP server does provide DNS resolver information which, in order, is
my internal BIND server (same physical server host), 8.8.8.8, and 8.8.4.4.
But my hosts were not getting that information. I think the difference
between the working and failing hosts is possibly (experiments required)
left-over ifcfg files some of which specified DHCP but also name servers
while others specified DHCP but did not specify name servers, as well as
some newer hosts that do not have any ifcfg files. I have also noticed
that ifcfg files are no longer created automatically but work when
created. I missed that information also.
OK, so DHCP is not working somehow. Are you running NetworkManager? That is
my #1 guess right now, because without NetworkManager, you have no easy way
to get DNS configuration from DHCP to systemd-resolved. systemd-resolved
doesn't configure itself: that's the responsibility of a higher-level
management layer, usually NetworkManager, or alternatively systemd-networkd.
You can configure it manually with your own scripts if you're really
hardcore. But if you have disabled NetworkManager, then my recommendation
would be to disable systemd-resolved as well. If you *are* running
NetworkManager, then unfortunately we're probably going to need to debug
NetworkManager to figure out why the configuration from DHCP is getting
dropped. I don't know how to help with that, but that also seems unlikely
because nobody has reported bugs related to that as far as I know.
If you are running NetworkManager, here are some more general
troubleshooting steps that I had typed up to send before reading the above:
I am running NetworkManager. I had disabled and stopped systemd-resolved on GP
after other hosts failed. After starting systemd-resolved everything looks to
be configured correctly:
[root@david ~]# resolvectl
Global
Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: foreign
DNS Servers: 192.168.0.52
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: both.org
Link 2 (enp0s31f6)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
DNS Servers: 192.168.0.52 8.8.8.8 8.8.4.4
DNS Domain: both.org ~.
Link 3 (vboxnet0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
But everything is working and has been on my primary workstation - which is why
I did not see this until I upgraded to F33 on other hosts. This host has no
ifcfg file.
I really need to experiment with this a bit. I will get back to you with my
results.
The most important thing to do is to check the output of 'resolvectl' and
look for anything suspicious. Ideally the DNS server you want things going
to will be listed under each desired network interface with +DefaultRoute
set. Hopefully something will be obviously wrong there, but if not, you can
post the output of 'resolvectl' here for us to take a look.
To ensure systemd-resolved's configuration doesn't get bypassed, you'll also
want to ensure you're running Fedora's new default configuration, which you
should be, since users should be automatically upgraded. But just in case,
it's good to check:
* Ensure NetworkManager is running ('systemctl status
NetworkManager.service'). If not, you're on your own and should consider
disabling systemd-resolved since it's not worth trying to use manually.
* Ensure systemd-resolved is running: 'systemctl status
systemd-resolved.service'
* Ensure /etc/resolv.conf is symlinked to
/run/systemd/resolve/stub-resolv.conf (this ensures anything reading it
manually gets pointed to systemd-resolved's IP address, 127.0.0.53)
* Ensure the hosts line in /etc
Re: Don't update to the latest f33!
;-) Response to earlier email: Thanks for the informative response Michael. I plan to read the content at those links in some depth. What I see so far does describe how name resolution now works and hints at why this is being done. Even had I read that it would not have prepared me for the possibility that the resolver would fail so completely in my relatively simple environment. Nor does it suggest how to return to a working resolver, either by returning to either nss option or correcting the systemd-resolved configuration -- and I still do not know how to approach that. I will continue to read. I guess that there are more places to get the information than I have previously been aware, but that still doesn't mean that most users will find it or understand it. I read stuff like this all the time but totally missed that. I can't imagine how most regular users and busy-to-their-eyeballs sysadmins will run across this and then know how to connect the dots between change and symptom. It took me a good bit of experimenting to figure out that /etc/resolv.conf is now just a link and the specific link used defines how name resolution actually works. My usual procedure with resolver problems is to cat /etc/resolv.conf but that does not tell me it is a link. I only realized that a major change had been made by doing a long listing while looking for old or conflicting files. Then I was on track to figure it out. I think your statement about name resolution being bad would only be true if I were part of one of the edge cases for which the old way failed. This is from a user standpoint where "all is good until it fails" rather than a developer standpoint where "it suck behind the scenes so it needs fixed even if it breaks things for a while." I do like most of what systemd does. I do think that perhaps better testing of possible failure modes and circumstances as well as communication of possible problems, their symptoms, known fixes, and circumventions would help. And it needs to be obvious to anyone looking for that information. Response to this email: Ok, so I manage my network using DHCP on an internal server for all except that server and my Linux firewall/router which both use a complete static configuration for networking. My DHCP server does provide DNS resolver information which, in order, is my internal BIND server (same physical server host), 8.8.8.8, and 8.8.4.4. But my hosts were not getting that information. I think the difference between the working and failing hosts is possibly (experiments required) left-over ifcfg files some of which specified DHCP but also name servers while others specified DHCP but did not specify name servers, as well as some newer hosts that do not have any ifcfg files. I have also noticed that ifcfg files are no longer created automatically but work when created. I missed that information also. I am willing to help with this. Thanks! -- * David P. Both, RHCE He/Him/His * www.both.org - My personal web site www.Linux-Databook.info - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * The value of any software lies in its usefulness not in its price. — Linus Torvalds * On Thu, 18 Feb 2021, Michael Catanzaro wrote: Date: Thu, 18 Feb 2021 09:34:52 From: Michael Catanzaro Reply-To: Development discussions related to Fedora To: David Both , Development discussions related to Fedora Cc: Steve Dickson Subject: Re: Don't update to the latest f33! On Thu, Feb 18, 2021 at 8:30 am, Michael Catanzaro wrote: We don't set DNS there intentionally because it eliminates any benefit of using split DNS. Your static global DNS= configuration in resolved.conf is used for *every* request, *in addition* to per-link DNS configuration. So if you have per-link DNS configuration from DHCP -- which almost everybody will except in cloud environments like this -- then you would wind up with two parallel DNS queries going out for every lookup, where whichever finishes first wins. That's not a good default. Well I should clarify: it *is* a good default for cloud or server environments where it is guaranteed that DHCP will not provide any DNS configuration and you just need a simple, static DNS config. So if the cloud provider inserted its DNS config here, that was probably the right thing to do. It just needs to not use commas. :P ___ 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_guid
Re: Don't update to the latest f33!
I do not believe that this is just about lack of fallback and the silent fail. Although that is probably true, it is also about the "silent" change from nss to systemd-resolved and THEN the silent change to zero default fallback. There was a series of silent changes that brought this failure to light. Not only do I not see the need for a change to a new name service client, the lack of information about the changeover to users outside this list is a terrible example for its lack of communication. Although I try to read the release notes I sometimes seem to miss things or fail to read them altogether. I am not sure I know how that bit can be fixed but I think it is an organic part of this failure. Perhaps such deep and basic changes should be mentioned in the release announcements along with a BOLO for related failures. Do not misunderstand me. I really like systemd overall. Perhaps you have seen my series of articles about various systemd tools at Opensource.com. But this bit does seem a little extreme. I think I have an idea for a new article. "The layers of Linux." ;-) Anyway, my personal approach to this is a return to nss by disabling systemd-resolved until the problem is well and truly fixed. And my name resolution is now working exactly as it should. My remaining question is, where can I find a complete description of systemd-resolved and what its design goals are? Thanks! -- * David P. Both, RHCE He/Him/His * www.both.org - My personal web site www.Linux-Databook.info - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * The value of any software lies in its usefulness not in its price. — Linus Torvalds * On Thu, 18 Feb 2021, Ed Greshko wrote: Date: Wed, 17 Feb 2021 21:11:12 From: Ed Greshko Reply-To: Development discussions related to Fedora To: Steve Dickson , Development discussions related to Fedora Subject: 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? ___ 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!
This situation is due to the change from the old resolver to the new systemd-resolved. I have a page on my technical web site that describes the problem and the circumvention. http://www.linux-databook.info/?page_id=5951 This does not, erm, resolve the problem but it does get you back to a working resover. I hope this helps. -- * David P. Both, RHCE He/Him/His * www.both.org - My personal web site www.Linux-Databook.info - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * The value of any software lies in its usefulness not in its price. — Linus Torvalds * On Mon, 15 Feb 2021, Steve Dickson wrote: Date: Mon, 15 Feb 2021 17:40:10 From: Steve Dickson Reply-To: Development discussions related to Fedora To: devel@lists.fedoraproject.org Subject: Don't update to the latest f33! Hello, I just updated to latest Fedora 33 and I no longer have any DNS name solution. The network is up... but... $ ping www.yahoo.com ping: www.yahoo.com: Name or service not known I changed nothing! How would be the bet way to debug this??? steved. ___ 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 ___ 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: heads up: nss 3.59 breaks firefox add-ons
Ok, I am the n00b here but I have experienced some nss related problems since upgrading to Fedora 33. I found that the systemd-resolved service interferes with or corrupts previously normal nss functions, most related. to the resolver. For example, when some hosts used systemd-resolved and others used nss, dig and nslookup don't resolve properly. Sometmes ping does work. Sometimes extrernal lookups work and internals don't and sometimes the other way round. But the exact symptom can depend on which type of host you are working with. I stopped and disabled systemd-resolved and all of those problems disappeared. Firefox now works fine for me as do all my network services. http://www.linux-databook.info/?page_id=5951 Thanks -- * David P. Both, RHCE He/Him/His * www.both.org - My personal web site www.Linux-Databook.info - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * The value of any software lies in its usefulness not in its price. — Linus Torvalds * On Sat, 19 Dec 2020, Kevin Fenzi wrote: Date: Sat, 19 Dec 2020 12:32:28 -0800 From: Kevin Fenzi Reply-To: Development discussions related to Fedora To: Development discussions related to Fedora Subject: Re: heads up: nss 3.59 breaks firefox add-ons On Sat, Dec 19, 2020 at 05:33:57PM +0100, Marius Schwarz wrote: Am 18.12.20 um 15:33 schrieb James Szinger: I see nss.x86_64 3.59.0-3.fc33 in today’s updates. Is this fixed or are there going to be a lot of unhappy Firefox users? The bug is still open. Can someone pls lush this into rawhide? There is only -2 WITH the SHA-1 blockade. firefox-84.0-6 in rawhide (the latest package available) has enabled it's bundled nss that doesn't do that check. ;( https://koji.fedoraproject.org/koji/buildinfo?buildID=1659741 So, upgrading to that should work around the problem. Of course it causes other problems, like firefox exposing all the nss provides. The best workaround for now would be firefox adding some code to exempt itself from the sha1 check for now and resume building against the system nss and the system nss re-enabling the sha1 check. The real solution is of course mozilla updaing add-ons to not use sha1. ;) kevin ___ 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
