Re: convert everything to rpmautospec?
I think missing easy to use documentation is the most missing part of current rpmautospec package. Manual page does not exist, readme is in wrong package. I have proposed to be able to include extra section just for changelog. I do not remember which exactly way was merged instead, there should be something use-able. But is not easy to find. Currently just first line is used as changelog entry. It might be skipped with special tag in commit, but that is nowhere to be found in documentation present with the package. I think simple tags could be used to mark noteworthy changes only for releases. I think autospec is great, as it especially makes longer term pull requests easy to merge. Avoiding stupid conflict with changelog bumps. But I think there is still a lot to improve in usability part. For many packages without significant function changes it is just fine. Significant changes should be mentioned in updates or linked bugs, rather than commit messages. But problem is rawhide automatic updates contains just changelog and not really anything useful. I find it not easy to fill this part. If the project contains changelog, I would recommend it as part of the package %doc files. It takes extra work to maintain one however. I would find it nice to generate nice looking update messages from commit, but current implementation is not sufficient IMO. Nice looking references to upstream issues or release notes would be nice too. On 09. 04. 24 10:04, Remi Collet wrote: Le 07/04/2024 à 17:15, Zbigniew Jędrzejewski-Szmek a écrit : Thus, the proposal: - new packages MUST use rpmautospec - packagers SHOULD convert their packages - provenpackagers MAY convert existing packages (e.g. when they want to push some fix or separately from other work) - people submitting pull requests against src.fp.o MAY also include a conversion in the pull request and packagers SHOULD merge it. Big -1 to all git log IS NOT a package changelog Read https://keepachangelog.com/en/1.1.0/ Remi -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- ___ 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: convert everything to rpmautospec?
Before any such ideas continue, I think rpmautospec should have more decent documentation. Unfortunately it does not have even manual page for rpmautospec command, core of its functionality. I find that missing. While I think rpmautospec is great idea, I do not think it is ready universally. Correct me if I am wrong, but I think there is no way to make rightmost bump as done by rpmdev-bumpspec -r. We use it a lot for RHEL minor version updates. But there does not seem to be a way to mark some commit, after which only rightmost bumps should occur. While I have intentionaly converted many my packages, I am keeping some more complicated intentionally the old way. Especially because it allows me to rebuild those packages for CentOS/RHEL and compare their functionality. Is there full support for rpmautospec in COPR for example? I don't know. I have not seen it mentioned in docs. It seems too early for any MUST related with this. On 07. 04. 24 17:15, Zbigniew Jędrzejewski-Szmek wrote: Hi everyone, I'm revisting the topic of rpmautospec because I was doing some work on various packages, and it's annoying that some packages are using rpmautospec and others are not. All my packages have been converted, so in day-to-day work, I don't even think about %changelog. When working with other packages, I'll forget to update the Relase and/or %changelog. Today I was rebasing some pull requests in pagure, and the _only_ conflicts that I had were about Release and %changelog. I think it's time to switch to rpmautospec completely. Thus, the proposal: - new packages MUST use rpmautospec I think this still be SHOULD. AFAIK rpmfusion does not work with rpmautospec and other distributions may not as well. Forcing this to everyone does not seem reasonable to me, although I would recommend it everywhere where possible. - packagers SHOULD convert their packages - provenpackagers MAY convert existing packages (e.g. when they want to push some fix or separately from other work) No, please don't. provenpackagers should not make significant changes to packages without communication with their maintainers. rpmautospec conversion requires change of workflow and should never be done without maintainer agreement. PR are okay, but not direct commits. - people submitting pull requests against src.fp.o MAY also include a conversion in the pull request and packagers SHOULD merge it. (FTR, 'rpmautospec convert' does the conversion, incl. the commit to dist-git. Manual conversion should not be used.) Zbyszek This again should be documented in installed package. Sadly it does not contain even README doc file with very basic information. Or it does in python3-rpmautospec, which is where I doubt those information is usually expected. I think easy to find documentation with skip changelog [1] instructions should be easy to find on the installed system. I do not think it is. 1. https://fedora-infra.github.io/rpmautospec-docs/autochangelog.html#skipping-changelog-entries -- Petr Menšík Software Engineer, RHEL Red Hat,http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- ___ 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: xz backdoor
Good point. Check testing it is actually expected unix socket would be
quite nice. Especially when the file sd-daemon.c implements
sd_is_socket_unix function, but never uses it itself. libsystemd
verifies this using socket_address_parse_unix or
socket_address_parse_vsock in pid_notify_with_fds_internal.
All in all, I don't see any good reason, why shared functionality should
be copy to every project. That is the worst long-term idea
hindering maintenance of shared functionality. I have been part of
project having a lot of copy It was quick to write, but hard to
maintain afterwards. Shared libraries make sense even when they are
small, especially when that small part is needed often. Which is exactly
the case of sd_notify variants.
Reusing easy to read and with no dependencies except libc is still much
better idea.
I think projects having bundled implementation should mark it somehow in
their packages. Something like Provides: bundled(systemd/sd_notify) ? Or
bundled(systemd-libs) ? I think such functionality should be searchable
somehow in the repository. I think we should define how it should be
marked in case of inline copy. bundled(systemd) seems a bit too strong,
but according to Bundling specification in packaging guidelines [1].
I like idea in marked comment [2]. It might get even
launcher-independent way of daemon to signal its readiness. We do not
support alternatives to systemd, but I see no reason to prevent upstream
project to reuse the same way for any alternative, which may use
readiness signal from the service. Other distributions still allow other
combinations. It would be much better to support alternative process
managers from shared library than in each project itself.
PS: once again comments are marked as spam, when they simply disagree
with systemd team stance, but are otherwise to the point. That
unfortunately makes no constructive discussion possible on systemd
upstream issues.
1. https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling
2. https://github.com/systemd/systemd/issues/32028#issuecomment-2034099384
On 02. 04. 24 20:05, Kevin Kofler via devel wrote:
Lennart Poettering wrote:
It *literally* is just sending a text string "READY=1" in an AF_UNIX
datagram to a socket whose path is provided to you in the
$NOTIFY_SOCKET env var.
I see so many ways one can get this wrong. E.g., using some abstraction for
the socket write that can also write to regular files, without checking that
"$NOTIFY_SOCKET" is really a socket (or checking it with a TOCTOU
vulnerability), introducing an arbitrary file overwrite vulnerability.
Kevin Kofler
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
--
___
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: xz backdoor
On 02. 04. 24 14:17, Lennart Poettering wrote: On Di, 02.04.24 14:04, Petr Menšík (pemen...@redhat.com) wrote: I am not convinced dlopen will it make secure in the end. I am not sure this is a good solution. dlopen makes those dependencies non-obvious from packaging side and non-visible from ldd or similar checking programs. I think it should be considered to offer more than one dynamic library. It was considered. To the point that a decade ago, libsystemd originally was split up. But it was awful to maintain. But let's not repeat this discussion here. Read up here: https://github.com/systemd/systemd/issues/32028 Oh, I hate the way discussions are moderated at systemd upstream. I would prefer to discuss here. It appears you do not want to make it simple to use just notify lib. But luckily it does not have to be maintained by systemd team. Yes, the protocol is trivial. But it still needs to handle conditions when it does not run under systemd. When it does, but error occurs. While number of lines required are very low, it would have need to be duplicated many times in many services. More or less the same code. It is apparent either everyone will implement it themselves or systemd-independent project needs to provide just limited sd_notify shared library. At least it needs documentation. Indication it implements sd_notify in some way is nice to have bonus. For example most services I maintain links to libsystemd just because it wants sd_notify calls in their services. Without any proof I would expect quite many services would have similar problem. Could be perhaps libsystemd broken into few more dynamic linked libraries? I somehow doubt any kind of compression is needed for sd_notify calls. Could be even smaller library libsystemd-notify linked from libsystemd, which would allow end applications to explicitly declare they need more limited set of functions? Why link? I'd really just suggest people to implement the trivial client on their own. It's a trivial protocol for a reason: so that people can implement it natively in their language and framwork without bothering with our upstream libsystemd. Because the number of applications solving the same problem is rather high. It is not issue to be solved in about 3 projects. There are dozens of daemons, which should implement the same functionality. Common base even with a tiny library still makes a sense to me. Especially if most of them linked unnecessarily to libsystemd and thought that was the best option. use libsystemd if you link against it anways and hack in C, or if you really don't are about the extra dep for a single function, but otherwise, why would you use the lib? It *literally* is just sending a text string "READY=1" in an AF_UNIX datagram to a socket whose path is provided to you in the $NOTIFY_SOCKET env var. Anyone with a moderate understanding of UNIX APIs should be able to hack that up in a a few lines of code. It's a protocol I can summarize and explain in *one* frickin' sentence. Yes, I admit, it is simple line oriented protocol. But you need to get notify socket path, handle failures when opening it. You need to know what to write there, so also documentation is needed. Man page for sd_notify is nice. Implementation of sd_notifyf() function would not be trivial. While it is not difficult to get right, it does not make sense to have over 15 different implementations, when it can share the same code. When you want to include also error messages, it certainly becomes more than few lines. Function pid_notify_with_fds_internal from ./src/libsystemd/sd-daemon/sd-daemon.c certainly is not just few lines, as suggested. Should I ask why, if not necessary? It seems whole sd-daemon.c has 775 lines, which would be nice to have separate library. Things missing are some helpers. Socket activation is not as needed as core sd_notify, but might be a good addition. Still needs just environment and pointer to ints. No unwanted dependencies, I think that would make a nice standalone shared library. It provides everything I would need in common service. sshd upstream understood this btw: https://bugzilla.mindrot.org/show_bug.cgi?id=2641 Lennart -- Lennart Poettering, Berlin I think they preferred having fast fix over having long-term sustainable solution. I haven't seen offer to provide libsystemd-notify library with minimal dependencies, which they kindly refused. They preferred bundled code over systemd bloat in comment #13. I haven't seen bloat-less library considered in the bug, but might have missed it? The question is, how should be the separate library called. libsystem_notify? Ideas for a better name? Compat include header to make it otherwise unmodified with libsystemd would be nice as well. -- Petr Menšík Software Engineer, RHEL Red Hat,http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- ___ devel ma
Re: xz backdoor
I am not convinced dlopen will it make secure in the end. I am not sure
this is a good solution. dlopen makes those dependencies non-obvious
from packaging side and non-visible from ldd or similar checking programs.
I think it should be considered to offer more than one dynamic library.
For example most services I maintain links to libsystemd just because it
wants sd_notify calls in their services. Without any proof I would
expect quite many services would have similar problem. Could be perhaps
libsystemd broken into few more dynamic linked libraries? I somehow
doubt any kind of compression is needed for sd_notify calls.
Could be even smaller library libsystemd-notify linked from libsystemd,
which would allow end applications to explicitly declare they need more
limited set of functions?
Is there now relatively simple way to analyze packages depending on
libsystemd, how rich functionality they need to use? I somehow doubt
many packages need explicit work with journal. If they do, okay, use
more heavy-weight library. But quite alot of programs needs just
sd_notify* and sd_listen* calls, maybe with addition to sd_booted.
The best example is sshd itself, which plays important role in this
story. For a very good reason.
$ objdump -T /usr/sbin/sshd | grep sd_
DF *UND* (LIBSYSTEMD_209) sd_notify
Less code linked into libraries means less code needs to be analysed for
malware or security scans. It also allows an user to explicitly declare
just limited functions should be available.
I have made crude script getting calls used on my own system. While
there is larger group with also journal involved, I think number of
packages using just sd_notify, sd_listen or similar is not unimportant.
$ dnf repoquery --whatdepends systemd-libs --alldeps | sort -u | while
read PKG; do rpm -q "$PKG" >/dev/null && echo "$PKG"; done | tee installed
$ cat installed | while read PKG; do rpm -ql "$PKG" | grep -E
'^(/usr/s?bin/|/usr/lib64/|/usr/libexec)' | while read BIN; do objdump
-T "$BIN" 2>/dev/null | grep -E ' (sd|udev)_' | sed -e
's/[0-9a-f]\+\s*DF\s*\(\*UND\*\|.text\)\s*[0-9a-f]\+\s*//' -e "s|^|$PKG
${BIN}: |" ; done; done | tee libsystemd-calls.txt
Attached the results in libsystemd-calls.txt attachment.
I would prefer ability to explicitly declare I want just limited
functionality for cooperating with systemd, without any obscure dlopen
calls. They are even more suspicious in low-level library and I don't
think they should be used to solve resource limitations. They make it
more difficult to discover actually used dependencies by static analysis
tools. udev has already own library, perhaps notify and bus should be
able to use with a more lightweight library too?
Regards,
Petr
(edit: attached compressed list.)
On 30. 03. 24 19:43, Zbigniew Jędrzejewski-Szmek wrote:
libsystemd is linked to compression libraries primarly because those
compressors
are options for journald files, and we generally want to mainain the property
that all journal files from the past, as well as journal files from other
systems, can be read by later journal code.
(bzip2 is an exception here. It is only used by systemd-importd and related
tools, so libsystemd was never linked to it, IIRC.)
In recent systemd versions, dlopen is used for various compression libraries and
other libraries, so they'll be opportunistically loaded if needed, effectively
making those dependencies optional at runtime.
Conversions to use dlopen require a bit of boilerplate code and make the code
less readable, so we only would to them if there was a reason. Usually, this
reason was size and/or the dependency tree. Compression libraries are very small
and have no dependencies, so it wasn't considered important to use dlopen for
them. But now that there's a new motivation, as mentioned elsewhere in the
thread, we'll load pretty much all dependencies of libsystemd via dlopen.
Zbyszek
Petr Menšík
Software Engineer, RHEL
Red Hat,http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
libsystemd-calls.txt.gz
Description: application/gzip
--
___
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: cloud-init switching to udhcpc
I am dhcpcd maintainer and okay, dhcpcd is not bad choice. But its maintenance might fall into our team in RHEL. I am interested why two DHCP clients are required inside a single tool. Why it could not use NetworkManager in both times, but with some different settings? Maybe alternative service? If there is missing ability to change behaviour, it may make sense to fix just that. Instead of keeping another client maintained. Do we support any kind of images, which would not have Network Manager present? Was it already evaluated by someone from Network Manager maintainers, whether it would be possible reuse NM both times? If changes would be required, how significant? Maybe it were already ruled out for a good reason. I haven't found any discussion about that topic on cloud-init upstream. On 06. 02. 24 21:04, Major Hayden wrote: On Tue, Feb 6, 2024, at 13:56, Petr Menšík wrote: I think this is stupid anyway. Why does cloud-init need 2 separate DHCP clients anyway? Can we gather what exactly they use it for and why alternative dhcp client is required? It looks like a small, basic, DHCP client is needed during the early boot just to get on the network to reach the metadata service. That would be before NetworkManager gets involved. Yes, I understand that. But I don't understand why. I don't work with cloud instances, so forgive my naivety. NetworkManager can obtain address and configure interface to a working state. It seems we want to: - prevent dispatches from running during metadata configuration phase - not reaching network.target - not using NetworkManager.service, but stripped down alternative Is it different, because DBus is not yet running at that time? Could be just alternative configuration used to not trigger unwanted parts? If we had just NetworkManager-metadata.service, using alternate state directory as well, couldn't it provide similar functionality as additional dhcpcd/dhclient? Just with few configuration files in addition, instead of additional compiled package(s)? Stephen Gallagher pointed out that ELN doesn't have busybox, but it does have dhcpcd, and that should work fine. I've reverted the switch to udhcpcd and I'm waiting on upstream cloud-init to have a new release with the recently added dhcpcd support. Are there simple steps, where I can as a dhcpcd maintainer try, how exactly is dhcpcd used during instance configuration process? Can I prepare VM image using mentioned metadata? Do we have any documentation on this topic for Fedora or RHEL at least? Can you point me to some documentation, how to test it? Best Regards, Petr -- Petr Menšík Software Engineer, RHEL Red Hat,http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- ___ 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: cloud-init switching to udhcpc
Hello Major, I think this is stupid anyway. Why does cloud-init need 2 separate DHCP clients anyway? Can we gather what exactly they use it for and why alternative dhcp client is required? It seems to me NetworkManager should be able to use just different configuration for "pre-connection" phase. But anyway, it is connected by that time. Pretending alternative dhcp client makes it "off-line" is ridiculous. It might not be reaching network.target with it, but still is connected. It would be great, if Network Manager could be used in both phases. Could for example --configure-and-quit with custom --config and --state-file provide basic configuration needed before correct network start? Were that even considered? Regards, Petr On 30. 01. 24 17:58, Major Hayden wrote: Hey there, For those of you who use Fedora often on public cloud providers where cloud-init handles the initial configuration, there's a change coming for the very early DHCP request during the boot. ☁️ As reported in BZ 2247055[0], the existing dhclient binary comes from ISC's dhcp and it stopped being maintained upstream in 2022. Cloud-init uses dhclient during the very early setup process to get an IP address for retrieving instance metadata. Busybox provides udhcpc[1] and it works well for cloud-init's early boot needs. Support for udhcpc was also added to cloud-init. I've tested this on AWS and it's working well. You shouldn't notice a difference when launching a cloud instance after this change, but I wanted to ensure everyone was aware it was coming. Have a great rest of the week! [0] https://bugzilla.redhat.com/show_bug.cgi?id=2247055 [1] https://en.wikipedia.org/wiki/Udhcpc -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- ___ 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: dnsmasq default configuration changed
Thanks, that is exactly the message I wanted to tell. Perhaps I should keep corner cases to myself until someone actually hits them. It has clearly confused people and created unnecessary reactions. Conflict will arise only when configuration change done by administrator were not complete. On 16. 01. 24 10:18, Miroslav Lichvar wrote: On Mon, Jan 15, 2024 at 05:31:36PM +0100, Kevin Kofler via devel wrote: Petr Menšík wrote: Anyway, dnsmasq will listen by default on 127.0.0.1, as every standard resolver does. You can use listen-address=127.0.0.53 if you like, but then it will conflict with systemd-resolved. You just wrote that you make it listen by default on all interfaces, and then filter. If I understand it correctly, it will do that only if the configuration was modified (an additional interface was specified). The default configuration should work exactly as before. This means it will conflict over the port 53. They bind to different addresses by default. -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- ___ 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: dnsmasq default configuration changed
Please, Stephen, would you please read what I wrote, not what Kevin wrongly deducted? The change I made in dnsmasq does not conflict with systemd-resolved in default configuration or if configured correctly. I have wrote scenario, when it can conflict and how to fix it. So no, there is no need to revert my change. If it is, *PLEASE* report it with exact step to reproduce. I have tested those changes do not cause regressions. If you (or anyone else) know something I have missed, I need much more precise steps than those below to fix it. I would suggest everyone to try that change in rawhide actually, verify what is listening on and whether it does conflict with anything. I use "lsof -np $(pidof dnsmasq)" command for quick checks. On 15. 01. 24 20:04, Stephen Gallagher wrote: On Mon, Jan 15, 2024 at 11:32 AM Kevin Kofler via devel wrote: Petr Menšík wrote: systemd-resolved is unfortunately known to broken. [snip] Dnsmasq does not break DNSSEC, systemd-resolved does. [snip] Unfortunately broken are clients having systemd-resolved enabled. How exactly is it broken? If you refer to: https://github.com/systemd/systemd/issues/25676 fixes for that are finally coming in now (as of 3 weeks ago). I have reported issues known to me: https://github.com/systemd/systemd/issues?q=is%3Aopen+is%3Aissue+author%3Apemensik+label%3Aresolve+ https://bugzilla.redhat.com/buglist.cgi?quicksearch=reporter%3Apemensik%40redhat.com%20component%3Asystemd_id=13235040 There are some others, which I consider important enough. If it works for you, good for you. It does not work well for others, I do not want to discuss it here. This thread is about dnsmasq only and I would like to focus to that only. I would recommend having systemd-resolved forwarded to dnsmasq, which can then be forwarded further. If you think dnsmasq should replace systemd-resolved by default, then please propose that through the Changes process, which will also ensure the glibc resolver, NetworkManager, and the like get configured properly for it. Simply shipping dnsmasq with a default configuration that conflicts with systemd-resolved is not a productive approach. If systemd-resolved is really broken, then it either needs to be fixed or replaced. The former needs to be handled through systemd upstream, the latter through the Fedora Changes process. Yes, I plan to propose changes to default system wide resolver, because long reported bugs to systemd-resolved were mostly ignored. For years. But the solution I want to propose is not replacing it with dnsmasq. I am dnsmasq maintainer, I know it has own issues. In my opinion it is less broken, but not perfect. We are preparing different solution, which should be better. But it is not yet ready and therefore there is no Fedora Change filled. We fill create that once we are sure it brings features without causing regressions. But this change should create conflict with systemd-resolved only in case it was improperly configured. But the default configuration you ship will conflict. Anyway, dnsmasq will listen by default on 127.0.0.1, as every standard resolver does. You can use listen-address=127.0.0.53 if you like, but then it will conflict with systemd-resolved. You just wrote that you make it listen by default on all interfaces, and then filter. This means it will conflict over the port 53. That said, listening on the lo interface only will also conflict with systemd-resolved or any other local resolver, so you are probably right that your change does not change much for the default configuration, it just makes it harder (more settings to change) to set up coexistence. 127.0.0.53 is unfortunately not an independent interface, it is still the lo interface. Based on my reading of this thread, this change is going to break the default configuration and needs to be reverted immediately. Petr, please file a Change Proposal for Fedora *41*. You have missed the deadline for F40 System-Wide Changes (Dec. 26th) and this is absolutely NOT a self-contained Change. I am sorry my intention were not understood correctly. Miroslav already mentioned that.We will fill System-Wide Change, but this change does not need it. If it breaks something, please use bug #2258062 to report details or create a new one for rawhide. But reproducible details are needed, not just assumptions. Cheers, Petr PS: I consider it rude to be commented on issue closed for discussion, especially if the comment is misleading and false. -- Petr Menšík Software Engineer, RHEL Red Hat,http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- ___ 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 Archiv
Re: dnsmasq default configuration changed
systemd-resolved is unfortunately known to broken. I would recommend having systemd-resolved forwarded to dnsmasq, which can then be forwarded further. Dnsmasq does not break DNSSEC, systemd-resolved does. But this change should create conflict with systemd-resolved only in case it was improperly configured. In all other cases, it should work independently on the same machine just fine. Anyway, dnsmasq will listen by default on 127.0.0.1, as every standard resolver does. You can use listen-address=127.0.0.53 if you like, but then it will conflict with systemd-resolved. On 14. 01. 24 1:57, Kevin Kofler via devel wrote: Petr Menšík wrote: That might create a regression in special case. If you are running by default systemd-resolved, it listens already on domain port on address 127.0.0.53 address. But if bind-interfaces or bind-dynamic is not used explicitly, dnsmasq will try to listen on wildcard address 0.0.0.0 and just filter incoming requests, accepting only those arriving on interface eth0. But if any service already listens on port domain, it will fail to listen on it and fail to start. But we run systemd-resolved by default these days, don't we? So making dnsmasq attempt by default to serve the same requests does not sound like a good idea to me. No, dnsmasq will serve addresses 127.0.0.1 and ::1. If you do not want it listening on wildcard address, please configure it explicitly by using bind-interfaces or bind-dynamic options. Otherwise make sure no other program listens on port 53 (domain), be it systemd-resolved, named, unbound or anything similar. On a server I administer for work, I have dnsmasq serving the DNS for an ocserv (OpenConnect) VPN, listening only on the VPN interface. Any request for a host not within the VPN network (coming in from clients with no or broken split DNS support, e.g., old GNU/Linux distros without systemd- resolved, or Windows, where the OpenConnect client is still unable to set up split DNS) is forwarded to systemd-resolved, which in turn forwards it to the upstream DNS from the datacenter. Relying instead on the filtering would not have worked exactly for the reason you describe above. But that server is not running Fedora anyway. Kevin Kofler -- Unfortunately broken are clients having systemd-resolved enabled. I would recommend to skip systemd-resolved stub and using resolv-file=/run/systemd/resolve/resolv.conf in such case. It would use servers configured by systemd-resolved, but without using broken port domain at address 127.0.0.53. Alternatively use server=127.0.0.54, which should not break incoming queries so much. Consider using unbound as a cache for other VPN clients. dnsmasq is great for its integration with DHCP server, but is targeted to use minimal resources. Unfortunately at cost of some design issues. Unbound is a high quality cache, while still relatively small compared to bind's named.service. Cheers, Petr -- Petr Menšík Software Engineer, RHEL Red Hat,http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_0x4931CA5B6C9FC5CB.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ 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
dnsmasq default configuration changed
Hello! I have just pushed a change, which modifies default configuration of dnsmasq package. I think it should not create any regressions, but it may happen in few special cases. What has changed: It is described in bug #2258062 [1]. It no longer contains in default configuration bind-interfaces and interface=lo options. Instead, it contains now local-service=host. Exact change is in PR #15 [2]. It should work exactly the same way. Except if you configure interface explicitly, for example by executing echo interface=eth0 > /etc/dnsmasq.d/iface.conf local-service=host will deactivate itself. It is active only when dnsmasq is otherwise unconfigured. When interface or listen-address option is used, it deactivates and behaves like commented out. That might create a regression in special case. If you are running by default systemd-resolved, it listens already on domain port on address 127.0.0.53 address. But if bind-interfaces or bind-dynamic is not used explicitly, dnsmasq will try to listen on wildcard address 0.0.0.0 and just filter incoming requests, accepting only those arriving on interface eth0. But if any service already listens on port domain, it will fail to listen on it and fail to start. Solution is simple: add your own explicit bind-interfaces, because it is not present by default. Use instead this: (echo bind-interfaces; echo interface=eth0) > /etc/dnsmasq.d/iface.conf There are some packages, which depends on dnsmasq in various way. libvirt or NetworkManager should not be affected, but won't hurt checking it. I would like to ask their maintainers depending on dnsmasq to check this change will not break their functionality and cause regressions. Use bug [1] to report problems found with this change, don't be afraid to set needinfo? on me. Unless some regression appears, I would like to backport this change also into Fedora 39 stable after two weeks without reported regressions. Thank you for reading it so far! Best Regards, Petr 1. https://bugzilla.redhat.com/show_bug.cgi?id=2258062 2. https://src.fedoraproject.org/rpms/dnsmasq/pull-request/15 -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_0x4931CA5B6C9FC5CB.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ 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: Dropping of sshd.socket unit
Wouldn't a relative simple change to fix this would be explicit TriggerLimitBurst=0 until some form of timed reactivation is implemented? Especially for sshd.socket that change would seem safer. It is not a big deal for sshd, it seems to be quite small anyway. Could simple [Unit] Restart=on-failure solve this issue instead? If it fails, this should be able to keep it up. Does it manifest itself a different way? On 03. 08. 23 11:29, Dmitry Belyavskiy wrote: Dear colleagues, I've pushed a fresh build of OpenSSH to rawhide. We decided to drop the sshd.socket unit from rawhide. We don't think it's worth going through the changes process, but would like to provide a heads-up. See the details in https://bugzilla.redhat.com/show_bug.cgi?id=2025716. -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: RFC authselect: mdns or mdns-minimal
On 07. 08. 23 12:49, Dominik 'Rathann' Mierzejewski wrote:
On Tuesday, 01 August 2023 at 12:16, Petr Menšík wrote:
Hi Pavel,
With Avahi upstream maintainer hat on, I would say it still makes sense to
have separate mdns*_minimal and mdns? modules. I would say mdns
(non-minimal) should be rarely needed, because by default it should be used
just for *.local names. As I have wrote to referenced ticket, I think we
want to prefer mdns_minimal in the future, but it first needs solving
increased timeouts for not present names [1]. As soon as it is solved on
avahi-daemon side, we can deprecate mdns{4,6}_minimal and mdns{4,6}
variants. If only one family should be resolved, I think it would be better
to configure it on side of avahi-daemon.
Simpler is good if it still offers the features required by Fedora.
I think mdns resolution needs smarter approach from avahi-daemon. It might
be useful to not open and re-parse /etc/mdns.allow on every single
``getaddrinfo()`` call, but cache it in thread local storage and re-read its
contents only on timestamp change. Maybe with checking the file stamp only
once per second at most.
Isn't inotify what should be used in such cases?
Regards,
Dominik
inotify is good for such changes, but I would prefer having inotify
socket on side of avahi-daemon. I think inotify sockets are limited and
should not be used by every common client application using nss plugin
for resolution. Let alone by every thread. I think default limit of
inotify sockets is something around 256.
/proc/sys/fs/inotify/max_user_instances gives 128 on my f37. nss plugin
files reads /etc/hosts on every resolution too. I made the change to try
opening /etc/mdns.allow from every call therefore. I am not sure how
critical this file optimization might be.
I haven't found any good way to store cached structures after calls to
getaddrinfo() or getnameinfo(), which would be reasonably safe to use in
simple applications as well as threaded applications. It seems the way
how glibc handles /etc/resolv.conf is not simple to be reused by other
plugins. Cached structures might include allocated memory or any kind of
socket, including inotify. Maybe it is the correct way to rely on
filesystem caching and just call fopen() and fclose() on every name
resolution attempt. That is thread-safe and well supported, is
race-condition free.
res_ninit() call is able to open context for DNS resolution, but that is
available only fro DNS specific resolution. The abstract getaddrinfo()
or getnameinfo() have no way to open cache store on start and clean it
on thread stop or application exit. I think optimizations should be done
only if there is a correct way how to solve them. It seems to me
original nss plugin system does not offer something similar.
Cheers,
Petr
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
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: RFC authselect: mdns or mdns-minimal
I have created upstream pull request, which makes non-minimal plugins to behave like minimal plugins except it tries to find /etc/mdns.allow. If that file does not exist, it copies also reverse queries from minimal plugin. Here: https://github.com/lathiat/nss-mdns/pull/89 On 02. 08. 23 9:15, Zdenek Dohnal wrote: On 8/1/23 12:41, Petr Menšík wrote: Hi Zdenek, the current logic is: - with-mdns4: mdns4_minimal - with-mdns6: mdns6_minimal - with-mdns4 and with-mdns6? mdns_minimal Ah, I have missed last part, that it uses mdns plugin for both queries. If I understand your message correctly, you propose to keep this logic but use mdns4/mdns6/mdns instead of minimal and drop support for minimal completely. Is that right? Thank, Pavel No, not at all. We want minimal variants preferred until nss-mdns is changes significantly. Check nss-mdns issue #88 [1]. 1. https://github.com/lathiat/nss-mdns/issues/88 Petr, this issue exists only if mdns.allow exists, so if we don't ship it as I recommend, we don't hit this issue. The file will be created by a user in case he needs to override settings which are against standards, where IMO a delay is tolerable. Thus, the issue is nice to have and should not block using mdns4/mdns6 variants. What I would support is adding a note into README file of nss-mdns, mentioning the delay due the mentioned bug - until it is fixed. So Pavel, I've understood me correctly - use mdns/mdns4/mdns6 instead of minimal variants, because they provide the same functionality as minimal + possibility to override network misconfigurations. And don't use complete 'mdns' by default. Okay, makes sense, once we include required changes into stable releases. I have created bug #2228533 to track this change, which once in stable, authselect might switch to non-minimal variants. But I'm not a nss-mdns or avahi maintainer, just a maintainer of stacks which use mdns often - printing and scanning. I've got this opinion from issues in past, by checking nss-mdns code and by intention of minimizing of new work in authselect, unless it is necessary. Zdenek Yes, I admit current way of providing different plugins instead of one plugin with related configuration is unfortunate. Because it depends on avahi-daemon anyway, I hope it can be reduced to single plugin, where every customization can be done on side of avahi-daemon. But needs code modifications first, so waiting for a volunteer. -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: RFC authselect: mdns or mdns-minimal
No, I am afraid that is not gist of that response. We still want mdns4_minimal to be preferred variant and others to be configurable manually. Sadly, they are all still needed, with minimal variants preferred. and also --with-mdns should be possible in addition to existing 4 and 6 variants. On 01. 08. 23 12:10, Pavel Březina wrote: On 8/1/23 09:56, Zdenek Dohnal wrote: Hi Pavel, since authselect already advertises features for profiles regarding mdns as: --with-mdns4 --with-mdns6 it would be great if the profile feature logically matched what is going to be enabled - --with-mdn4 will put 'mdns4' into 'hosts' in nsswitch.conf instead of current mdns_minimal. AFAIK from Avahi people (pemensik in CC) I wouldn't go for mdns and mdns_minimal, because hostname->IPv6 + hostname->IPv4 address resolutions are currently made in sequence in Avahi, so the getting the result will be unnecessary delayed if one of them is not defined. IIUC nss-mdns README, the main difference between mdns4 and mdns4_minimal is /etc/mdns.allow file support, which can allow bypassing heuristics and allows user to do mDNS queries in conflict to mDNS standard (f.e. standard specifies that only .local or .local. domains can be used for mDNS) - although it would be great if networks were up to the standards, it is not a case in reality. We had this issue https://bugzilla.redhat.com/show_bug.cgi?id=2148500 , where ISP injected DNS server which defined 'local' domain as classic DNS record, breaking mDNS resolution in whole user's environment. Fortunately Petr came up with solution for it (now nss-mdns does always mDNS lookup for .local, but if there is DNS SOA for .local and mDNS lookup didn't succeed, moves to DNS), so this scenario doesn't need mdns.allow anymore, but IMO there could be other divergence from standards in the networks, so having the option to use mdns.allow in default configuration is welcome. So what I would propose: - use mdns4/mdns6 with authselect --with-mdns4 and --with-mdns6 profile features instead of _minimal to honor name logic, - don't use mdns/mdns_minimal - if someone wants to use it, he can enable both features separately, - if someone would like to use mdns4/6_minimal, he can opt-out from authselect and update nsswitch.conf manually. @Adam, @Petr, please let me know if there are other things to consider or disadvantages in this. Hi Zdenek, the current logic is: - with-mdns4: mdns4_minimal - with-mdns6: mdns6_minimal - with-mdns4 and with-mdns6? mdns_minimal Where exactly are those variants documented? I have looked into man authselect, but failed any word on mdns. How can I check how authselect presents them, please? Anything better than command: $ authselect list-features minimal If I understand your message correctly, you propose to keep this logic but use mdns4/mdns6/mdns instead of minimal and drop support for minimal completely. Is that right? Thank, Pavel No, not at all. We want minimal variants preferred until nss-mdns is changes significantly. Check nss-mdns issue #88 [1]. 1. https://github.com/lathiat/nss-mdns/issues/88 -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: RFC authselect: mdns or mdns-minimal
Hi Pavel,
With Avahi upstream maintainer hat on, I would say it still makes sense
to have separate mdns*_minimal and mdns? modules. I would say mdns
(non-minimal) should be rarely needed, because by default it should be
used just for *.local names. As I have wrote to referenced ticket, I
think we want to prefer mdns_minimal in the future, but it first needs
solving increased timeouts for not present names [1]. As soon as it is
solved on avahi-daemon side, we can deprecate mdns{4,6}_minimal and
mdns{4,6} variants. If only one family should be resolved, I think it
would be better to configure it on side of avahi-daemon.
I think mdns resolution needs smarter approach from avahi-daemon. It
might be useful to not open and re-parse /etc/mdns.allow on every single
``getaddrinfo()`` call, but cache it in thread local storage and re-read
its contents only on timestamp change. Maybe with checking the file
stamp only once per second at most.
An alternative approach might be fetching list of wanted domains first
time the process uses mdns plugin from avahi-daemon. And cache it in
thread local storage of the process (with some ttl before refresh). That
would avoid separate mdns?_minimal and mdns? plugins, because the
smartness would be at avahi-daemon. That is required for any combination
anyway. No slowing down unrelated queries after the first one. I guess
that would make browser people happy, because they try hard to make
everything quite fast. Wrote new issue [2] for this idea.
So a quick summary. I am afraid all those variants are needed until some
volunteer improves the situation and makes them obsolete. I think we are
not there yet.
Cheers,
Petr
1. https://github.com/lathiat/nss-mdns/issues/83
2. https://github.com/lathiat/nss-mdns/issues/88
On 31. 07. 23 14:47, Pavel Březina wrote:
Hi Fedora,
I have this ticket opened against authselect:
https://github.com/authselect/authselect/issues/334
I am not user of mdns myself, so I wonder if non-minimal version of
mdns is something used and if it should be included in the authselect
profiles (or even replace the minimal version).
mdns support is already complicated since there are mdns, mdns4 and
mdns6 full and minimal versions of the module. Is it really required
nowadays? In might opinion, it might be good to move the logic out of
nsswitch into a configuration file.
Thank you for your feedback,
Pavel.
___
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
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
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: Are we ready for ipv6-mostly networks?
The easy way is definitely pushing both IPv6 and IPv4 addresses of any service into DNS. Use at least mdns (which is not resolving also IPv6 in our default configuration sadly), which converts names to ipaddress and back. That in my opinion is the target. To use human friendly names, not IP addresses. Sure, IPv4 are shorter and easier to type in or even spell. But we need the address bits, there is no workaround. IP addresses are not user-friendly way. Dnsmasq for example creates name<->IP address mapping for every machine asking DHCP from it. That is the way to go. Name your machine and reference it by name from others. Avahi is a good alternative for locating your device, even when network does not do mapping to it. If some device does not insert names automatically (hello Mikrotik!), ask their vendor to fix that. Usage of IP addresses should be reduced to strictly necessary minimum. Copy & paste should help with that. Tomorrow is IPv6 Seminar at Prague [3], I am going to attend that. I have still many questions, I am not really IPv6 guru (yet?). On 05. 06. 23 15:27, Michal Schorm wrote: Thought: (disclaimer: I don't know much about networking) IPv4 addresses are in some cases 'human readable' / 'human usable' / 'human friendly'. How can one set up a temporary network of several devices for a LAN party or any similar connecting application use cases? From my own experience, the vast majority of people have no idea that when one tells you "write in: ten zero zero eight", they have to put dots in between. Because they have no idea what IP address is and how it's formatted. I can't imagine I would say this out loud to even a tech experienced person and they would get it right the first time. 1a01:4204:b07d:af00:21c6:542a:611:73ea For real addresses which users actually has to type it is usually better. dns.google: 2001:4860:4860::8844 dns9.quad9.net: 2620:fe::9 Not mentioning all the times I need to connect devices in many rooms across several floors in the whole building. Is there any easy way to keep exchanging the IP address 'human usable' ? No. But we have DNS there for decades to make them human usable. We just need to use it everytime we can. Autoconfigure it when possible. What I am not sure is how should SLAAC allocated addresses be paired with a name provided by the network, into which they are connected to. It is supported with DHCP(v6), but I don't know a good way for router advertisements. A question for experts! Though domain name services is the area I am expert in already. If there is integration missing in some area, fill a bug! Even to me. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Thu, May 25, 2023 at 10:51 PM Petr Menšík wrote: Hello everyone, I have attended recently csnog.eu conference [1], where some interesting presentations took place. They were usually in Czech, so it is not something I am going to share more. But what took my interest were ipv6 readiness with some exceptions. Fedora is ready to be run on dual-stack IPv4 and IPv6 networks just fine. But the presentation were about future case where we run most hosts on IPv6 network only, but allow some older devices to take and use also IPv4 address. Fortunately there is roughly the same presentation[2] in English, which took the place on RIPE 85 meeting. What catched my interest were talk about Windows 11 and Apple systems are ready, but not really talk about how any linux distribution is ready for such situation. It seems to me we should improve the support for mentioned mechanisms in Fedora. What do you think about it? [1] https://indico.csnog.eu/event/13/contributions/121/ [2] https://ripe85.ripe.net/archives/video/923/ 3. https://www.cesnet.cz/akce/seminar-ipv6-2023/ -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: Are we ready for ipv6-mostly networks?
FYI, I have created tracker bug ipv6-mostly [1], which links bugs in different components to make that possible. More below On 01. 06. 23 21:05, Björn Persson wrote: Petr Menšík wrote: ... Fortunately there is roughly the same presentation[2] in English, which took the place on RIPE 85 meeting. What catched my interest were talk about Windows 11 and Apple systems are ready, but not really talk about how any linux distribution is ready for such situation. It seems to me we should improve the support for mentioned mechanisms in Fedora. Having watched the latter presentation, I understand that the idea is that, on a network with a limited pool of globally routable IPv4 addresses, IPv6-capable clients should use only IPv6 and refrain from requesting IPv4 addresses, so that addresses will be available to legacy devices that need IPv4. It seems to me that it would be very difficult for a DHCP client program to know whether the Fedora installation it's running on needs an IPv4 address. I think it would have to be manually configured. I think this is not expected from any clients. Of course we as a Fedora vendor cannot know how the user will use it. I do not have native IPv6 connectivity myself. The presentation explains that it should keep the IPv4 connectivity by using CLAT. How I understood that it would mean NM would configure just IPv6 address on the interface, but should configure also x464clat interface automatically for you. It would make your machine to have IPv4 address on nat64 device, which would have also IPv4 default route directed to it. So ping 8.8.8.8 should work out of the box, but your wifi or eth interface wouldn't have it assigned. Even in case you request a tool to use just IPv4, it should work. Like curl -4 http://example.org or even curl http://93.184.216.34/. We have already clatd package, but the ability to autoconfigure it is missing. Current NM does not even parse information what DNS64 prefixes are used on this network. That is required to make it autoconfigured IMO. It's mentioned in the presentation that IPv6 support is required in Apple's App Store. That's not currently the case in Fedora. In my own opinion everything should by now assume IPv6 as the norm, and treat IPv4 as the legacy protocol that must still be supported for compatibility – but that's not Fedora's policy. The policy is as follows: | If an application contains native and stable support for both IPv4 and | IPv6, and support for IPv6 does not negatively affect IPv4 then both | MUST be enabled in the Fedora package. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_networking_support That means that IPv4-only programs are still quite welcome in Fedora if their lack of IPv6 support is an upstream limitation and not introduced by the packager. Thus the network configuration must expect that the user might run such a program and might need IPv4 connectivity. The policy should probably be changed before Fedora begins requesting only IPv6 addresses by default. Do we have any IPv4 only packages in Fedora? It would be nice to have tracker bug for missing features in upstream packages. I don't know about any more popular or used. But especially because such programs still exist we need something like this. The solution provides client IPv4 connectivity, because it expects private AS112 ranges to be used. Maybe it could be used with public IPv4, but I don't think that makes any sense. We should definitely encourage and recommend full IPv6 support. For applications not ready this is a way to make them working in most of cases. Another concern is that the entire IPv6-mostly concept seems to assume devices that are strictly clients. It doesn't seem like it would work for anyone who runs any kind of server or peer-to-peer program. The idea seems to be that IPv6 clients will access IPv4-only servers over NAT64. Like all address translation, NAT64 is an obstacle to peer-to-peer communication. If you need to communicate with a peer who is stuck with an RFC 1918 address behind NAT on an IPv4-only network – a case that is still far too common – and you're using IPv6 and NAT64, then you and your peer will both be unable to connect to each other. If globally routable IPv4 addresses are available on the network where you are, then you'll want one so that your peer can at least connect to you. Users of peer-to-peer programs will want to configure their DHCP client to request an IPv4 address in case that need arises. Björn Persson I expect servers should have dual stack if they need to provide IPv4 services. I admit couldn't test this concept myself, because I do not have a network with at least native dual stack. Peer to peer connectivity should be possible in the same way as with cascaded IPv4 routers used today. I expect UDP port punching should work. NAT64 should be for a IPv4 server side just another client behind NAT. Most of machines today do not require
Are we ready for ipv6-mostly networks?
Hello everyone, I have attended recently csnog.eu conference [1], where some interesting presentations took place. They were usually in Czech, so it is not something I am going to share more. But what took my interest were ipv6 readiness with some exceptions. Fedora is ready to be run on dual-stack IPv4 and IPv6 networks just fine. But the presentation were about future case where we run most hosts on IPv6 network only, but allow some older devices to take and use also IPv4 address. Fortunately there is roughly the same presentation[2] in English, which took the place on RIPE 85 meeting. What catched my interest were talk about Windows 11 and Apple systems are ready, but not really talk about how any linux distribution is ready for such situation. It seems to me we should improve the support for mentioned mechanisms in Fedora. What do you think about it? [1] https://indico.csnog.eu/event/13/contributions/121/ [2] https://ripe85.ripe.net/archives/video/923/ -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: %patchN deprecated?
I would suggest creating at least self-contained change on Fedora to describe what has changed and why. Those syntax might be a little weird, but were used quite often. It would be nice to have some place to read about it. Because frankly it just started warning when used, but I do not remember it announced. When I searched approved changes mentioning this, there were none. Wiki page might provide links to external sources and could be used by other to reference why they are changing %patchX format. Is there also documented and preferred way to apply just single patch when %autosetup -N -S git is used? I mean, if I want to have all patches applied git-like way, I know I can use -m or -M parameters to %autopatch. But %autopatch -m 1 -M 1 does not look nice. I haven't found how to do that from comments in /usr/lib/rpm/macros. Can you help? On 3/29/23 17:58, Todd Zullinger wrote: Florian Festi wrote: On 3/29/23 10:31, Michael J Gruber wrote: Has `%patchN` been deprecated in favour of `%patch N`? Yes, see %patch section on https://rpm-software-management.github.io/rpm/manual/spec.html Quoting that: %patch is used to apply patches on top of the just unpacked pristine sources. Historically it supported multiple strange syntaxes and buggy behaviors, which are no longer maintained. To apply patch number 1, the following are recognized: %patch 1 (since rpm >= 4.18) %patch -P1 (all rpm versions) %patch1 (deprecated, do not use) For new packages, the positional argument form 1) is preferred. For maximal compatibility use 2). Both forms can be used to apply several patches at once, in the order they appear on the line. The third form where the number is a part of the directive is deprecated and should not be used anymore. Which gets to Michael's question "which releases can take it?" Changing `%patch1` to `%patch 1` limits support to Fedora 37 and above, unless this has been backported to older Fedora and/or RHEL rpm? Until it's supported by all current Fedora and RHEL releases, it's not a change I'd want in the packages I maintain. I'd have to go with `%patch -P1` (anywhere that %autosetup / %autopatch wasn't used). ___ 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 -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: htdig: about to orphan due to license issues, how to?
Okay, thank you. Retired the package in rawhide and orphaned the package. If the removal should be required also in stable releases, I would have to take it again. It would be a part of f38 as it is now sadly, should it be removed even when it is already in the final freeze? I am not sure how much severe is the license problem. Should all stable branches get it retired too? Should complete removal [1] apply to this package? 1. https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#complete_removal On 3/13/23 08:31, Florian Weimer wrote: * Petr Menšík: Is it enough if I orphan that package? Is there any guidance where existing package is found to have licensing problem, how should it be solved? Should something be done to the stable branches also? Should it be retired from all stable branches as well? How should I proceed in this case? I think you should retire it from rawhide at least because it will fail to build after the C99 transition for Fedora 40 anyway. As far as I understand it, Fedora still has permission to distribute, we just don't like the license, so no special action is required from a licensing perspective. Neither Fedora Legal nor the packaging committee request removal in such cases or carry it out themselves. At most, a bug will be filed, but if the maintainer ignores it, basically nothing happens. Thanks, Florian -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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
htdig: about to orphan due to license issues, how to?
Hi! I own htdig package, which got recently discovered license issue with bundled libdb version ~3.x [1]. I think the only reason it is still in Fedora is that just compiled for years back. I doubt anyone is using it at the moment and I have never used it myself. I just inherited it when joined Red Hat and just once fixed FTBFS bug, otherwise there weren't been any feedback to it for years. It uses undeclared libdb copy with Sleepycat license, which were declared incompatible for Fedora [2]. I don't want to invest time to make it compile with alternative database, because I don't think time spent on it is worth it. If anyone would like to maintain and solve those issues, send me a mail. I am happy to give it to anyone else. Upstream is long dead though. Is it enough if I orphan that package? Is there any guidance where existing package is found to have licensing problem, how should it be solved? Should something be done to the stable branches also? Should it be retired from all stable branches as well? How should I proceed in this case? Best Regards, Petr 1. https://bugzilla.redhat.com/show_bug.cgi?id=2168501 2. https://gitlab.com/fedora/legal/fedora-license-data/-/issues/152 -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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
Do we have alternatives to alternatives?
Hi! I heard (read) objections to any alternatives macros usage often. But unless I am mistaken, we do not have any user (enough) friendly way to support similar functionality tools with just minor differences. I thought about it recently and I think we have similar issue solved by systemd-sysusers macros. Unless I am mistaken, they work fine even on rpm-ostree distributions. They have some similarities with alternatives %post scriptlets: those scriptlets more define values for some other tools than they need immediate reaction. Original %pre scriptlets adding users had to be executed during install and never outside. systemd-sysusers solves it fine by calling a common tool and data configuration file. It makes it possible to configure all users at a time or just the user from given config. I think similar approach could work with alternatives. Instead of defining the alternative name by alternatives --install command, we could move link name, path and priority to simple configuration snippet. Then process that definition either per-package (for classic rpm %post) or after-install (for rpm-ostree based distributions). The result should be the same, just time of execution may differ. It would require modification of alternatives to read instructions also from config file, not only from command line parameters. It might be naive, but wouldn't such modification allow to solve alternatives sufficiently also for ostree based installations? Is there a reason why this would not work? Of course it would add extra config file per package using alternatives. Unless I am mistaken, we do not have full featured replacement for current alternatives. Other than not having alternatives at all. I doubt dnf swap approach is more user-friendly, especially because it cannot be done by PackageKit GUI tools. Is there a reason, why my idea cannot work? Is there an unsolved problem it could not solve? Have something similar been considered already? Best Regards, Petr -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: Building two conflicting binaries from the same source
I think the need to find such attempts is a clear indication there is something wrong with the design of current implementation. If there are binaries with different build results, I think some code should be refactored out of the binary itself. The common parts can remain, but hardware specific parts should be moved to dynamically loaded *.so files. The correct files should be loaded depending on hardware found on the system. If auto-detection is wrong, manual configuration via configuration file should be used instead. Are we talking about shared library or executable binary? I think executable binary might use just shell wrapper doing the detection and running correct implementation build. I admit it requires non-trivial changes, but it seems to me they would be required sooner or later. Just my 2 cents. Petr On 11/3/22 21:31, Bojan Smojver via devel wrote: This may be a trivial question, but my friend Google is not showing me any obvious answers, so I will ask here at my own peril. Say one needs to configure and build the same source with two (or more) different sets of options that generate different binary RPMs, but which have files in exactly the same place. This is to support different hardware. The end result would be mutually conflicting binary packages that users then install etc. Sure, it is easy enough to configure/build repeatedly and stash the results into non-conflicting paths of buildroot, but how does one then package this in %files sections into exactly the same paths? If there is an example floating somewhere, that would be very useful. Thanks, -- Bojan -- Petr Menšík Software Engineer, RHEL Red Hat,https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: F38 proposal: RPM Sequoia (System-Wide Change proposal)
Hi, maybe it was already answered.
Not long ago Thunderbird switched from using installed GPG to its own
implementation inside. I think I have found the library part and it
seems to be in C++, which should be much more easier to integrate than
rust libraries.
I think the project link is:
https://github.com/rnpgp/rnp
Wouldn't it solve the problems cause in more compatible way? Is has
relatively recent release, so it does not seem abandoned. Is there a
specific reason, why is a Rust implementation chosen instead? I like
Rust language, but its integration into a core system component does not
seem easy.
Cheers,
Petr
On 20. 10. 22 11:03, Miro Hrončok wrote:
On 10. 10. 22 16:32, Ben Cotton wrote:
For the last 20 years or so, RPM has used a home-grown OpenPGP parser
for dealing with keys and signatures. That parser is rather infamous
for its limitations and flaws, and especially in recent years has
proven a significant burden to RPM development. In order to improve
security and free developer resources for dealing with RPM's "core
business" instead, RPM upstream is in the process of deprecating the
internal parser in favor of [https://sequoia-pgp.org/ Sequoia PGP]
based solution written in Rust.
At this point the change is mostly invisible in normal daily use.
Which of the following will happen:
1) rpm will gain ExclusiveArch: %{rust_arches}
2) we will stop requiring the above in Rust packages, as Rust is 100%
available
3) rpm will %ifarch %{rust_arches} this change
4) something else (what?)
IMHO if we do 1) we could as well do 2) because without rpm, we won't
be able to build rpms. 3) seems somewhat tedious for no good reason.
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
___
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: Once again, more than 8 days delayed notifications
Do we have any notification alternative interface other than IRC? What about pushing notifications to matrix, XMPP or other protocol/service? I think IRC has often also not-so-short delays. Is there something we can to to improve the situation? On 09. 07. 22 15:24, Ralf Corsépius wrote: Hi, I thought the notification delay mess was fixed. Apparently, I was wrong. I just received this: Subject: corsepiu pushed 1 commit to rpms/perl-Sub-HandlesVia (rawhide) Date: Sat, 9 Jul 2022 10:39:46 + (GMT) From: notificati...@fedoraproject.org ... Notification time stamped 2022-07-01 05:57:40 UTC ... Ralf ___ 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 -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: Updated criteria proposal: networking requirements
Because of attitude documented in change for systemd-resolved [1], I expect the only change to get this improved would be switch from systemd-resolved to anything more DNSSEC friendly. I don't understand why, but it seems systemd team is avoiding working DNSSEC as much as they can. Yet it was fixed ALMOST after change related to original issue #4621 [2], reported 4 years before even the original change in Fedora were started. I will attempt to prepare a better working alternative for the next release or the one after it. 1. https://fedoraproject.org/wiki/Changes/systemd-resolved#DNSSEC 2. https://github.com/systemd/systemd/issues/4621 On 09. 06. 22 20:32, Adam Williamson wrote: On Thu, 2022-06-09 at 19:50 +0200, Petr Menšík wrote: I would propose also ability keep DNSSEC validation passthru. If infrastructure provides cryptographic records, they should be available also on the installed host. Without extra modifications. Ie. if delv @$NS is validated for all network DNS servers, then delv should validate too. But that would rule out systemd-resolved in current configuration. delv is a command from bind-utils. Is that too much to ask? I would generally be hesitant to make anything that does not currently work a release criterion. That is effectively requesting development by the back door. It also seems to sort of go against reality - we are apparently fine shipping distributions where this doesn't work, because we've just done it, and there is not an outcry in the press or on social media (AFAICS) that this doesn't work. That tends to imply we don't need to block our releases on it. Basically, if the implied request here is "make it so Fedora really cares whether dnssec works", I'd kinda suggest that should be a Change first. If it's accepted as a Change and gets implemented successfully, then we could maybe consider whether it's a sufficiently important feature to be release blocking. If we haven't even (as a project) decided it's a desirable feature and proved we can implement it (that's what the Change process is for), blocking the release on it seems rather premature... -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: Request to change default /etc/resolv.conf symlink
On 09. 06. 22 19:31, Zbigniew Jędrzejewski-Szmek wrote: I reviewed your pull request https://github.com/systemd/systemd/pull/21317. I know you are trying to move things forward, but at the same time, you're not really responding to feedback. Despite two versions being pushed in the meantime, my re-review was to a large part a repeat of what I posted in January. I said that the approach looks promising, but if you want the patches to be merged, they need to be adjusted to be acceptable for upstream. Zbyszek Funny. I have created prerequisite MR #21257 [1], which had not received any attention in months. It contains very simple change and I hope no controversy. Yet it has stayed like that for months. If not even that change were accepted, then work on MR #21317 would be a waste of my time. From Lennart's comments I got an impression similar change is unwanted. You haven't made a single comment after his comments it is still worth to proceed. I don't know if you vote, but I got an impression Lennart has to agree or don't be involved. Was that wrong? Petr 1. https://github.com/systemd/systemd/pull/21257 -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: Updated criteria proposal: networking requirements
I would propose also ability keep DNSSEC validation passthru. If infrastructure provides cryptographic records, they should be available also on the installed host. Without extra modifications. Ie. if delv @$NS is validated for all network DNS servers, then delv should validate too. But that would rule out systemd-resolved in current configuration. delv is a command from bind-utils. Is that too much to ask? On 04. 06. 22 1:35, Adam Williamson wrote: Hi folks! Some time ago I proposed some specific networking release criteria. I revived the thread back in February, and meeting discussion suggested we should be more intentional and specific about wifi requirements. So, looking at it again, I suggest adding an additional footnote: Footnote titled "Wireless networks": Common wireless network configurations using supported hardware as defined above are covered by this criterion. This includes access to home and enterprise wireless networks using 802.11 series connection protocols and WPA2 and WPA3 personal and enterprise security protocols. Bugs that are specific to particular hardware or configurations will be assessed according to [[Blocker_Bug_FAQ|hardware-dependent-issues|the normal considerations for such issues]]. Here is the full proposal again, with the new footnote included: # === Network requirements === Each of these requirements apply to both installer and installed system environments. For any given installer environment, the 'default network configuration tools' are considered to be those the installer documents as supported ways to configure networking (e.g. for anaconda-based environments, configuration via kernel command line options, a kickstart, or interactively in anaconda itself are included). Basic networking It must be possible to establish both IPv4 and IPv6 network connections using both typical router-provided addressing systems (e.g. DHCP on IPv4 or SLAAC or IPv6) and static addressing. The default network configuration tools for the console, for release-blocking desktops and for installer environments must work well enough to allow typical network connection configuration operations without major workarounds. Standard network functions such as address resolution and connections with common protocols such as ping, HTTP and ssh must work as expected. Footnote titled "Supported hardware": Supported network hardware is hardware for which the Fedora kernel includes drivers and, where necessary, for which a firmware package is available. If support for a commonly-used piece or type of network hardware that would usually be present is omitted, that may constitute a violation of this criterion, after consideration of the [[Blocker_Bug_FAQ|hardware-dependent- issues|normal factors for hardware-dependent issues]]. Similarly, violations of this criteria that are hardware or configuration dependent are, as usual, subject to consideration of those factors when determining whether they are release-blocking. Footnote titled "Wireless networks": Common wireless network configurations using supported hardware as defined above are covered by this criterion. This includes access to home and enterprise wireless networks using 802.11 series connection protocols and WPA2 and WPA3 personal and enterprise security protocols. Bugs that are specific to particular hardware or configurations will be assessed according to [[Blocker_Bug_FAQ|hardware-dependent-issues|the normal considerations for such issues]]. VPN connections Using the default network configuration tools for the console and for release-blocking desktops, it must be possible to establish a working connection to common OpenVPN, openconnect-supported and vpnc-supported VPN servers with typical configurations. Footnote titled "Supported servers and configurations": As there are many different VPN server applications and configurations, blocker reviewers must use their best judgment in determining whether violations of this criterion are likely to be encountered commonly enough to block a release, and if so, at which milestone. As a general principle, the more people are likely to use affected servers and the less complicated the configuration required to hit the bug, the more likely it is to be a blocker. # Any more thoughts, comments, adjustments etc? Thanks! -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: Request to change default /etc/resolv.conf symlink
On 04. 06. 22 12:09, Peter Boy wrote: Is there anywhere a kind of a list to said set of problems? Dnsmasq is currently the only tool that provides seamless split DNS in all (or at least very many) circumstances. So I’m going to change our Fedora Server documentation to recommend (and describe) set set up dnsmasq. The problem with dnsmasq is it has just single upstream maintainer. Adding new features takes time and they are also not well tested. But as its maintainer I think it works much better than resolved. But admit it has much worse runtime reconfiguration interface, but capable to do what is required. That may be true for enterprise usage. For the large number of private stand alone server or SME servers DNSSEC is not more important as for desktops. Depends. Servers often produce much more queries, which would have higher impact if cache were poisoned. DNSSEC protects against that. Unlike weird networks laptop can be connected to, which does not pass required DNSSEC records, data centers usually provide perfect service including fully working DNSSEC. There should not be often reason to turn it off. And split DNS is especially necessary when a server does host libvirt/KVM VMs. In order to address its VMs (e.g. monitoring tools or forwarding services) the host must query the libvirt dnsmasq instance. This is broken since F34/F35 with systemd-resolved. The only reliable way i know of is a second dnsmasq instance, most easily as NM plugin. I have just started discussion about this topic in our internal tech-list. I think there should be common interface for services, which provide any kind of network with dynamic dns to integrate subdomain into main host cache. Whether you use dnsmasq, unbound, systemd-resolved or knot-resolver, it should not matter how well itegrated they can be. If the server has runtime reconfiguration ability, there should be common way how it would allow subdomain redirection. If you use both podman and libvirt, they should be able to access each other via names. But that would be for entirely different thread. So we need a way to configure DNS resolution based on custom needs in every single case, at least until systemd-resolved has resolved all the issues (it is a very nice and elegant solution, I think) Wouldn’t be systemd-resolvd in enabled or disabled state a valid indicator what a sysadmin want’s to use and whether to replace a resolv.conf file by a symbolic link or vice versa? -- 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 Java developer and enthusiast Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure I have filled attempt to improve situation with /etc/resolv.conf ownership in PR [1], but it were not accepted well. I think resolved takes over /etc/resolv.conf even in case where it should not. If you disable systemd-resolved, it leaves your system without working resolution. Even reboot would not fix it automatically. It is fine to have /etc/resolv.conf missing in some cases, but that is not supported by resolved. 1. https://github.com/systemd/systemd/pull/21317 -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: Request to change default /etc/resolv.conf symlink
On 04. 06. 22 12:23, Michael Catanzaro wrote: No, I have no clue. But I'm pretty sure applications that do choose to use /etc/resolv.conf still deserve to receive correct results. Agreed. Which they do not receive from systemd-resolved in certain use cases. Applications use DNS because they expect fully working DNS. Yet systemd adds several non-standard "improvements", which breaks other use cases. I would not complain if it just worked. I see Lennart responded in the upstream bug: https://github.com/systemd/systemd/issues/19227 although it's still waiting on him after a long time. This is an upstream issue, not a downstream issue, so I wouldn't expect much interaction in the downstream bug report. Michael This is an existing issue in Fedora installation. So I fill bugs to Fedora. It is up to fedora maintainers to forward those reports to upstream, if it affects also upstream, or at least we it that way in our team. I don't want to join systemd development. The reason I fill issues there is to improve name resolution in Fedora and also RHEL. Because filled bugzillas have no effect, I try at least on github. To have at least evidence those issues were known and reported. But unlike Fedora, there is no ON_QA phase. They implement something and close the bug. Often it makes me to report another issue, because that was not what were requested or just half of the problem were fixed. Just like with the bug you have mentioned. We have a workflow for that in bugzilla, but it is not used on upstream. -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: Request to change default /etc/resolv.conf symlink
Do we have any list of significant applications, which use /etc/resolv.conf only? It is used by most of DNS related tools I manage. dig and host use dns only. Sure, they would not be able to report split-DNS required hosts correctly. But browsers tend to use getaddrinfo() glibc calls AFAIK. Can you name some important? On 04. 06. 22 2:56, Michael Catanzaro wrote: Hi, This would break split DNS for applications that read /etc/resolv.conf directly. For desktop systems, that's generally way more important than DNSSEC. For split DNS to work, /etc/resolv.conf needs to be managed by either systemd-resolved or dnsmasq. We would go back to dark ages DNS where requests go to the wrong VPN connection and where local network devices like printers don't work as expected. (I understand that your proposal would have no impact on applications that use glibc for name resolution, but inconsistency in results when using glibc vs. /etc/resolv.conf would be a pretty dissatisfying default.) I admit dnsmasq, which I maintain, has existing integration with NM, which can provide required functionality. It has its own set of problems however, therefore I am not pushing it as a replacement in general. In contrast, DNSSEC is unlikely to be useful for most desktops unless adoption improves dramatically, which seems unlikely. Accordingly, I do not support your proposal. There is no real chance of DNSSEC increased adoption if default configuration does not allow its use. I know there are more networks where it is not working. But current setup prevents it use always, on all networks. Even on those where it worked fine on f32. For servers, the opposite is generally true: DNSSEC is generally way more important than split DNS. Of course, there will be exceptions -- e.g. you're familiar with cases where DNSSEC is needed on desktops, and servers on some complex networks apparently really do require split DNS -- but it's true as a generalization. So if we are forced to choose between working split DNS vs. working DNSSEC, I would pick the split DNS for desktop editions, and DNSSEC for server editions. (On servers, the main benefit of systemd-resolved is the DNS cache.) Sure, I admit servers need DNSSEC more and are actually able to use it already. Also tend to use more often more advanced DNS caches. Of course, it's best if we can do both well. I remember previously watching systemd-resolved DNSSEC issues that you considered to be important in: https://bugzilla.redhat.com/show_bug.cgi?id=1879028 which were, eventually, mostly resolved. Based on your comment #28 in that issue, I had understood that you were more or less satisfied. Well, I had not reopened that bug only because it were slight improvement. But I wanted it working in default configuration, which is requested explicitly: https://bugzilla.redhat.com/show_bug.cgi?id=1945309 You and I have exchanged few comments, but maintainers never wrote a single line. What I would have a tracker for, when those bugs don't receive a single comment after 6 months? I don't keep bitting by resolved only because I always disable it ASAP on my machines. I report every issue I find, but very little of them have any progress. But I see you've been discovering more bugs: https://github.com/systemd/systemd/issues/created_by/pemensik Perhaps it could help the systemd-resolved developers if you could create a list/tracker with issues in order of priority/importance? Having a tracker doesn't mean they'll be fixed, but it might help attract attention to the bugs. Michael I can set severity in bugzilla, but they tend to be ignored. I don't know how to express severity on github issues, which at least receive some feedback. -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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
Request to change default /etc/resolv.conf symlink
Hello, We reported issues with DNSSEC tools stopped working with resolved were enabled shortly before f33 release. I admit I have not noticed soon enough, because I haven't noticed how it behaves. We were promised a quick fix back then. Since f33 systemd-resolved is installed by default on Workstation and Server. But the issue remains unchanged still in Fedora 37. Any attempt to use DNSSEC without manual change just fails. You can try delv from bind-utils, unbound-host -rD from unbound or drill -S src.fedoraproject.org from ldns-utils. They all fail on default installation. I have reported multiple bugs, which remains in NEW state for years. I have reported also upstream issues, which are either ignored or closed without proper fix. It stop any my attempts at getting DNSSEC more popular and used. It is clearly not high on systemd team priority list. For years. It has caused regression without a proper fix. I request to change default resolv.conf back to file generated by Network Manager. We have resolve nss plugin listed in /etc/nsswitch.conf, so it would still cache all name requests from glibc. But it would not interfere with DNS specialized tools in a weird way, like LLMNR [1]. I don't think systemd-resolved provides any other record types than reverse mapping or addresses. All that can be safely provided via resolve nss plugin, where it would not cause any regressions. A minimal change would be using /run/systemd/resolve/resolv.conf as a target of current /etc/resolv.conf symlink. If systemd-resolved ever becomes capable as a good DNS cache, we can return it back to domain port. I don't think it is ready for that. Opinions? Regards, Petr 1. https://github.com/systemd/systemd/issues/23494 -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: News from printing world aka PWG May 2022 meetup
Thank you for that COPR repository. I think using SNAPs on Fedora is wrong. I don't like what snaps do with mounted filesystems and consider flatpak more appropriate replacement. But flatpak wants to isolate application from the system. Those apps require to integrate into the system on the other hand. I assume from provided explanation that printer apps needs direct access to USB ports and therefore are not good candidate for placing into some kind of container. It needs a direct access to the host hardware, therefore it belongs to the system. Or is it possible to forward just limited sets of of USB devices into a container? Could perhaps alternative package with unreleased snapshots be provided? That would allow packaging required printer apps, which cannot use stable versions. Should be module considered for applications and new version of cups filters? On 03. 06. 22 3:14, Brandon Nielsen via devel wrote: On 5/19/22 3:27 AM, Zdenek Dohnal wrote: [Snip] - Till Kamppeter wrote printer applications which covers all printer drivers in Debian distribution - we don't have any additional printer driver package in Fedora, so all our driver packages are covered as well Since there were some questions the last time this came up, see this[0] gnome-control-center upstream discussion for how printer applications may be integrated into the desktop environment printer configuration. - printer applications (the solution for driver-only printers how to work with IPP-only CUPS) are available as SNAPs in Fedora (feel free to try them and leave feedback at the respective OpenPrinting project https://github.com/orgs/OpenPrinting/repositories ), packaging them as RPMs is blocked due dependency on cups-filters 2.0, which is not released yet (though IIRC someone from Fedora community - maybe Brandon Nielsen - has them in copr) That would be me[1], though I haven't been giving them the attention they need lately. [Snip] [0] - https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1878 [1] - https://copr.fedorainfracloud.org/coprs/nielsenb/printer-apps/ ___ 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 -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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
[EPEL-devel] Re: [dns-operations] SHA-1 DNSSEC verification broken in RHEL 9 and CentOS 9 Stream
No, I wanted just the first message to reach both, because I am subscribed to both lists. Interested people can search archives of the other list. I expected those lists have very likely disjoint members not able to write to both. Feel free to remove epel-devel from further responses here to avoid receiving errors (and vice versa). On 4/14/22 00:49, Mark Andrews wrote: > If you wanted epel-devel list members to see the discussion you have failed. > > Your message to the epel-devel mailing-list was rejected for the following > reasons: > > The message is not from a list member > > The original message as received by Mailman is attached. > > From: Mark Andrews > Subject: Re: [dns-operations] SHA-1 DNSSEC verification broken in RHEL 9 and > CentOS 9 Stream > Date: 14 April 2022 at 08:44:55 AEST > To: Petr Menšík > Cc: DNS-Operations , > epel-devel@lists.fedoraproject.org > > > The only way to detect if the server is running in this mode is to actually > attempt a verification and to see if it fails. That requires precomputed > signatures as you can’t sign using RSASHA1 in FIPS mode but you can verify > RSASHA1 in FIPS mode. I am not sure what is the platform you are describing. RHEL 9 won't be able to verify RSASHA1 signature even in default policy, let alone in FIPS mode. > > In FIPS mode one can check if the server is running in FIPS mode or not by > calling FIPS_mode() or EVP_default_properties_is_fips_enabled() and you can > adjust the list of algorithms supported by libcrypto at runtime before > attempting to validate anything. You don’t end up doing a lot of work just > to have EVP_VerifyFinal() fail because of an unsignalled policy switch. > > Mark Yes, I find it also disturbing that there is no good public API to check SHA-1 availability except attempting a real crypto operation. I hope that will improve later, but I don't know well working candidate API at the moment. -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] SHA-1 DNSSEC verification broken in RHEL 9 and CentOS 9 Stream
Hello DNS users, I have already created some bugs to inform some affected software packages. But I would like to notify also here with prepared plan to obsolete SHA-1 in upcoming RHEL 9.0. Final documentation is not yet created for it, but it could be tested already on centos container: docker pull quay.io/centos/centos:stream9 delv command from bind-utils or unbound-host -D from unbound can test it. delv would still fail, because it does not follow crypto-policy configuration which named consumes. I have filled tracker bug for EPEL9 components I know on bug #2073066 [1]. If your software validates DNSSEC signatures, it might start failing on domain names signed with RSASHA1 or NSEC3RSASHA1 algorithms. If you have package validating DNSSEC on EPEL9 which I have not mentioned and it is affected, please create a bug blocking this tracker bug. If have created the bug but is not affected, please close it with NOTABUG. Crypto-policy DEFAULT makes some openssl or gnutls methods to fail, when RSASHA-1 key is used. That includes openssl function EVP_VerifyFinal (used in bind) and EVP_DigestVerifyInit (used in unbound). Because used crypto policy DEFAULT prevents such signature verification, DNSSEC validators may start to return failures on those names. A simple workaround would be switching to crypto policy DEFAULT:SHA1: update-crypto-policies --set DEFAULT:SHA1 I have created list to TLD affected and attached them to the bug [2]. But it includes many more names, such as icann.org, ietf.org or paypal.com. I know it violates still active RFC 8624 [3], but because it is enforced by lower-level API, it is possible just to follow or fail. I think so far every crypto call failure results in bogus result and returns status SERVFAIL on the reply. Would it make sense to create some common cases, where the result would be fallback to insecure reply without AD bit, but no failure? Supported bind and unbound packages will start considering those names as insecure to prevent validation failures. There has been interesting conversation on mattermost Town Square [4] on this topic. Worth noting might be also threads on unbound [5] and Fedora discussion about implementing the same way [6]. Best Regards, Petr 1. https://bugzilla.redhat.com/show_bug.cgi?id=2073066 2. https://bugzilla.redhat.com/show_bug.cgi?id=2073066#c7 3. https://datatracker.ietf.org/doc/html/rfc8624#section-3.1 4. https://chat.dns-oarc.net/community/channels/town-square 5. https://lists.nlnetlabs.nl/pipermail/unbound-users/2022-April/007709.html 6. https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/VVLHQAWI3IQ7NRLKMUHJ27JV3V2JAFDP/#W73IMPJVK3DNCRXS5OZXELVWJRDRT6KN -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Fedora-packaging] Re: font copies in sphinx generated documentation
On 2/8/22 20:13, Miro Hrončok wrote: > On 08. 02. 22 19:50, Petr Menšík wrote: >> Is FESCO okay with bundled javascript libraries in similar >> packages? > > FESCo/FPC does allow bundling. See e.g. > https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling > > This is no different. Except what you describe is a lot of work for > the sphinx maintainers. As one of the I'd rather outright ban packaged > documentation than have to make it work myself. It seems ban is quite radical solution. I thought I have seen that in guidelines and indeed. Fonts should not be bundled by other packages [1]. Are system libraries only native code libraries? Doesn't jquery count as system library itself? If javascript libraries do not require any attempts to not duplicate shared code, shouldn't it be mentioned somewhere in guidelines? It seems they try to avoid current situation [2]. I could certainly help with some pull requests, but any change cannot be done at all without cooperation of theme package maintainers. Fedora theme would help to avoid local fonts, but would leave unresolved jquery and underline bundles. Those are part of basic sphinx theme. So change of theme might help only partially. But it would be self-contained change, I guess worth trying. I admit npm processed theme.css is far outside of my expertise. I found we already have some infrastructure for similar things at /usr/share/web-assets/fonts/ and /usr/share/web-assets/javascript/, perhaps it should be reused also for html manuals. Unless documentation build time would be simple to modify, post-processing of installed documentation to (sym)link to shared assets might be simpler. And would require almost no work from sphinx or themes maintainers. Cheers, Petr 1. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_avoid_bundling_of_fonts_in_other_packages 2. https://docs.fedoraproject.org/en-US/packaging-guidelines/JavaScript/#_wrappers_for_other_languages_or_environments -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: font copies in sphinx generated documentation
I prefer much more HTML documentation than PDF. While I try to make PDF also available, HTML is more useful in offline situations, on a train for example. On 2/8/22 15:18, Daniel P. Berrangé wrote: > On Mon, Feb 07, 2022 at 04:51:35PM +0100, Petr Menšík wrote: >> Hi! >> >> I maintain bind package, which generates html documentation using sphinx >> and sphinx_rtd_theme. I admit this format is quite popular. Once I have >> noticed that bind-doc package is quite big. When looking why, I have >> found not a small number of static copies were generated by >> documentation process. >> >> If I remember correctly, fonts are allowed to be shipped only by font >> packages. Not only sphinx packages ships static copies of javascript >> underscore and jquery, but it seems every such package includes also set >> of fonts contained in its documentation. > Perhaps I'm mis-interpreting the guidelines, but I don't feel > like the font packaging rules should apply in this case. When > we describe the rules for packaging fonts, I feel like that was > related to fonts that are to be installed for shared usage. > ie stuff going into /usr/share/fonts should be provided by a > fonts-xxx package, not as a side effect of some other package. I admit I thought fonts are allowed to be packaged ONLY in fonts package and should be reused otherwise. That may not be required. > The fonts that get copied/around embedded in documentation are > for private usage by only that documentation. Any shared docs > generator tools would ideally pull their fonts from common source, > but whatever they do for output we should just accept. It is not > a sane use of resources to expect package maintainers to hack the > generated docs to change how they deal with fonts. Sphinx is just > one docs tool, there are many other tools, often written just to > suit the one app in question. > > Regards, > Daniel Thanks to Ben Beasley for pointing relevant thread in packaging list, it revealed the problem is not primary about size wasted by repeated copies of static content. Especially fonts are included without any hint of original license. It is non-trivial to obtain original data license and I am certain most packages ignores it instead of following packaging guidelines precisely. I found there are python-sphinx-doc and python-sphinx_rtd_theme-doc, which are generated by their respective generators. I compared their contents: diff -ru /usr/share/doc/python-sphinx-doc/html/_static/ /usr/share/doc/python-sphinx_rtd_theme-doc/html/_static/ That revealed most of files are not modified template, but exact copy. Just documentation_options.js and pygments.css seems to be generated and modified. Could we perhaps create python-sphinx-common package, which would put common data to /usr/share/doc/python-sphinx-common/_static/ for example. Then we could make a script for packagers to convert bundled copies to links. sphinx-package make-shared Such script would remove copies and create relative symlinks to /usr/share/doc/python-sphinx-common/_static/ content directory. Packager would then just ensure his doc package Requires: python-sphinx-common package. Harder work would be done by sphinx packager, which would ensure common package has all needed Requires: to fonts or js-jquery, js-underline or similar. He or she would make sure those files stay in single path and point to minimized or normal from original js library. Also would ensure they do not depend on python version for example. Strange thing is, jquery bundled in sphinx package is more recent than matching js-jquery version in f35. Difference is minimal, but they are not the same. Opposite situation is with js-underline, which is much higher version in js-underline than the one bundled in sphinx. Even original packages do not Provides: bundled(js-jquery) from built doc package. If self-contained copy were required, it might not be so hard to prepare also sphinx-package make-static action, which would dereference symlinks and replace them with hard link if possible, a file copy otherwise. sphinx_rtd_theme-package might specialize and extend copied list of files. It would have its own common subpackage with correct dependencies. I think such system would allow proper licensing, because it would point to original package with its well specified license. It would not work great in case of subdirectories mounted somewhere else. Script converting shared links to static copies should make it reasonably simple to create a workaround. I think that might solve both repeated bundling of JS libraries and fonts and save visible amount of space. I admit I am not maintainer of sphinx nor rtd_theme, so most of work would be done outside of my packages. Is FESCO okay with bundled javascript libraries in similar packages? Regards, Petr -- Petr Men
font copies in sphinx generated documentation
Hi! I maintain bind package, which generates html documentation using sphinx and sphinx_rtd_theme. I admit this format is quite popular. Once I have noticed that bind-doc package is quite big. When looking why, I have found not a small number of static copies were generated by documentation process. If I remember correctly, fonts are allowed to be shipped only by font packages. Not only sphinx packages ships static copies of javascript underscore and jquery, but it seems every such package includes also set of fonts contained in its documentation. It leads to interesting situation on RHEL9. It ships fonts in supported packages, which are not shipped in supported repositories. Example: dnf repoquery --disablerepo=rhel-CRB --whatprovides '*/fontawesome-webfont.svg' I expect many users would like to serve those packages via web servers to local networks. Is there way to share static contents in multiple documentation packages and not break at least most common way to share /usr/share/doc via web server? Note: I have attempted to link static contents to python3-sphinx_rtd_theme. I symlinked directories js and css in _static dir. I do NOT recommend anyone to follow my way. This way, I cannot return real directories with real content into the place. Consider that a blind way not worth following. Is there a good way to reduce duplicated documentation content, when keeping it reasonably working? Are there helpers for that? It seems even bodhi-server contains quite big stash of fonts files for example. Many important packages has them bundled. kernel-doc, rust-doc. Do we want that? I have found not a single word about it in font exceptions [1]. Is that okay? It seems guidelines contradicts common practice on this. Regards, Petr 1. https://docs.fedoraproject.org/en-US/packaging-guidelines/FontsPolicy/#_exceptions -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: Request assistance getting a package (usbrelay) into Fedora
Hi Darryl, if you have all sources in single repository then only one source package should exist for them. That means one spec file, which can contain multiple sub-packages produced on build. But input should still be single if they come from single repository. You can build both python and native code from single spec file. It you have never worked with RPM, I would recommend finding someone interested as co-maintainer. You would have to create a package review and obtain a sponsor to own your own package in Fedora. To start RPM packaging, I would suggest reading [1]. Also packaging guidelines [2] of course. Or just copy and modify existing spec. I think my sep review [3] might be useful inspiration to you. It contains both python and cmake builds. Your project uses just make, so %make_build and %make_install would be used instead. Spec file is a recipe to build an RPM package, it would need only source archive in addition. 1. https://rpm-packaging-guide.github.io/ 2. https://docs.fedoraproject.org/en-US/packaging-guidelines/ 3. https://bugzilla.redhat.com/show_bug.cgi?id=2029677 On 1/17/22 11:43, Darryl Bond wrote: > Hello, > I maintain a small application hosted on GitHub. > (https://github.com/darrylb123/usbrelay) > It allows control of USB connected electrical relays. Originally it was a > simple command line application. > Over the years, it has accumulated additional features such as a python > interface, and an mqtt daemon. > There is a debian package that has not been maintained for many years. We are > endeavouring to fix that. > As a long term Fedora user, I would love to get it into Fedora. However I > have never attempted to create an rpm package. The more I read, the more > confused I am. > > Questions on Issues like: > - How to clone the GitHub repository in the spec file Spec file does not clone github repository in any way. Source rpm package contains spec file and source code archive. In case of github, it would be obtained from a release tag. Some smart url can be used from github to download tar.gz source archive, from which the code would be built. If you look on sep [3] example, %forgemeta macro with %forgeurl0 make it easy and it would choose correct %forgesource automagically. > - should there be one package or a separate python package. It makes sense to package python3-usbrelay and usbrelay separately. But both would be built from single source. > - what about the daemon/ systemd service... If you do not have separate library and utilities, keep systemd service together with utilities. If library with devel package exists, it should be separate from utilities/daemons. If you have shared library, I think you should have 4 subpackages in total. - usbrelay (utility and daemon) - usbrelay-libs (shared library) - usbrelay-devel (header files and usbrelay.so) - python3-usbrelay (python module) > > Any help greatly appreciated > > Darryl Regards, Petr -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: How do we announce new packages?
Hello, I still think smaller changes might be better propagated using bodhi system. I know severity is used usually for security updates. But can we make more user-friendly summaries of enhancement updates? I think it might be sorted by severity and list only enhancement or newpackage type updates. Then we could make a nicer summary page with smaller, but still important changes. I think not only new packages are interesting. But a good place describing improvements in existing package in compact enough format is something I miss. What if we make summary for all enhancement updates, putting first high-severity updates. That might be rebases including new functionality for example, which might be useful to users. If only small feature would be added, maintainer may choose medium or low severity. It may generate monthly summaries without much additional work for maintainers. If upstream has a good documentation or blog, it might be sufficient just few bullets with hyperlink to upstream article introducing that features. I think often separate Fedora article would not be required. But do we have any better overview of changes targeted to end-users? I am not aware of anything good myself. I think bodhi enhancement is already not bad [1]. Could we propagate it a bit? Should those updates also include links to Fedora Changes explicit articles? Could we highlight those referencing them with higher 'importance'? If we would be able to hide minor improvements, I think it could pretty interesting for checking upcoming releases. Cheers, Petr 1. https://bodhi.fedoraproject.org/updates/?releases=F36=enhancement On 12/26/21 21:09, Matthew Miller wrote: > On Sat, Dec 25, 2021 at 09:15:38PM +0100, Fabio Valentini wrote: >> So ... maybe we could have a mailing list for this? >> >> Maybe "awesome-announce" or "the-new-shinyness" (I'm kidding! I'm bad >> with names!) at lists.fedoraproject.org, where all Fedora contributors >> could post the fancy new thing that they just made? Because we >> definitely don't have a good place for announcements like that right >> now (the community blog might be the right place for some of those, >> but it is a higher barrier to actually write a blog post that gets >> edited etc. instead of writing an e-mail to a mailing list). > Hmmm. > > The Community Blog should have a pretty low barrier to entry. Are > people feeling blocked by that? We should try to adjust if so. > > As it is, the bar is basically "is this appropriate for this site" and "is > the categorization right", with the editorial pass mostly being for > egregious problems. In other words, I don't think it's actually much more > heavyweight than a moderated announce mailing list would be. > > But I also am not sure Community Blog is the right audience — that's > intended to be contributor-facing, and this seems like something aimed to e > more user-facing. > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: How do we announce new packages?
If newpackage is chosen in Bodhi update, it can be listed from it: https://bodhi.fedoraproject.org/updates/?search==__current__=__pending__=newpackage=1 Slight problem is rawhide only builds do not have newpackage updates in bodhi. I think they do not have any good place to watch them. It lists bunch of packages, but it seems only good coincidence. https://bodhi.fedoraproject.org/updates/?search==F36=newpackage Should the first successful rawhide build trigger newpackage update on current rawhide release? It would also handle case when new package is build only in Rawhide. Review bug then has to be closed manually, because it never passes ON_QA phase without build and bodhi update for stable release. Because the review bug is required for repository creation, I think it would be nice to simplify using it for initial update also on rawhide. Cheers, Petr On 12/22/21 14:07, Eduard Lucena wrote: > Hello people. > > First of all, I'm not a developer or a packager, I just try to help > with the little things I know to do. One thing I try to do is to check > news, forums, ML and places where people talk about Fedora. > > A thing I noted is that a lot of people in magazines and news sites > like phoronix, hacker news and other sites follow this list to get > news about the project and it started to worry me that a big part of > the traffic follow orphaned and retired packages, but nothing is never > revealed/published when a new package enter the repositories or > nothing similar, maybe a review swap but it's not enough. > > Trying to market the number of packages, the amount of free and open > source software that we offer, how this could be measured and > published? Is that something that require to much work? > > Br, > -- > Eduard Lucena > Móvil: +56962318010 > GNU/Linux User #589060 > Ubuntu User #8749 > Fedora Marketing Representative > > ___ > 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 -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: Onboarding package
I like the idea. I think we can even setup tests namespace repo for it, which would ensure all content in this package is %doc only. It does not contain %post scripts and no executable, unless strictly predefined content. That CI repo would have more strict access to ensure newcomers cannot avoid automated checks. We could ask new contributors to review PRs of candidates and merge and build them. I think this package definitely should be part of the distribution. Other packages should not depend on it, so it would get installed only by those who want it. New contributors could also be proud once they have their name in a real package. Don't force anyone, but blocking is not needed IMHO. Cheers, Petr On 10/4/21 21:09, Kevin Fenzi wrote: > On Mon, Oct 04, 2021 at 02:42:58PM -0400, Matthew Miller wrote: >> On Mon, Oct 04, 2021 at 05:52:33PM +, Zbigniew Jędrzejewski-Szmek wrote: >>>> I like the idea! >>>> We can block such a package from ever appearing in a compose in pungi. >>> Is this really necessary? The package will not be open to anyone, >>> but only for approved contributors. Malicious behaviour is not more >>> likely then in any other package (and would be immediately caught). >>> I think we're thinking up technical solutions to something that is >>> not a problem. >> Yeah, I think making it a real package is a good idea. Maybe even a little >> packaged script that runs >> >> xdg-open https://docs.fedoraproject.org/en-US/fedora-join/ >> >> ? >> >> The package itself can even be a gateway to onboarding for the curious, but >> more importantly, it'd act more like a real package. > True. As long as there's a group of experenced folks watching it, that > should be ok. > > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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] Introduction of OpenSSL 3.0.0 in F36
Hello Sahana and Jakub, openssl-pkcs11 module failed during rebuild. It has no separate bug yet, but missing pkcs11 engine for OpenSSL 3.0 bind build makes freeipa server fail to even start. Filled bug #2005832 [1]. CentOS Stream 9 build of openssl-pkcs11 were successful, I think there are missing changes required on Rawhide. Please include required fixes also in Rawhide. Is there any timeline, when would be FTBFS bugs filled? I did not yet found any bug on openssl-pkcs11. I would expect openssl engine packages would be ready before mass rebuild. Could it be fixed soon please? Cheers, Petr 1. https://bugzilla.redhat.com/show_bug.cgi?id=2005832 On 9/20/21 10:47, Sahana Prasad wrote: > > > On Fri, Sep 17, 2021 at 12:50 PM Neal Gompa wrote: > > On Fri, Sep 17, 2021 at 5:09 AM Sahana Prasad > wrote: > > > > Hello all, > > > > The side-tag was merged yesterday. OpenSSL 3.0.0 is available in > rawhide now. > > You can continue to port your changes for OpenSSL 3.0.0 now. > > > > The following packages FTBFS (attached), kindly have a look at them. > > I haven't reported FTBFS bugs right away. As I know many > packages have the porting ready already > > and they were waiting for 3.0.0 to land in rawhide. > > Some packages fail due to usage of deprecated functions. > Consider treating those warnings as not errors > > for a quick fix and you could slowly stop using deprecated > functions in the future. > > > > Thanks Miro for your help with building packages in the side-tag > and getting a list of failed packages. > > > > We will try a rebuild of all these failed packages after 3/4 > weeks and report bugs for failing packages then. > > > > I noticed that the changelog for the openssl package got truncated. Is > there a reason for this? The spec file wasn't significantly rewritten, > nor was there some other condition invalidating the entire recorded > history of the package. Would you kindly please restore the changelog > to the spec file? > > > Hi Neal, > I will restore it. > Thank you, > Regards, > Sahana Prasad > > > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > > > ___ > 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 -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: libvirt and systemd-resolved integration?
On 9/10/21 4:57 PM, Peter Boy wrote: > Hi all, > > I’m working on an update of the Fedora Server virtlib documentation > (https://docs.fedoraproject.org/en-US/fedora-server/virtualization-install/), > specifically the part about the DNS configration. > > I would like to include and integrate the solutions presented in this thread > by Daniel Berrange and by Juan Alcaine. But unfortunately none of the > solutions worked in my test installations. I would be grateful if I could get > some hints on what I might have missed. > > The main challenge is to enable the host to resolve the internal name of the > VMs. For this purpose, the DNS server provided by libvirt must be included in > the search path (default virbr0 192.168.122.1). The server itself works fine. > If you use dig or nsloookup to assign the servers, the names of the VMs are > resolved correctly. No, it does not have to be included in search path. It is just required to forward any subset of names to dns server listening on libvirt's interface. > > > > (a) === Installing libvirt-nss. (Daniel Berrange) === > > I did the following > > 1. dnf install libvirt-nss > > 2. Modified following the libvirt documentation and the docs included with > the files /etc/authselect/user-nsswitch.conf and edited the hosts item to > "hosts: files myhostname libvirt resolve [!UNAVAIL=return] dns“ > > 3. executed: authselect apply-changes > > 4. reboot > > Neither using standard DNS without systems-resolved activated nor using > systemd-resolved could resolve the internal names of the VM nss modules affects just getaddrinfo() calls from programs, if it uses only glibc to resolve names. Could be tested by "getent hosts " command. Any program using DNS directly, like host or dig, would not be affected by it. Setting up dns forwarding is more work, but would help all programs, no matter how they resolve names to IP addresses. > (b) === using libvirt hook dir to modify systemd-resolved configuration === > > I followed Juan Alcaine's instructions and after booting I got: > > (for my homelab domain, served as public here) > Link 2 (enp1s0) > Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 > Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS > DNSSEC=no/unsupported > Current DNS Server: 192.168.158.1 >DNS Servers: 192.168.158.1 fd00::3681:c4ff:fe14:21b4 > DNS Domain: fritz.box > > (for my internal domain via libvirt ipv4 only) > Link 5 (virbr0) > Current Scopes: DNS LLMNR/IPv4 > Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS > DNSSEC=no/unsupported > Current DNS Server: 192.168.122.1 >DNS Servers: 192.168.122.1 > DNS Domain: fritz.lan > > The internal names could be resolved, but with such a long delay that the > solution is practically unusable. The „host“ utility provided the internal > IPv4 name immediately, but continued searching for several seconds and > finally the process was terminated with 2 times of the message ";; connection > timed out; no servers could be reached“. Host without -t parameter given sends -t A, -t and -t MX queries for given name. Because of the way dnsmasq behaves, you are waiting for -t and -t MX queries. Because they are looping from systemd-resolved to dnsmasq and back, until one of them drops them. > > In the systemd-resolved log I found a lot of entries like > > Firing regular transaction 50808 for scope dns on > virbr0/* (validate=yes). > > But virbr0 is ipv4 only. This happens because dnsmasq serving names for libvirt network sends queries to whatever resolver it got from the system. Meaning usually back to whatever forwarded the name to it. In my configuration, I used domain statement in virsh net-edit default to prevent sending X.vm names back to the system resolver. It becames then (sort of) authoritative for that name. You would just replace vm with fritz.lan (or vm.home.arpa.). localOnly=yes is imporant part. It tells dnsmasq to consider all names under fritz.lan its own and if it does not know them, they do not exist. If dns cache on hosts forwards some domain to it, it is required to break loops. ... ... It would be nice if it could be done automagically, but I doubt used domain can be specified on just single place. Together with libvirt hook, the above should work. > Any advice greatly appreciated. > > > Peter > > > > > >> Am 08.10.2020 um 09:33 schrieb Juan Orti Alcaine : >> >> >> >> El mié., 7 oct. 2020 a las 10:35, Petr Menšík () >> escribió: >> >> >> On 10/7/20 6:44 AM, Pavel Zhukov wrote: >>> I don't think it's a good idea. >>> dnsmasq is not dns resolver but acts as DHCP and DNS server. It pr
Re: [Heads-up] Introduction of OpenSSL 3.0.0 in F36
On 9/15/21 1:54 PM, Miro Hrončok wrote: > On 15. 09. 21 13:00, Vít Ondruch wrote: >> >> Dne 15. 09. 21 v 12:57 Petr Menšík napsal(a): >>> >>> Hi Sahana, >>> >>> it would be nice, if changelog entry contained bug id we could use >>> to watch the progress. >>> >> >> The commit message should contain reference to the change proposal IMO Yes, something similar to mass rebuilds before new release. They also have URL to details. I think all non-maintainer commits should have some reference to details, why is it done. > > I've never referenced the Bugzilla ID or change proposal when I've > done Python 3.X rebuilds and I have never heard somebody that it > mattered to them. > > Referencing the change in the commit message is actually a good idea > in retrospect. However, referencing a bug ID might create a lot of > noise, we once did that here: > > https://bugzilla.redhat.com/show_bug.cgi?id=1748018 This bug is something I had on mind. But I would expect it would be only used as Depends: field on bugs filled to failed components. I were looking for a bug number to add to block > > People kept associating unrelated EPEL updates with this for months, > as "fedpkg update" or some other clever thing automatically added that > bug ID to them. > Indeed, there were a lot of EPEL builds referencing Fedora bug. If that were done by any existing tool, it should be fixed. I doubt we ever want EPEL builds to directly reference Fedora builds. It might be done in rare cases by a person, but I doubt it should ever be done by any automated tool. Maybe if it had bug cloned to EPEL, it might followed clone with matching product for the build. I think we miss here way to make that bug only related. It might be added to bodhi updates of such builds, but it should not switch state of referenced bug in any way, let alone close it. It should just be clickable link from bodhi update. It should be considered only as indication similar problem had multiple packages. Would such feature make sense also to others? Cheers, Petr -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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] Introduction of OpenSSL 3.0.0 in F36
Hi Sahana, it would be nice, if changelog entry contained bug id we could use to watch the progress. Or any other link to some tracker. bind package has a new release, I am preparing update for it, but I am not sure where should I watch for a progress. Even build of openssl itself does not reference any bug. Is there any better tracker than bug #1825937, which I can monitor for progress? Is the koji build the best way to check readiness? Does exist any variant of RHEL9 bug #1958021 <https://bugzilla.redhat.com/show_bug.cgi?id=1958021> for Fedora Rawhide? Is there any expected timeline, how long it might take to merge the side-tag? Thanks! Regards, Petr On 9/14/21 6:56 PM, Sahana Prasad wrote: > Hi all, > > The builds of packages that depend on OpenSSL are being rebuilt in the > side tag f36-build-side-44794 [1] now. > > Note to package maintainers: If you see a "Rebuilt with OpenSSL > 3.0.0" commit in your package, do not build it in > regular rawhide unless the side tag is merged > > [1] > https://koji.fedoraproject.org/koji/builds?inherited=0=44794=-build_id=1 > <https://koji.fedoraproject.org/koji/builds?inherited=0=44794=-build_id=1> > > > Thank you, > Regards, > Sahana Prasad > > > > On Wed, Sep 8, 2021 at 5:06 PM Sahana Prasad <mailto:sah...@redhat.com>> wrote: > > > > On Wed, Sep 8, 2021 at 4:35 PM Omair Majid <mailto:oma...@redhat.com>> wrote: > > Hi, > > Sahana Prasad mailto:sah...@redhat.com>> > writes: > > > An update that I will directly bring in the OpenSSL 3.0.0 > final RC > > (released upstream yesterday) > > Thanks for doing this! > > I read the upstream announcement and it certainly reads like > it's the > final/GA release, not an RC: > > https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/ > <https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/> > > Do you know what's going on? Did they phrase it badly or did they > perform multiple releases in parallel? > > > Hi Omair, > > Sorry I phrased it incorrectly. It is the final major version > only, not the RC. > > Thank you, > Regards, > Sahana Prasad > > > Thanks, > Omair > > -- > PGP Key: B157A9F0 (http://pgp.mit.edu/ <http://pgp.mit.edu/>) > Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0 > > > ___ > 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 -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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 unit files installed into unowned directories
Sure, it would contain some files on almost every system anyway. If it contains already /usr/lib64/pm-utils/power.d, I guess it can (co)own few directories of systemd. Much more used in my opinion. Opened pull request for it: https://src.fedoraproject.org/rpms/filesystem/pull-request/6 On 8/6/21 1:44 AM, Björn Persson wrote: > Petr Menšík wrote: >> No, that is the reason why I proposed it. Guidelines already state >> *-filesystem packages does not have to be depended on [1]. Just one, >> probably systemd or systemd-libs, should depend on it to get it >> installed. All other can then just ignore the directory exactly as you >> have proposed. In this case it would not be breaking guidelines, but >> according to them instead. >> >> 1. >> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_ownership > That is contradicted by the following quote from the Packaging > Guidelines: > > | Sometimes, it may be preferable for such directories to be owned by > | an "artificial filesystem" package, such as mozilla-filesystem. These > | packages are designed to be explicitly required when other packages > | store files in their directories, thus, in such situations, these > | packages should explicitly Require the artificial filesystem package > | and not multiply own those directories. > > That is, each of those 1600 packages would need to require > systemd-filesystem. > > Perhaps the filesystem package should own these directories? Not > systemd-filesystem, just filesystem. The case is rather similar to > /usr/share/bash-completion, /usr/share/man, /usr/share/info and various > other directories that filesystem owns. > > Björn Persson > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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 unit files installed into unowned directories
On 8/5/21 6:47 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Aug 05, 2021 at 04:45:31PM +0200, Petr Menšík wrote:
>> Depends on how many maintainers should fix their package, more below.
>>
>> On 8/4/21 4:22 PM, Zbigniew Jędrzejewski-Szmek wrote:
>>> On Wed, Aug 04, 2021 at 10:27:10AM +0200, Petr Menšík wrote:
>>>> Hi Zbyszek,
>>>>
>>>> thanks for your comment. Wouldn't it be much clearer instead of turning
>>>> bind eye on the issue creating noarch systemd-filesystem subpackage,
>>>> which would own:
>>>>
>>>> %files filesystem
>>>> %dir %_unitdir
>>>> %dir %_userunitdir
>>>> %dir %_tmpfilesdir
>>>> %dir %_sysusersdir
>>> I don't think so. This is an intrusive solution: visible to users
>>> in package upgrade outputs, annoying to package maintainers.
>> Does it bother users to include new dependencies during upgrades? I
>> would not certainly notice when I upgrade ~500 packages every week.
>> Annoying to how many package maintainers? Would owning those directories
>> by every package using those directories would be less annoying?
>>
>> Alternative would be moving these empty directories into systemd-libs,
>> which is installed in fedora:rawhide podman container. It seems also in
>> mock build environments. No public visible changes, what would you think?
>>
>> [root@8fec9bc0b895 /]# rpm -qf /usr/lib/systemd/system/
>> file /usr/lib/systemd/system is not owned by any package
>>
>>>> and systemd would just contain requirement on it
>>>>
>>>> Requires: %{name}-filesystem
>>>>
>>>> This would be 100% according to the Guidelines, every automated tools
>>>> should not raise any warning and developers would not have to pretend
>>>> they haven't seen it. Instead of silently breaching our guidelines, can
>>>> we adjust it to follow them?
>>>>
>>>> Shall I try a pull request on systemd?
>>> No, I don't think -filesystem packages are a solution we should be
>>> recommending nowadays. If you want strict conformance to the guidelines,
>>> insert '%dir %_unitdir' in the package: this is also a one-line solution
>>> and doesn't require any other changes.
>> What I don't like about this approach, it would result in ~1600 times
>> single line for every package delivering some unit file. Or the same
>> number of rules violation. Versus single package change working for all
>> of them. I admit it would mean your package should be updated instead of
>> mine (and others). I would update it if I were in your position.
> But most of those 1600 packages would need to add Requires:systemd-filesystem.
> (As discussed earlier in the thread, no Requires:systemd dependency is
> needed nowadays.)
No, that is the reason why I proposed it. Guidelines already state
*-filesystem packages does not have to be depended on [1]. Just one,
probably systemd or systemd-libs, should depend on it to get it
installed. All other can then just ignore the directory exactly as you
have proposed. In this case it would not be breaking guidelines, but
according to them instead.
1.
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_ownership
>
> N.B.: If we're going to add a line to 1600 packages, I think it's much better
> to add one line in %files, directly adjacent to the line for the unit file,
> then one or two lines somewhere in the header part of the spec file. (I
> say two, because you'd probably also want a comment explaining why that line
> is added.)
Imagine the required work, if someone realizes after a year that the
directory should be owned by a different group. This way would create so
many repetitions in different packages, which I think should be put into
single shared piece. The same way as the code.
>
>> Are *-filesystem packages considered deprecated?
> Officially, no. But we certainly don't add as many new ones as in the
> past.
>
> Zbyszek
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
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 unit files installed into unowned directories
Depends on how many maintainers should fix their package, more below.
On 8/4/21 4:22 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Aug 04, 2021 at 10:27:10AM +0200, Petr Menšík wrote:
>> Hi Zbyszek,
>>
>> thanks for your comment. Wouldn't it be much clearer instead of turning
>> bind eye on the issue creating noarch systemd-filesystem subpackage,
>> which would own:
>>
>> %files filesystem
>> %dir %_unitdir
>> %dir %_userunitdir
>> %dir %_tmpfilesdir
>> %dir %_sysusersdir
> I don't think so. This is an intrusive solution: visible to users
> in package upgrade outputs, annoying to package maintainers.
Does it bother users to include new dependencies during upgrades? I
would not certainly notice when I upgrade ~500 packages every week.
Annoying to how many package maintainers? Would owning those directories
by every package using those directories would be less annoying?
Alternative would be moving these empty directories into systemd-libs,
which is installed in fedora:rawhide podman container. It seems also in
mock build environments. No public visible changes, what would you think?
[root@8fec9bc0b895 /]# rpm -qf /usr/lib/systemd/system/
file /usr/lib/systemd/system is not owned by any package
>> and systemd would just contain requirement on it
>>
>> Requires: %{name}-filesystem
>>
>> This would be 100% according to the Guidelines, every automated tools
>> should not raise any warning and developers would not have to pretend
>> they haven't seen it. Instead of silently breaching our guidelines, can
>> we adjust it to follow them?
>>
>> Shall I try a pull request on systemd?
> No, I don't think -filesystem packages are a solution we should be
> recommending nowadays. If you want strict conformance to the guidelines,
> insert '%dir %_unitdir' in the package: this is also a one-line solution
> and doesn't require any other changes.
What I don't like about this approach, it would result in ~1600 times
single line for every package delivering some unit file. Or the same
number of rules violation. Versus single package change working for all
of them. I admit it would mean your package should be updated instead of
mine (and others). I would update it if I were in your position.
Are *-filesystem packages considered deprecated?
>> On 8/3/21 5:31 PM, Zbigniew Jędrzejewski-Szmek wrote:
>>> On Tue, Aug 03, 2021 at 05:12:22PM +0200, Petr Menšík wrote:
>>>> It seems to me most of common services do not require systemd for
>>>> functionality. They might be able to be installed in container without
>>>> systemd involved. The more I look at [1], the more I think common
>>>> package with some service should usually include just
>>>> %systemd_{post,preun,postun_with_restart} snippets and instead of
>>>> %systemd_requires just %{?systemd_ordering}. If the service does not
>>>> require systemd to start, it should not require it, right? Snippets are
>>>> prepared already to handle situation without systemd gracefully.
>>> Yes. Even further, services should not require systemd, even if
>>> systemd is normally used to start them. On normal installations systemd
>>> is already installed anyway, so the dependency is moot. Not having
>>> a hard dependency makes it easier to do custom installations,
>>> tests in mock, containers, etc. So even %{?systemd_ordering} is
>>> not necessary in most cases. The guidelines have been updated to
>>> drop the Requires a while back.
>>>
>>>> In that case, who should own %_unitdir and similar? systemd is not tiny
>>>> enough to not make a difference. On the other hand number of package
>>>> owning %_unitdir might be quite high. Could there be minimal 'virtual'
>>>> owner?
>>> It's fine to co-own %_unitdir. But I would say that it's also fine to
>>> just ignore this issue, and let only systemd own the directory, even
>>> if the package installing files under the directory doesn't have a
>>> hard dependency on systemd. Owning directories is useful when the user
>>> may install the package, uninstall it, and then be left with a "dangling"
>>> empty directory. But this is unlikely to happen in the case of anything
>>> systemd-related: systemd cannot be uninstalled on normal systems,
>>> and on the other hand, on custom images that *never* had systemd,
>>> you're unlikely to install and uninstall packages. So I'd advocate
>>> this small breach of the guidelines, since it doesn't cause any real
>>> problems and makes packager life easier.
>>>
>>> Zbyszek
>> Unfo
Re: Systemd unit files installed into unowned directories
Hi Zbyszek,
thanks for your comment. Wouldn't it be much clearer instead of turning
bind eye on the issue creating noarch systemd-filesystem subpackage,
which would own:
%files filesystem
%dir %_unitdir
%dir %_userunitdir
%dir %_tmpfilesdir
%dir %_sysusersdir
and systemd would just contain requirement on it
Requires: %{name}-filesystem
This would be 100% according to the Guidelines, every automated tools
should not raise any warning and developers would not have to pretend
they haven't seen it. Instead of silently breaching our guidelines, can
we adjust it to follow them?
Shall I try a pull request on systemd?
Few notes below.
On 8/3/21 5:31 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Aug 03, 2021 at 05:12:22PM +0200, Petr Menšík wrote:
>> It seems to me most of common services do not require systemd for
>> functionality. They might be able to be installed in container without
>> systemd involved. The more I look at [1], the more I think common
>> package with some service should usually include just
>> %systemd_{post,preun,postun_with_restart} snippets and instead of
>> %systemd_requires just %{?systemd_ordering}. If the service does not
>> require systemd to start, it should not require it, right? Snippets are
>> prepared already to handle situation without systemd gracefully.
> Yes. Even further, services should not require systemd, even if
> systemd is normally used to start them. On normal installations systemd
> is already installed anyway, so the dependency is moot. Not having
> a hard dependency makes it easier to do custom installations,
> tests in mock, containers, etc. So even %{?systemd_ordering} is
> not necessary in most cases. The guidelines have been updated to
> drop the Requires a while back.
>
>> In that case, who should own %_unitdir and similar? systemd is not tiny
>> enough to not make a difference. On the other hand number of package
>> owning %_unitdir might be quite high. Could there be minimal 'virtual'
>> owner?
> It's fine to co-own %_unitdir. But I would say that it's also fine to
> just ignore this issue, and let only systemd own the directory, even
> if the package installing files under the directory doesn't have a
> hard dependency on systemd. Owning directories is useful when the user
> may install the package, uninstall it, and then be left with a "dangling"
> empty directory. But this is unlikely to happen in the case of anything
> systemd-related: systemd cannot be uninstalled on normal systems,
> and on the other hand, on custom images that *never* had systemd,
> you're unlikely to install and uninstall packages. So I'd advocate
> this small breach of the guidelines, since it doesn't cause any real
> problems and makes packager life easier.
>
> Zbyszek
Unfortunately many packages will drag systemd into containers/mock
without ever needing it. I think that was recommended not long ago. That
includes bind and dnsmasq packages I own. Is the latest best practice to
remove %systemd_requires everywhere with just common services and use
just %systemd_preun macros to handle it? I have missed such
recommendation, was it in some announced change or at least here on
devel list?
It seems to be a smart change, but I found it just by pure coincidence.
I might not be the only one.
Cheers,
Petr
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
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 unit files installed into unowned directories
It seems to me most of common services do not require systemd for
functionality. They might be able to be installed in container without
systemd involved. The more I look at [1], the more I think common
package with some service should usually include just
%systemd_{post,preun,postun_with_restart} snippets and instead of
%systemd_requires just %{?systemd_ordering}. If the service does not
require systemd to start, it should not require it, right? Snippets are
prepared already to handle situation without systemd gracefully.
In that case, who should own %_unitdir and similar? systemd is not tiny
enough to not make a difference. On the other hand number of package
owning %_unitdir might be quite high. Could there be minimal 'virtual'
owner?
1.
https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_dependencies_on_the_systemd_package
On 8/3/21 12:11 PM, Vascom wrote:
> Your package require systemd?
> Systemd own this directory?
> If yes it is OK
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_the_directory_is_also_owned_by_a_package_implementing_required_functionality_of_your_package
> <https://docs.fedoraproject.org/en-US/packaging-guidelines/#_the_directory_is_also_owned_by_a_package_implementing_required_functionality_of_your_package>
>
> If you mean warning from fedora-review then it tool may be old. But
> reviewer must manually check all points and not use only automatic
> reviewing tools.
>
> вт, 3 авг. 2021 г., 13:05 Petr Menšík <mailto:pemen...@redhat.com>>:
>
> Hello,
>
> I just did package review and noticed systemd service files are
> installed into %_unitdir without proper. I failed to notice all my
> packages install into the same directory without depending on that
> directory.
>
> I did not find explicit note about the issue anywhere in Packaging
> Guidelines. Unowned directories [1] note only 'core packages' without
> precise specification, how can one identify core package. While I
> agree
> systemd IS core package for sure, is there reason why
> systemd-filesystem
> noarch subpackage does not own %_unitdir, %_userunitdir and
> %_tmpfilesdir?
>
> I admit systemd might be missing only in few containers without init
> system. Does systemd have special expection? Can be guidelines updated
> to mention this is okay? In that case fedora-review should be adjusted
> to not warn about those directories.
>
> I would propose creation of systemd-filesystem package required by
> systemd, which would pass general rule about *-filesystem package not
> required.
>
> Any opinions?
>
> Regards,
>
> Petr
>
> 1.
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/UnownedDirectories/
>
> <https://docs.fedoraproject.org/en-US/packaging-guidelines/UnownedDirectories/>
>
> --
> Petr Menšík
> Software Engineer
> Red Hat, http://www.redhat.com/ <http://www.redhat.com/>
> email: pemen...@redhat.com <mailto:pemen...@redhat.com>
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> <mailto:devel@lists.fedoraproject.org>
> To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> <mailto:devel-le...@lists.fedoraproject.org>
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> <https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> <https://fedoraproject.org/wiki/Mailing_list_guidelines>
> List Archives:
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
> <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
> <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
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...
Re: Systemd unit files installed into unowned directories
No, my packages do not always require systemd. It might be error in some
cases, but I think %{?systemd_requires} is the only part usually
required. Which means systemd has to be there during updates, but
otherwise it leaves %_unitdir/*.service _partially_ reside in unowned
directory. It is owned just during post, postun and preun. Is that enough?
On 8/3/21 12:11 PM, Vascom wrote:
> Your package require systemd?
> Systemd own this directory?
> If yes it is OK
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_the_directory_is_also_owned_by_a_package_implementing_required_functionality_of_your_package
> <https://docs.fedoraproject.org/en-US/packaging-guidelines/#_the_directory_is_also_owned_by_a_package_implementing_required_functionality_of_your_package>
>
> If you mean warning from fedora-review then it tool may be old. But
> reviewer must manually check all points and not use only automatic
> reviewing tools.
I did review it manually and reported it to the reporter. The package
does not explicitly Requires: systemd. But I failed to note my own
packages do not depend on systemd too. I don't think every package with
a service should hard require systemd. Take dnsmasq package as an example.
# rpm -qv --requires dnsmasq | grep systemd
post: systemd
preun: systemd
postun: systemd
Which means it is not required outside upgrading process. Is that okay?
Is that wrong? I am not sure, not perfect I would say.
>
> вт, 3 авг. 2021 г., 13:05 Petr Menšík <mailto:pemen...@redhat.com>>:
>
> Hello,
>
> I just did package review and noticed systemd service files are
> installed into %_unitdir without proper. I failed to notice all my
> packages install into the same directory without depending on that
> directory.
>
> I did not find explicit note about the issue anywhere in Packaging
> Guidelines. Unowned directories [1] note only 'core packages' without
> precise specification, how can one identify core package. While I
> agree
> systemd IS core package for sure, is there reason why
> systemd-filesystem
> noarch subpackage does not own %_unitdir, %_userunitdir and
> %_tmpfilesdir?
>
> I admit systemd might be missing only in few containers without init
> system. Does systemd have special expection? Can be guidelines updated
> to mention this is okay? In that case fedora-review should be adjusted
> to not warn about those directories.
>
> I would propose creation of systemd-filesystem package required by
> systemd, which would pass general rule about *-filesystem package not
> required.
>
> Any opinions?
>
> Regards,
>
> Petr
>
> 1.
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/UnownedDirectories/
>
> <https://docs.fedoraproject.org/en-US/packaging-guidelines/UnownedDirectories/>
>
> --
> Petr Menšík
> Software Engineer
> Red Hat, http://www.redhat.com/ <http://www.redhat.com/>
> email: pemen...@redhat.com <mailto:pemen...@redhat.com>
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> <mailto:devel@lists.fedoraproject.org>
> To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> <mailto:devel-le...@lists.fedoraproject.org>
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> <https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> <https://fedoraproject.org/wiki/Mailing_list_guidelines>
> List Archives:
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
> <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
> <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
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFC
Systemd unit files installed into unowned directories
Hello, I just did package review and noticed systemd service files are installed into %_unitdir without proper. I failed to notice all my packages install into the same directory without depending on that directory. I did not find explicit note about the issue anywhere in Packaging Guidelines. Unowned directories [1] note only 'core packages' without precise specification, how can one identify core package. While I agree systemd IS core package for sure, is there reason why systemd-filesystem noarch subpackage does not own %_unitdir, %_userunitdir and %_tmpfilesdir? I admit systemd might be missing only in few containers without init system. Does systemd have special expection? Can be guidelines updated to mention this is okay? In that case fedora-review should be adjusted to not warn about those directories. I would propose creation of systemd-filesystem package required by systemd, which would pass general rule about *-filesystem package not required. Any opinions? Regards, Petr 1. https://docs.fedoraproject.org/en-US/packaging-guidelines/UnownedDirectories/ -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: guile22 -> gnutls -> lots of virt packages
at make is a more prominent > package than most. This is interesting request. I spent some thinking about it for my optional package features bind-sdb. Do we have any way to guess what feature is used at least sometime? Especially hard for make package, where you cannot expect checking every dependent package by hand. What would be considered sufficient research about usage of guile? If package provides it as optional feature among many other features, how should package owner test one feature is still demanded? Do we have any best practice? Is asking on users@ and devel@ list enough? > > So: I'd like to see actual investigation into whether the guile > support is actually used in any Fedora package, and if it's going to > be removed, it should be removed upstream first. > If it turns out that really actually nobody uses this, why not drop it > upstream, and have the guile support removal come with the next GNU > toolchain Change for Fedora? > > Fabio Cheers, Petr -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: Offering strongswan for (co)maintaining
Thanks, added you both. Anyone with direct feedback from people using it is quite welcome. On 3/31/21 7:38 PM, Michel Alexandre Salim wrote: > Hi Petr, > > On Wed, 2021-03-31 at 14:12 +0200, Petr Menšík wrote: >> Hello, >> >> strongswan and NetworkManager-strongswan packages were passed to me >> from >> previous maintainer. I admit I have little experience with them and >> do >> not run any service based on them. Because IPSsec is quite complex >> technology, I am looking for help with its maintenance. I was always >> using OpenVPN based solutions myself, so I guess I am not the best >> person as main admin. I would like to transfer main admin to anyone >> doing a good job, not not immediately. That is why I haven't orphaned >> it >> already. >> > We use this at work, could you add these FASes? > - salimma (Michel) > - dcavalca (Davide Cavalca) > > Davide did a PR for strongswan recently. > > Likewise, we don't want to be main admins immediately either, but would > like to help comaintaining. We can channel requests from the internal > team that directly uses it. > > > Best regards, > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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
Offering strongswan for (co)maintaining
Hello, strongswan and NetworkManager-strongswan packages were passed to me from previous maintainer. I admit I have little experience with them and do not run any service based on them. Because IPSsec is quite complex technology, I am looking for help with its maintenance. I was always using OpenVPN based solutions myself, so I guess I am not the best person as main admin. I would like to transfer main admin to anyone doing a good job, not not immediately. That is why I haven't orphaned it already. I would like to keep commit access for a while, but I would share at least commit access with anyone willing to improve those packages. Especially someone using they (almost) everyday would be ideal maintainer. Regards, Petr -- Petr Menšík PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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: Default 'fedora' hostname and failing split DNS VPN
Hi, I would guess your domainname is not (none), and hostname -f value is fedora.domain_failing.tld. One of fixes might be to change hostname of the machine to not contain domains suffix. Then only explicitly configured search would apply. On 3/25/21 2:51 AM, Robert Marcano via devel wrote: > Currently I am connecting to a VPN that provides a few DNS search > entries. One of these domains on the search path is having DNS > resolution problems. This is not per se the the problem I am writing > this email for. > > The problem is that starting Firefox and Thunderbird take a long time, > it took time to detect the DNS resolution problem was the origin of > these timeouts. I am not using that domain that is having resolution > problems. Would dig fedora.domain_failing.tld take long before VPN is estabilished? Does it timeout when connecting or after connected? Timeout might mean some of connection provided servers does not respond or route to it does not work. Even searches should mean just more packets, not visibly longer delay. > > The real culprit is the default `fedora` hostname, instead of localhost. > Starting a Wireshark capture there are DNS searches for > fedora.domain_failing.tld, when starting Firefox and Thunderbird. The > presence of the search path on generated /etc/resolv.conf isn't the > cause of these DNS searches, I edited them out while the VPN was still > active. Try not commenting it out, but override default system value in /etc/resolv.conf: search . > > Even 'ping fedora' start doing these searches with the search paths > appended. 'ping localhost' doesn't do that. The only workaround to this > issue is to add fedora to the localhost entries on /etc/hosts. That would be likely because localhost is in /etc/hosts, read by files in nsswitch. But dns queries (if systemd-resolved is disabled) are configured by /etc/resolv.conf. > > This in some way is a DNS leak, even on a VPN with perfectly working DNS > resolution, the fedora name should not be searched on these domains > until I am using the fedora full hostname on these domains. Even worse > when simply starting applications like Firefox o Thunderbird. Are you sure you do not have hostname set to FQDN? Have you tried setting it to relative name (no dots)? > > Maybe changing the default hostname to fedora wasn't a good idea after > all, or at least fedora should be added to the default /etc/hosts. It should not be necessary unless fqdn is used as a hostname. "fedora" value should be completely ok. But I guess even when connecting to VPN, it should not timeout. DNS settings should be changed only after VPN is connected and ready to forward packets. Are you sure no IP range conflicts with used DNS servers? Cheers, Petr -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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: Fedora's GPG key in DNS(SEC)
On 3/10/21 5:43 PM, Colin Walters wrote: > > > On Wed, Mar 10, 2021, at 7:32 AM, Petr Menšík wrote: >> I think Björn's point is valid note. Because DNSSEC is used to verify >> email of used key, but fedora.repo does not contain any hint about how >> email in GPG key should look like. Also does not contain fingerprint of >> such key. It would be nice to include email of included GPG key in repo >> file itself. If actual email in GPG did not match, dnf would refuse such >> key unless explicitly requested by user. >> >> What if we added to repos: >> gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch >> gpgkeyid=mailto:fedora-$releasever-prim...@fedoraproject.org > > See also https://github.com/rpm-software-management/libdnf/issues/43 - a > massive difference today between /usr/bin/dnf and libdnf-based things (like > rpm-ostree and PackageKit) is that libdnf auto-imports keys without prompting. > > For ostree we added support for doing the same, so that's how our rpm-ostree > based systems work by default (same set of GPG keys). > > There should really be an entirely separate flow for system repos versus 3rd > party. It's just plain dumb for us to prompt the user "Do you trust this > Fedora GPG key" if we already put the RPMs on disk! Agreed. System repositories should have been obtained via GPG signed packages. If we finally fixed periodic gpg key breakage on new release branching, it should have been obtained by trusted way. There should be no need to trust a new release key again manually. > > This is still today worked around in e.g. > https://pagure.io/fedora-kickstarts/blob/main/f/fedora-cloud-base.ks#_110 > for traditional yum/dnf based systems. > > For 3rd party repositories like COPR, as I noted in that issue I think the > best is to bootstrap trust over TLS - e.g. we have > ``` > gpgkeyfingerprint= > ``` How do I check what the correct fingerprint is on my system? How do I check it has not changed? Gpg fingerprint is related only to the single key. It does not allow safe roll of keys. If the key has to change, how can it *automatically* obtain the new fingerprint? DNSSEC and email allows the generation of a new key with the same email, which has trusted chain and can be just validated. New key would be imported if the old is invalid. How would you validate gpgkeyfingerprint? It would have to know authoritative URL to fetch current fingerprint (or the key itself) and compare it to the internal key. Does such url exist? Is it documented somewhere? Fingerprint helps only when installing a new repo. It does not contain signature of repo file, the only way is to trust ALL TLS authorities when fetching it. It would not be possible to supply trusted repo files on mirrors. If both repo and its key(s) are fetched from the same source, verification of fingerprint written in the repo file does not bring any more security IMHO. > > Having the full fingerprint supports fetching the key from anywhere too. Unless the fingerprint can be validated somehow, it creates just a false sense of security. > And the fingerprint+key is fetched via TLS, effectively a trust-on-first-use > style model. This exactly is a problem. You should not be asked to trust it on the first use, if there exists already trusted key chain able to validate it. I guess most people just hit Y once asked to trust a new key, because it is convenient. But unsafe. Regards, Petr -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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: Fedora's GPG key in DNS(SEC)
nd tricked me to download his package. If he signed package
> using brad.guy@malicious.example email. Then DNF will tell me:
>
> Importing GPG key 0x45719A39:
> Userid : "hahah "
> Fingerprint: some thing bad and not matching
> From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-34-x86_64
>
> The package is signed using brad.guy@malicious.example and if he has
> corresponding DNS entry and DNSSEC on malicious.example, then DNF tells me:
> Verified using DNS record with DNSSEC signature.
> I.e. that owner of malicious.example domain say that GPG key for
> brad.guy@malicious.example is correct.
> I would need to be dumb to allow import of brad.guy@malicious.example
> GPG key.
>
> Attacker learned the lesson and he created new GPG pair and he use email
> address fedora-34-prim...@fedoraproject.org. GPG will not stop you. And
> it is okay to have several GPG keys for one email (CentOS does that).
>
> I run dnf again and DNF tells me:
> Importing GPG key 0x45719A39:
> Userid : "Fedora (34) "
> Fingerprint: some thing not correct
> From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-34-x86_64
> Is this ok [y/N]:
>
> The email match. The filename match. Fingerprint? That is long, there is
> no time. It is ok, proceed and voila, I am hacked.
>
> Let's try that with
> gpgkey_dns_verification=1
>
> Importing GPG key 0x45719A39:
> Userid : "Fedora (34) "
> Fingerprint: some thing not correct
> From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-34-x86_64
> NOT verified using DNS record.
> Is this ok [y/N]:
>
> That sounds fishy. I will try to check the fingerprint. But even if I
> proceed. Then every time DNF starts, it will check the DNS entries and I
> will get:
>
> "GPG Key {} could not be verified, because DNSSEC signatures"
> " are bogus. Possible causes: wrong configuration of the DNS"
> " server, MITM attack".format(key.email)
>
>
> This is getting long. What is the conclusion? GPG in DNS is not
> equivalent of **authorization**. It is still up to admin to approve the
> key. And it will not open your system. Not more than it is now.
> GPG in DNS is more equivalent of **authentication**. You will not need
> to compute fingerprint and manually compare it with fingerprint on
> website (or what you are using).
> When the email is f...@domain.com and have DNS(SEC) entry then you can be
> sure that the domain owner confirms the identity of that GPG keys. It is
> up to you whether you will trust the owner of that domain.
>
>
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
OpenPGP_signature
Description: OpenPGP digital signature
___
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: split-DNS, resolvconf on Fedora (OpenVPN related issues)
I don't think it is so easy. It can add facl on resolv.conf file before it drops privileges. But Any other process might remove the file again and write a new one, preventing openvpn to update it later. Because openvpn is not supposed to be owner of /etc/resolv.conf, it should not dictate what rights it needs. For example dnsmasq solves similar problem by forking second process connected by a pipe with original. Original then drops privileges and switches to unprivileged user, just keeping NET_ADMIN to be able reopening privileged ports. When it requires lease changes, it sends request over pipe to process still with enough privileges. Because it does not have any other sockets open to attackers, it just have to check input data sufficiently. I think similar position might have netcfg part. It seems safe enough to keep root privileges to manipulate resolv.conf (or resolvconf). On 3/1/21 2:35 PM, Kevin Kofler via devel wrote: > Petr Menšík wrote: >> It is about 2 years when we were removing CAP_DAC_OVERRIDE from our >> services, because selinux-policy does not grant it anymore. I think it >> is a good thing. Running as openvpn user, but requiring then >> CAP_DAC_OVERRIDE is insecure! It gives it more rights than just root >> users without this permission would have. I would suggest reconsider >> such design and run netcfg as root, just with dropped capabilities >> except CAP_NET_ADMIN, if it needs to modify resolv.conf. resolvconf call >> should not pose significant threat. > > IMHO, the proper fix would be to have a proper facl on resolv.conf for the > openvpn user. > > Kevin Kofler -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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: split-DNS, resolvconf on Fedora (OpenVPN related issues)
On 2/25/21 4:50 PM, David Sommerseth wrote: > Hi! > > On 25/02/2021 14:39, Petr Menšík wrote: > [..snip...] >> >> This case is exactly what I am trying to prevent. There is multiple >> implementations of dns cache, most of them can support split-DNS by some >> configuration. If openvpn supports systemd-resolved natively, does that >> mean it would not be able to support split-DNS on dnsmasq or unbound? >> What is motivation to support specific implementation instead of generic >> interface? I don't want to ask openvpn to support also dnsmasq or >> unbound natively, because I think there should be middle layer support. >> I am trying to use resolvconf as such layer. > > systemd-resolved is already enabled in Ubuntu 18.04 (but not fully) and > now in Fedora 33 (which goes a long way of integration into the system). > > It also provides a D-Bus interface which is reasonable to integrate with. > > This solved use cases we have for customers connecting Ubuntu machines > to OpenVPN Cloud, where DNS is a big part of the Cloud solution. > >> I am dnsmasq, unbound and bind (co)maintainer. I want them to stay first >> class citizens in Fedora, even when they are not installed by default. >> Of course, also knot-resolver and pdns-recursor should be supported, if >> they are (willing and) able to. > > dnsmasq and unbound are great packages as well, but they are not really > designed for system integration in the same level as systemd-resolved > when considering today's ever changing network topology. Just take an > average laptop user today - how many various networks might that user > connect during a day, especially when travelling? I have been using dnssec-trigger, which acts as DNSSEC enabled and unbound split DNS provider for 4 years, also during travels on train. I admit it hit some issues on weird networks, but nothing serious. dnsmasq also has good integration with Network Manager, just use dns=dnsmasq. I disagree they are not ready for laptop users. They both work fine. And both do not block DNSSEC by default like systemd-resolved does. > > Since we have the impression systemd-resolved is becoming more and more > used by default, we figured that would be a reasonable service to > integrate with. It also seems to handle the various use cases of > roadwarriors pretty well as well as virtualised servers. Plus it > provides a reasonable D-Bus API to work with (more on that below). I am not sure it is becoming default for its quality or its push from systemd developers. Sure, it is whole driven by dbus. Dnsmasq has split DNS configuration available from dbus, it just is not enabled by default. None of more serious DNS caches has dbus interface I think. > > OpenVPN 3 Linux aims to run with as least privileges as possible. And > tt tries to integrate with the basic existing network components on the > system. But running with least privileges is a challenge with lots of > the network stack, as it requires some elevated privileges. So > OpenVPN 3 Linux is split up into several components doing a dedicated task. By the way, how would OpenVPN 3 work on windows, where I expect dbus support is missing? Does it have similar equivalent also to systemd-resolved local cache? Can it archieve split DNS? > > == Some OpenVPN 3 Linux architecture details == > > The most privileged service running is the openvpn3-service-netcfg > (net.openvpn.v3.netcfg). This is responsible for creating and configure > TUN interfaces (with or without kernel acceleration), setting up routes > and DNS. But it runs as the openvpn:openvpn user with CAP_NETADMIN. If > using the resolv.conf approach (currently the default, which edits > /etc/resolv.conf directly - which IS nasty), it also adds CAP_DAC_OVERRIDE. It is about 2 years when we were removing CAP_DAC_OVERRIDE from our services, because selinux-policy does not grant it anymore. I think it is a good thing. Running as openvpn user, but requiring then CAP_DAC_OVERRIDE is insecure! It gives it more rights than just root users without this permission would have. I would suggest reconsider such design and run netcfg as root, just with dropped capabilities except CAP_NET_ADMIN, if it needs to modify resolv.conf. resolvconf call should not pose significant threat. > > But we generally try to avoid exec() any external code and depend on > available APIs on the host, whether it is Kernel Netlink, libc related > interfaces or D-Bus. In fact, the script-hooks found in OpenVPN 2.x is > non-existing in OpenVPN 3 Linux. In such situation, calling resolvconf as a helper seems secure enough. I don't see any value in avoiding exec(), when CAP_DAC_OVERRIDE were not first to purge. Please reach to selinux-policy maintainers to discuss the best solution. I think DAC_OVERRIDE sh
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On 2/26/21 12:10 PM, Marius Schwarz wrote: > Am 25.02.21 um 10:51 schrieb Florian Weimer: >> >> Why do you think that? >> >> Caching DNS server availability is a commonly requested feature even in >> data center deployments. The way Fedora currently implements its DNS >> client, it more or less defeats the built-in high availability mechanism >> of DNS, and complex network-based mitigations are needed (like using >> anycast DNS resolvers). > > If you run a server farm with mailservers, you usually have antispam > services like spamhaus enabled. > > If one server from an ip adressrange is using spamhaus, spamhaus is fine > with it. > If a hundret ips from that ip addressrange ask spamhaus, you get blocked > quite fast. Nobody here requested independent iteration from root servers, right? If a machine is caching itself, it would reduce the load to upstream resolver. If local cache forwards cache misses to central DNS cache configured by network administrators, no blocking should ever happen. systemd-resolved or dnsmasq are incapable of independent resolving, they always need upstream iterative resolver doing work for them. Unbound is capable of doing that, but that was not proposed by nobody. Forwarders usage is always expected by default. It might depend on how to choose them only. Local cache is especially useful on DNS intensive service, which SMTP with various spam filters tends to be. Spamhaus wants prevention of unconfigured unbound or bind caches, which would without additional configuration iterate from root servers. Just add forwarders to shared network cache. > > The cache on the server itself, is of limit use here. Thats why you use > a central dns cache on one server, > so anyone benefits from the caching and spamhaus is happy : win-win. > > On a desktop / laptop you won't have such a scenario in the first place, > here local caching makes more sense. Multi layer caching is supported by DNS. Having local cache on the host does not prevent caching also by a big DNS cache for whole network. On the contrary. It is a bit suppressed by DNS over TLS/HTTPS, but default configuration still should obtain DNS from DHCP/autoconfiguration. On servers, clients, VMs and containers. > > best regards, > Marius Schwarz-- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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 2/26/21 9:06 AM, Lennart Poettering wrote: > On Do, 25.02.21 23:58, Petr Menšík (pemen...@redhat.com) wrote: > >> No, I don't think so. Anyone who manages the system should have basic >> understanding how to configure it. If not obvious, needs good >> documentation at hand. Extremely high level is not writing lines into >> configuration file in documented format. I think we switched to nano >> editor to make it friendly. Sure, he won't be able to google help from >> the machine. Fortunately, most of us have got smartphone able to google >> almost anything. > > I am sorry, but I think we have to agree that we are designing > software for a different group of people. I certainly don't want to > assume a level of Linux expertise from our audience that they all can > reconfigure DNS. I think it's a general problem of developers like us > to assume that everyone has the same level of understanding of our > favourite technology as us. i.e. don't assume that because you know > DNS quite well, everyone else does too, or even just heard of DNS at all... I am not sure about it. It is not really different. People missing expertise have to fill bugs or report issues to people with appropriate level of expertise. I would not ask my mum to fix this and she would not even attempt to. She would just complain to me it does not work as it should. Because it does not hide failures, the person with expertise can check the problem and fix it properly. Sure, it will cause interruption. But makes the service more reliable for everyone. Usually auto-configuration is for people without the expertise, I hope we agree in that. > Note that as I understood it the original reporter's issue wasn't even > caused by concious editing of the configuration file, but was done > automatically by some other tool/copy pasted from elsewhere? i.e. it's > a bit much to expect people to understand enough DNS to fix up stuff > manually that other tools broke for them. And the original reporter > is a seasoned a Linux guy, even. The tool was broken by not enough tested change in F33. It should have been found during testing period. Even seasoned Linux guy haven't noticed it was broken until hidden fallback were removed. So again. Broken configuration must appear broken to be fixed. The fix should be prepared by someone with expertise, but they have to receive a bug report first. > > And the idea that "nano" was a flagship of user friendliness sounds, > …umm… a bit strange to me. I mean, maybe it's not as arcane as > vi, but come on it's admittedly just one step down from there. > >> But you forgot some decision were made for the user without his >> knowledge or his approval. That is wrong. > > We make decisions for our users all the time. *All* *the* > *time*. Fedora is a product of developer decisions. > > Lennart > I would just point you to related DNS flag day 2019 [1]. Those guys were pilling workaround over workarounds in DNS server software. After 20 years they have realized it costs a lot of unnecessary work. So, it might may sense to provide workaround, but it should always include plan, when it would be removed again. Sometimes the other party has to be pushed to follow the rules instead of bending our own. Cheers, Petr 1. https://dnsflagday.net/2019/ -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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: [dns-sig] split-DNS, resolvconf on Fedora
On 2/25/21 9:06 AM, Peter Boy wrote: > >> Am 24.02.2021 um 18:18 schrieb Paul Wouters : >> There is no technical reason why this is not in its own package. There >> has been some focussing on reducing minimal installs, and this is a >> prime candidate for that. I'm fine with the workstation or desktop >> installs bringing this package in by default. But I see only potential >> harm from installing it on servers, containers and most virtual machines. > > > You may be right. See https://github.com/systemd/systemd/issues/18761 > > and/or > > https://lists.fedoraproject.org/archives/list/ser...@lists.fedoraproject.org/thread/HOWYMPWHLBB5FDFD5VWLCC5Z73IQWA66/ systemd-resolved has some cool features, but I haven't found a way to configure domain forwarding to selected IP address without a device. Which would match your use-case. Every classic dns cache, dnsmasq used by libvirt included, can forward subdomain queries to selected IPs. I think systemd-resolved is able to configure it only per connection. But it should be possible to use virbr0 device for it inside resolved. resolvectl dns virbr0 192.168.122.1 resolvectl dns virbr0 example.lan I don't know any permanent way to store this information to NM or systemd-resolved, so it would configure it itself next boot. Maybe systemd guys would know a way. -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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
> people to be in after all... Hiding configuration errors just into logs is unfriendly. Ever since Windows 95, very basic network configuration required two steps. Configuring IP address, netmask and one or two DNS servers. Sure, configuration of those basics must be as simple as possible. But if user typed wrong format of address, it always demanded correct format. I consider such approach still valid. Okay, not so simple, when configuring not yet running system. > > (Oh, and I don't appreciate those people at all, who claim that > "resolved sends all DNS lookups" to Google because it's a lie, we > never did that, we only did that in case no better DNS configuration > was available, i.e. as *last* *resort*, one step before giving up > entirely). But no-one asked that user, whether he hates Microsoft, Google or Martians. Fallback setup should be simple, but not automatic. > > Lennart > > -- > Lennart Poettering, Berlin Cheers, Petr -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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
No, this is not true. DNS servers had for ages ability to forward selected domains to specified list of addresses. All DNS caches have the ability to do it for no reason. Servers do not have automatic configuration of split DNS only, because often do not have multiple connections. But I think VPNs could be also used to interconnect networks and selected DNS forwarding might still be benefical for it. However, servers need a proper DNS service. Very often they depend on DNSSEC for mail filtering. They should protect their precious caches with signatures. DNSSEC disabled by default, even when upstream service provides perfectly working DNS, is just failure on our side. Especially on servers, when DNSSEC readines would be much more common than on crappy cheap home routers. Remote DNS does not have to be much slower. If you have dedicated resolver on the same LAN as you, your own cache might not help you much. Depends a lot on specific applications usage. On 2/25/21 4:42 PM, Michael Catanzaro wrote: > On Thu, Feb 25, 2021 at 10:51 am, Florian Weimer > wrote: >> Why do you think that? > > Servers don't need split DNS. Desktops do. Without a DNS cache, your DNS > will be slower. Without split DNS, your DNS may not work properly at all. -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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: split-DNS, resolvconf on Fedora (OpenVPN related issues)
Hi David, more below. On 2/25/21 11:57 AM, David Sommerseth wrote: > On 22/02/2021 16:29, Petr Menšík wrote: >> Why? I thought about common interface to various DNS cache >> implementations for workstations and different VPN providers available. >> While I think the best place to direct, which interface resolvers should >> handle given domains. resolvconf handles conflicting requests from >> different interfaces, when multiple DNS resolver providers are >> configured by connection. > > Just providing some input from the OpenVPN perspective. > > * OpenVPN 3 Linux > > OpenVPN 3 Linux [0] since the v10 release provides native > systemd-resolved support > > It is not optimal yet, but we plan to provide full support for split-DNS > (only pushed domains will be resolved via the DNS server requested by > the VPN server) and exclusive DNS (use only the DNS server pushed by VPN > server). This case is exactly what I am trying to prevent. There is multiple implementations of dns cache, most of them can support split-DNS by some configuration. If openvpn supports systemd-resolved natively, does that mean it would not be able to support split-DNS on dnsmasq or unbound? What is motivation to support specific implementation instead of generic interface? I don't want to ask openvpn to support also dnsmasq or unbound natively, because I think there should be middle layer support. I am trying to use resolvconf as such layer. I am dnsmasq, unbound and bind (co)maintainer. I want them to stay first class citizens in Fedora, even when they are not installed by default. Of course, also knot-resolver and pdns-recursor should be supported, if they are (willing and) able to. > > The current implementation will query all DNS servers on all interfaces. > This hybrid mode will also be supported. > > At the moment I'm not yet decided what should be the default mode, but > I'm leaning towards split-DNS - as that provides the least risk for DNS > leakage either way. But for some any DNS lookups to the main link is > considered a DNS leak as well, so this is highly usage dependent. We > are also considering how far the server can go to push for a certain > profile - as the use cases for VPN provider side are also very diverse > with different requirements. I think it should be configurable from server side with ability to override it on client side. The VPN owner should be able to do specify, whether all queries or only domain-selected queries should go over the VPN. Is it already possible to choose the variant from server side? The default should matter only in case VPN administrator does not care. > > For the v10+ releases you need to do a little configuration step [1] to > enable this support, but we are planning to enable this by default on > Fedora 33+. Ubuntu 20.04 will probably also be updated to use it by > default. This will most likely happen from the v14 release. > > > * OpenVPN 2.x > > We are also considering to fully embrace the update-systemd-resolved [2] > script for the OpenVPN 2.x versions. And will work together with this > project to ensure OpenVPN 3 Linux and OpenVPN 2.x will behave a similar > as possible. Is there a reason, why systemd-resolved's resolvconf does not work for you? Does update-systemd-resolved need more functionality than resolvconf is able to provide? Was the reason missing resolvconf on Ubuntu/Debian? For example, resolvconf -p -a > > * NetworkManger and OpenVPN > > Outside of that, OpenVPN via NetworkManager will be a different beast to > tackle which we have not yet dug into from the OpenVPN project side. > From the OpenVPN side, we are not too happy about the current > NetworkManager plug-in from a general point of view. > > It is good with the graphical interface, but NetworkManager does not > fully consider what OpenVPN is capable and restricts its capabilities > too much in several areas (like killing the OpenVPN process if the main > link disappears; OpenVPN is capable of recovering quite nicely when > network recovers). And we have more OpenVPN specific features planned > as well, where the NetworkManager can cause more damage - as it does not > (and should not) understand how OpenVPN operates. > > * DNS updates > > If NetworkManager is capable of fully integrating with a unified DNS > resolver management which OpenVPN and other updateresolve alternatives > could work with would definitely be the best for all of this. NM can set ipv4.dns-search and ipv4.dns, with ipv6 having this too. My ethernet nmcli shows values from DHCP as IP4.DNS[*] and IP4.DOMAIN[*]. I think that is almost all we need. Set of DNS IPs and list of domains handled by them. Then just a signal of preference, whether to forward all unspecific queries to this connection by d
Re: Fedora's GPG key in DNS(SEC)
On 2/23/21 9:30 AM, Miroslav Suchý wrote: > Dne 22. 02. 21 v 21:11 Petr Menšík napsal(a): >> as a bind-utils maintainer, I have to ask. Why is dig -t TYPE61 used, >> when all stable Fedora supports dig -t OPENPGPKEY just fine. Type61 >> might be used as fallback for older releases > > Because I did not knew that -t OPENPGPKEY can be used. :) No other reason. > Every type it can display on output is accepted also in input. Only types printed as TYPEX, where it does not know them, have to be used with numbered types. It can be emulated by dig +unknownformat for any known type too. -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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
Hi Tadej, thanks for confirmation. On 2/23/21 10:37 AM, Tadej Janež wrote: > Petr, > > thanks for looking into this. > > On Mon, 2021-02-22 at 18:30 +0100, Petr Menšík wrote: >> After a quick glance at cloud-init code, it seems to me it does not >> check /etc/resolv.conf for symlinks. >> >> It just reads /etc/resolv.conf if it is a file, then writes its own >> nameservers into target. I have seen no rm of original >> /etc/resolv.conf, >> so I guess it rewritten target of symlink on Fedora 33: >> /run/systemd/resolve/stub-resolv.conf > > Indeed, cloud-init just "blindly" amends the /etc/resolv.conf file > which is a symlink to /run/systemd/resolve/stub-resolv.conf and hence > gets overwritten by systemd-resolved. > > Here are the relevant snippets from a DigitalOcean instance's > /var/log/cloud-init.log: > > ... trimmed ... > digitalocean.py[DEBUG]: added dns servers: ['67.207.67.2', > '67.207.67.3'] > ... trimmed ... > __init__.py[DEBUG]: Selected renderer 'sysconfig' from priority list: > None > util.py[DEBUG]: Writing to /etc/sysconfig/network-scripts/ifcfg-eth1 - > wb: [644] 212 bytes > util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network- > scripts/ifcfg-eth1 (recursive=False) > util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network- > scripts/ifcfg-eth1 (recursive=False) > util.py[DEBUG]: Writing to /etc/sysconfig/network-scripts/ifcfg-eth0 - > wb: [644] 287 bytes > util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network- > scripts/ifcfg-eth0 (recursive=False) > util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network- > scripts/ifcfg-eth0 (recursive=False) > util.py[DEBUG]: Reading from /etc/resolv.conf (quiet=False) > util.py[DEBUG]: Read 729 bytes from /etc/resolv.conf > util.py[DEBUG]: Writing to /etc/resolv.conf - wb: [644] 846 bytes > util.py[DEBUG]: Restoring selinux mode for /run/systemd/resolve/stub- > resolv.conf (recursive=False) > util.py[DEBUG]: Restoring selinux mode for /run/systemd/resolve/stub- > resolv.conf (recursive=False) > util.py[DEBUG]: Writing to /etc/NetworkManager/conf.d/99-cloud- > init.conf - wb: [644] 89 bytes > util.py[DEBUG]: Restoring selinux mode for > /etc/NetworkManager/conf.d/99-cloud-init.conf (recursive=False) > util.py[DEBUG]: Restoring selinux mode for > /etc/NetworkManager/conf.d/99-cloud-init.conf (recursive=False) > util.py[DEBUG]: Writing to /etc/udev/rules.d/70-persistent-net.rules - > wb: [644] 192 bytes > util.py[DEBUG]: Restoring selinux mode for /etc/udev/rules.d/70- > persistent-net.rules (recursive=False) > util.py[DEBUG]: Restoring selinux mode for /etc/udev/rules.d/70- > persistent-net.rules (recursive=False) > ... trimmed ... > >> I think there are two possible fixes: >> * cloud-init would check the symlink and target of etc/resolv.conf. >> If >> it points to /run/systemd/resolve/*, write DNS=x y into >> /etc/systemd/resolved.conf.d/*cloud-init.conf > > I think this option would be preferred. > >> * clound-init would always delete etc/resolv.conf before it writes >> into >> it, if it was symlink. > > I guess this is a simple solution that would work, but from what I > understand it would also disable the use of systemd-resolved? Well, partially. It wouldn't disable systemd-resolved service, but would not direct DNS messages to resolved. It would still cache requests done via nss, typically via getaddrinfo() or gethostbyname() function. That was intention of cloud-init anyway. Personally I would prefer cache on the host instead of in each container. > >> * systemd-resolved would check contents of link target of >> /etc/resolv.conf on startup. If it leads to systemd, try parsing its >> contents. If it does not look like managed contents of systemd, >> assume >> it might be misdirected resolv.conf configuration. Store it and wait >> for >> DHCP configuration. If no better configuration arrives, use >> nameservers >> from misdirected file. Would have to restore original resolv.conf on >> shutdown to keep working after restarts. Should move it to >> fallback.conf >> and use it instead of built-in fallbacks? > > This seems too complex and error prone. > > Regards, > Tadej It could just always move file without its own header to /run/systemd/resolved/fallback.conf (or maybe some permanent). When no better configuration was set, use this file as nameservers source, instead of built-in defaults. It would omit saving that files. Sure, this part is more complex. But only this part can fix this problem from inside the container IMO. Ie. we could fix it faster for any involved parties. I don't really run any container on any cloud serv
Re: [dns-sig] Re: split-DNS, resolvconf on Fedora
On 2/22/21 9:12 PM, Lennart Poettering wrote: > Quite frankly, I am not sure it would be a good idea to do things that > way. > > note that resolved should be fine as a resolvconf replacement, even if > you don't want to use it as a resolver: just set the /etc/resolv.conf > symlink to /run/systemd/resolve/resolv.conf (instead of the usual > /run/systemd/resolve/stub-resolv.conf) and you get the upstream > servers listed there, as any other resolvconf implementation would do > it. I am aware it can work like that. But it still requires systemd-resolved to be enabled, while it does nothing more than listening for interface events. Even when some other DNS cache running on localhost. Openresolv can provide also split-dns configuration for dnsmasq, unbound, named, powerdns (recursor). Or just no local cache, in size 64k. > > The thing is, there's a bunch of software these days that can talk to > to resolved's D-Bus interface to set DNS servers and such. You lose > all that if you insist that systemd-resolved is so terrible that you > cannot even use it as a resolvconf reimplementation, that is more than > a bunch of shell scripts. I never proposed D-Bus API. I think DNS (RFC 1035) works well enough to provide name resolution. I would recommend DNS library instead of proprietary D-Bus API personally. I am trying to find common solution with ability to support different implementations. Implementing common D-Bus protocol in every cache seems unrealistic to me. Common interface able to pass domains and addresses tuples seems possible with resolvconf, with minimal overhead or added complexity. > > Another option might be > https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/ btw. > > Lennart > > -- > Lennart Poettering, Berlin I know about alternatives. I would kindly point you to filled bug #1923727 [1], which already requests Alternatives support from systemd. Openresolv already supports it [2]. Problem with alternatives is, it can handle quite poorly situation, where both openresolv and systemd-resolved are removed or disabled. Let's take for example file from openvpn package: /usr/share/doc/openvpn/contrib/pull-resolv-conf/client.up Close to the end is resolvconf handling. I would like something similar to be part of installed packages, for example dhcp-client. It should handle states: - systemd-resolved enabled and active (default configuration), providing split- DNS - dnsmasq + openresolv configured, providing split-DNS * no local cache running and no resolvconf enabled Problem is with *starred* option. How to tell packages to handle resolv.conf manually? How to update /usr/sbin/dhclient-script, function change_resolv_conf()? How can I use alternatives and check resolvconf is enabled? And keep it simple and maintainable in various VPN providers? Openvpn variant is simple and elegant, but requires ability to remove resolvconf, when not used. Current systemd does not pass such requirement. 1. https://bugzilla.redhat.com/show_bug.cgi?id=1923727 2. https://src.fedoraproject.org/rpms/openresolv/blob/rawhide/f/openresolv.spec#_56 -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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: Fedora's GPG key in DNS(SEC)
Hi, as a bind-utils maintainer, I have to ask. Why is dig -t TYPE61 used, when all stable Fedora supports dig -t OPENPGPKEY just fine. Type61 might be used as fallback for older releases On 2/12/21 8:22 PM, Miroslav Suchý wrote: > All Fedora's GPG key - starting with Fedora 27 - are now stored in > fedoraproject.org DNS record and can be verified using DNSSEC. > > Why? How it can be used? That is long story and you can read about it in > my blog entry: > > http://miroslav.suchy.cz/blog/archives/2021/02/11/verify_package_gpg_signature_using_dnssec/index.html > > > Few last minutes notes here: > - there are still some gotchas which should be fixed. But enough code > is already in production - you can play with it now. Relevant issues are > linked in the blog post. > - the DNF team is migrating their code to libdnf, I do not have any > guarantee when this piece of code will be migrating - so we are far from > enabling this by default. > > Comments are welcomed. -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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
After a quick glance at cloud-init code, it seems to me it does not check /etc/resolv.conf for symlinks. It just reads /etc/resolv.conf if it is a file, then writes its own nameservers into target. I have seen no rm of original /etc/resolv.conf, so I guess it rewritten target of symlink on Fedora 33: /run/systemd/resolve/stub-resolv.conf I think there are two possible fixes: * cloud-init would check the symlink and target of etc/resolv.conf. If it points to /run/systemd/resolve/*, write DNS=x y into /etc/systemd/resolved.conf.d/*cloud-init.conf * clound-init would always delete etc/resolv.conf before it writes into it, if it was symlink. * systemd-resolved would check contents of link target of /etc/resolv.conf on startup. If it leads to systemd, try parsing its contents. If it does not look like managed contents of systemd, assume it might be misdirected resolv.conf configuration. Store it and wait for DHCP configuration. If no better configuration arrives, use nameservers from misdirected file. Would have to restore original resolv.conf on shutdown to keep working after restarts. Should move it to fallback.conf and use it instead of built-in fallbacks? 1. https://github.com/canonical/cloud-init/blob/66e2d42dd1b722dc8e59f4e5990cea54f81ccd2a/cloudinit/net/sysconfig.py#L909 On 2/22/21 4:45 PM, Michael Catanzaro wrote: > 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 -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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: [dns-sig] Re: split-DNS, resolvconf on Fedora
Wouldn't it be much simpler, if I could just dnf remove systemd-resolved in case I don't want it? Then I don't have to make a proxy, but install indeed a different package providing resolvconf. I think I would submit that PR on Fedora package instead. Or don't have any /usr/sbin/resolvconf, in which case openvpn or dhclient knows it should try to rewrite /etc/resolv.conf itself. Unless driven by NM or similar. Init system and dns cache have very different requirements in system integration. On 2/22/21 4:38 PM, Lennart Poettering wrote: > On Mo, 22.02.21 16:29, Petr Menšík (pemen...@redhat.com) wrote: > > It might be OK for systemd's resolvectl to pass the call on to some > other executable if it notices resolved is not there. We do the same > in the "telinit" tool, so that Debian can have multiple init systems, > and when ours owns the "telinit" name, but the system is not actually > booted with systemd we can propagate the call to some other tool. > > Happy to review a patch for that (submit upstream) > > Lennart > > -- > Lennart Poettering, Berlin > ___ > dns-sig mailing list -- dns-...@lists.fedoraproject.org > To unsubscribe send an email to dns-sig-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/dns-...@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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
split-DNS, resolvconf on Fedora
Hi, I have submitted new package openresolv [1], which provides resolvconf tool, similar to Debian's resolvconf package. Why? I thought about common interface to various DNS cache implementations for workstations and different VPN providers available. While I think the best place to direct, which interface resolvers should handle given domains. resolvconf handles conflicting requests from different interfaces, when multiple DNS resolver providers are configured by connection. Current Fedora 33 already has /usr/sbin/resolvconf provided by systemd-resolved. It provides split-DNS implementation in default Fedora installation[2]. Problem is this is useful only in case systemd-resolved service is running and used. When it is disabled, its resolvconf just fails. But because systemd-resolved does not have its own subpackage, the daemon can be only disabled, not uninstalled. My question is, how should dhclient or vpn provider check resolvconf is installed and enabled? It usually checks [ -x /usr/sbin/resolvconf ] in Debian from shell, but because resolvconf is always present on Fedora, it cannot work. Unlike Debian, where systemd does not provide resolvconf. How could it therefore check, how should be /etc/resolv.conf updated? How would dhclient know, when to rewrite /etc/resolv.conf itself or when to use resolvconf for coordinated changes? I think Network Manager should manage DNS domains list per connection IMO. But in cases VPN provider is not configured via NM or NM is not even used, I think resolvconf is good alternative to set and restore the system's /etc/resolv.conf, when any VPN service is started. Only systemd-resolved and dnsmasq can support split-DNS from NM. openresolv is written only in shell, has no other dependencies. It could support multiple DNS implementations as a local cache[3]. It currently breaks systemd's symlink /usr/sbin/resolvconf, it uses alternatives links. But systemd package does not use it, so after uninstallation of openresolv, resolvconf remains broken. I think this has to be solved by systemd package. Do you have any opinion, how should resolvconf be supported on Fedora? Any opinion against it? 1. https://src.fedoraproject.org/rpms/openresolv 2. https://fedoraproject.org/wiki/Changes/systemd-resolved#Split_DNS 3. https://roy.marples.name/projects/openresolv/configuration/ -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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 2/22/21 11:17 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Feb 22, 2021 at 10:58:09AM +0100, Tadej Janež wrote: >> Hi, >> >> I would like to question the decision that was made by systemd >> maintainers to remove the fallback DNS server list: >> https://src.fedoraproject.org/rpms/systemd/c/14b2fafb3688a4170a9c15235d1c3feb7ddeaf9d >> >> And then backported to F33: >> https://src.fedoraproject.org/rpms/systemd/c/ed795fb1fc9a2c20ebcac34bdf7e7c7ae17322a2?branch=f33 >> >> On F33, this actually breaks a working vanilla cloud instance by >> removing the fallback DNS server list in a systemd upgrade, effectively >> leaving the system with no DNS servers configured. >> >> I described this in more detail here: >> https://lists.fedoraproject.org/archives/list/cl...@lists.fedoraproject.org/thread/72MRKIFGPMFGBS7XJ5T5I23NVDXXWVGR/ >> >> Zbigniew Jędrzejewski-Szmek wrote the following in the commit message >> accompanying the fallback DNS server list removal: >> >>> So hopefully users will not see any effect from the change done in >>> this patch. Right now I think it is better to avoid the legal and >>> privacy risk. If it turns out this change causes noticable problems, >>> we might want to reconsider. In particular we could use the fallback >>> servers only in containers and such which are not "personal" machines >>> and there is no particular person attached to them. >> >> I would argue that the change causes noticeable problems and we want to >> reconsider this change. >> In particular, I think cloud image users would prefer to have their >> cloud instances usable out of the box, i.e. have DNS working out-of-the >> box. >> >> Don't get me wrong, I understand the privacy concerns and I think >> Fedora should strive to protect the privacy of its users as much as >> possible, but at the same time, the circumstances of a cloud instance >> are probably very different from a e.g. workstation instance. >> >> Possible solutions that come to mind: >> >> 1) Use different defaults for different Fedora editions, e.g. container >> and cloud images include the fallback DNS servers list while >> workstation (and similar) images don't. > > Yes, I think this would be the way to go. Cloud images already have > special configuration to invoke the "cloud init" services. They could > just as well add a drop-in in /usr/lib/systemd/resolved.conf/ with > FallbackDNS=. It would be even better to make sure that the cloud > config sets some appropriate dns servers in all cases. Problem with fallback is, you never know when they are appropriate. I think it should be possible to configure container without DNS access at all. It should depend on deployment configuration, not on fallback. It should obey configuration and notify user, when configuration is wrong. He should not realize that only when fallbacks were removed. > >> 2) Pick a reputable DNS resolver that preserves users' privacy and >> doesn't log anything and configure it as a fallback DNS server. >> Here is a good summary of DNS resolvers and their privacy: >> https://privacytools.io/providers/dns/#dns > > I don't think this is feasible. The laws put a lot of emphasis on > location (i.e. that the data is not processed by outside entities). > So an even perfectly good privacy-respecting provider might not be > acceptable in some locations (there's at least EU, Brazil, Japan that > have GDPR-like rules…). I don't think we want to analyze the situation > to figure out whether some provider is acceptable everywhere even once, > and promising to do that continuously as things change would be even > worse. > > 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 on the list, report it: > https://pagure.io/fedora-infrastructure > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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
Hi Tadej, I think more effort should be put to configure the instance correctly by provider. No default should save invalid configuration of container host. I think there is actually little benefit in systemd-resolved usage in a container. I would guess the container host would run proper dns cache for all its containers, sharing the cache between them. Why does it run its own cache inside? I think systemd-resolved should not be used on container at all. It needs to forward queries to any address configured by the host. It should even not be installed by default in container, could it be split to systemd-resolved package? Do you know, what are all steps done by cloud-init? Did it try to write its own /etc/resolv.conf? When it disables dns=none in NM, I guess it tried to setup static resolv.conf. Is it possible that writes went to symlink target in /run/systemd/resolve and they were overwritten later? We have to find good way to configure DNS in all releases the proper way. Don't rely on fallbacks. If you had non-working configuration from the start and relied on fallback, I think this should be fixed. If configuration were provided but did not work, it should fail hard, let you notice it. I think most daemons do that already. Is there any "standard" way to configure DNS in deployed containers? I use DHCP myself, but have only containers for development. Cheers, Petr On 2/22/21 10:58 AM, Tadej Janež wrote: > Hi, > > I would like to question the decision that was made by systemd > maintainers to remove the fallback DNS server list: > https://src.fedoraproject.org/rpms/systemd/c/14b2fafb3688a4170a9c15235d1c3feb7ddeaf9d > > And then backported to F33: > https://src.fedoraproject.org/rpms/systemd/c/ed795fb1fc9a2c20ebcac34bdf7e7c7ae17322a2?branch=f33 > > On F33, this actually breaks a working vanilla cloud instance by > removing the fallback DNS server list in a systemd upgrade, effectively > leaving the system with no DNS servers configured. > > I described this in more detail here: > https://lists.fedoraproject.org/archives/list/cl...@lists.fedoraproject.org/thread/72MRKIFGPMFGBS7XJ5T5I23NVDXXWVGR/ > > Zbigniew Jędrzejewski-Szmek wrote the following in the commit message > accompanying the fallback DNS server list removal: > >> So hopefully users will not see any effect from the change done in >> this patch. Right now I think it is better to avoid the legal and >> privacy risk. If it turns out this change causes noticable problems, >> we might want to reconsider. In particular we could use the fallback >> servers only in containers and such which are not "personal" machines >> and there is no particular person attached to them. > > I would argue that the change causes noticeable problems and we want to > reconsider this change. > In particular, I think cloud image users would prefer to have their > cloud instances usable out of the box, i.e. have DNS working out-of-the > box. > > Don't get me wrong, I understand the privacy concerns and I think > Fedora should strive to protect the privacy of its users as much as > possible, but at the same time, the circumstances of a cloud instance > are probably very different from a e.g. workstation instance. > > Possible solutions that come to mind: > > 1) Use different defaults for different Fedora editions, e.g. container > and cloud images include the fallback DNS servers list while > workstation (and similar) images don't. > > 2) Pick a reputable DNS resolver that preserves users' privacy and > doesn't log anything and configure it as a fallback DNS server. > Here is a good summary of DNS resolvers and their privacy: > https://privacytools.io/providers/dns/#dns > > Thoughts? > > Regards, > Tadej > > P.S. I'm subscribed, but please keep me in Cc so I'll notice replies > sooner. > > > ___ > 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 > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fed
Re: koji save-failed-tree enabled
Hi Kevin, is there specific reason, why scratch builds cannot do it? I met hard to reproduce issues in builds several times. I would prefer to analyse scratch builds instead of production builds. Could for example just single per-user scratch build archive be stored for some short time? Might be just a day or so. It might be useful to add some tweaks and retry. Keeping previous scratch build is not needed, but ability to extract information from non-production builds seems vital to me. Keeping record of failed production builds, which will stay there forever, does not look good to me. Cheers, Petr On 2/11/21 8:27 PM, Kevin Fenzi wrote: > Greetings. > > We have enabled the koji 'save-failed-tree' plugin in > koji.fedoraproject.org. This plugin allows you to tell koji to bundle up > a failed official builds chroot (either partly or fully) and download it > to investigate it locally. > > This plugin should only be used for the case where you cannot determine > the cause of a build failure by any other means and need to examine > specific files in the chroot to do so. > > A few things to note: > > * This will only work on failed official builds that have failed > recently enough to still have their chroot on the builder where they > failed (default: 1 day) Not scratch builds. Not canceled builds. > The chroot downloads are REALLY LARGE. Please use this sparingly. > > * This will only work on buildArch tasks, not images, etc > > * Saved tree .tar.gz's are deleted from koji after 14 days. > > * You need to have python3-koji-cli-plugins subpackage installed to use > the command. > > * You run the command as: koji save-failed-tree > > I hope that this will be of use to help maintainers track down hard to > isolate bugs when all other means fail. > > kevin > > > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to devel-announce-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-annou...@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 > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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: Fedora 34 Mass Branching
Hi, I were unable to find time in the schedule, at which the new F35 GPG key would be activated to sign new builds. In order to prevent bug 1872248 [1], new key must not be used until all stable releases got new key with symlinks for all supported arches. New builds were done few days ago, f33 is already in stable [2]. Yet it is again incomplete and unusable. If the new key is activated now, it would break (again!) gpg validation of rpm updates. Please tell me I am missing something. I tried to help with fixing this state, yet my PR[3] are still not merged. Could be new GPG key activation explicitly mentioned in the schedule? Isn't it also the key step? So, how does Rawhide choose GPG key to sign built packages? Would it break (again) today? Regards, Petr 1. https://bugzilla.redhat.com/show_bug.cgi?id=1872248 2. https://bodhi.fedoraproject.org/updates/FEDORA-2021-d17f7e917c 3. https://src.fedoraproject.org/rpms/fedora-repos/pull-requests On 2/8/21 5:39 PM, Mohan Boddu wrote: > Hello All, > > Fedora 34 will be branched from rawhide on Feb 09th 2021 as per the > Fedora 34 schedule[1]. The process takes about a day and everything > should be ready by Feb 10th 2021. You can still be able to build > packages normally until then, but after the mass branching, rawhide > and F34 will be separated. > > We will send another email once the branching is done. > > Thanks, > Mohan Boddu. > > [1] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html > ___ > 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 > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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: Proposal to deprecated `fedpkg local`
Hi, This would describe my usual workflow as well. fedpkg local is great for checking soname did not change, patches apply, to debugging why my test suites fail and how they behave. mock usual does not have even vim, let alone gdb or something better. In other words, i use fedpkg local a lot and would miss it much. I understand what mockbuild is for, but for any iterative improvements done to my package, fedpkg local is much better. Don't remove it, please. Especially in bind, which includes latex documentation building, are installed dependencies slowing one iteration significantly. On 1/27/21 5:43 PM, Daniel P. Berrangé wrote: > On Wed, Jan 27, 2021 at 05:27:12PM +0100, Fabio Valentini wrote: >> On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel >> wrote: >>> >>> It's needed for testing builds against versions of packages not yet in >>> mock. I use it almost every day. Losing it would make things like testing >>> solib bumps harder. >> >> I've done local test builds for soname bumps and similar things lots >> of times, and I've never used (or thought about using) fedpkg local >> for that. >> I used "mock --chain" or a combination of "mock --postinstall >> --no-clean" for those builds ... which is much closer to what koji >> will do with your builds, and gives every build the clean environment >> it deserves >:-) > > If you want to closely replicate that koji will do, then no disagreement > that use of mock is the right tool (or just a koji scratch-build). That > just isn't a requirement much of the time though. > > For adhoc development and debugging of RPM spec changes/updates, mock > gets in the way and slows things down. I could easily do 10-20 "local" > runs while getting an complex change working, and then finish off with > just one or two mock build or koji scratch-build to validate it in a > pristine build root env at the end. > > > Regards, > Daniel > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git
On 1/27/21 2:22 PM, Miro Hrončok wrote: > On 27. 01. 21 13:45, Petr Menšík wrote: >> I think one reason against maintainer's pull requests is poor tooling to >> work with them. Filled fedpkg proposal to include ability to fork and >> add personal fork to current repository or add when cloning [1]. >> I think current way discourages its use, because too many manual steps >> have to be done before making PR. >> >> 1. https://bugzilla.redhat.com/show_bug.cgi?id=1920997 >> >> On 1/25/21 4:30 PM, Miro Hrončok wrote: ... >> >> Is there already way to configure maintainer's fork branch to auto merge >> and production build, once CI finishes successfully? >> >> I think adding required steps into build process, where developer has to >> watch for results and make manual steps is the problem. If I could just >> push my change to my fork and let it autoprocess, I would use it when >> not in hurry. But I demand first not involving multiple manual steps to >> make production built from PR. >> >> Could there be way as a maintainer to add a comment [build] to merged >> PR, and pagure would start a new build? I think it does not matter who >> started the build, but whose changes are included. >> >> If I could just mark good looking changes and it would try to process >> it, just notifying me whether successfully or not, I would use PR more >> often. If I have to watch PR CI results myself and do manual steps >> depending of its result, it discourages me. Would like some bot to do >> that. >> >> There seems to be support for [citest] for retriggering CI on package. >> Could something similar be used to autobuild PR of people with commit >> rights on explicitly enabled branches? > > Zuul can merge and build PRs automatically when CI passes. > > https://fedoraproject.org/wiki/Zuul-based-ci > Great! Never heard of this. It seems somehow clumsy to be configured just for personal forks, but it seems it provides required features. Configuration seems more complicated than I would like, but I will try to use it for some proof of concept. Thanks for mentioning it. -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git
I think one reason against maintainer's pull requests is poor tooling to work with them. Filled fedpkg proposal to include ability to fork and add personal fork to current repository or add when cloning [1]. I think current way discourages its use, because too many manual steps have to be done before making PR. 1. https://bugzilla.redhat.com/show_bug.cgi?id=1920997 On 1/25/21 4:30 PM, Miro Hrončok wrote: > On 25. 01. 21 16:19, Stephen Gallagher wrote: >> I'm fully in favor of this and I'd really like to see us add some >> degree of CI gating to support it. > > Note that unfortunately CI gating happens too late. It has no capability > to block commits that fail to build, because it only tests successful > builds and because it only tests already pushed changes. CI on Pull > Requests can solve this, but many packagers seem to be very much agianst > the idea of sending PRs to packages they maintain themselves :( > Is there already way to configure maintainer's fork branch to auto merge and production build, once CI finishes successfully? I think adding required steps into build process, where developer has to watch for results and make manual steps is the problem. If I could just push my change to my fork and let it autoprocess, I would use it when not in hurry. But I demand first not involving multiple manual steps to make production built from PR. Could there be way as a maintainer to add a comment [build] to merged PR, and pagure would start a new build? I think it does not matter who started the build, but whose changes are included. If I could just mark good looking changes and it would try to process it, just notifying me whether successfully or not, I would use PR more often. If I have to watch PR CI results myself and do manual steps depending of its result, it discourages me. Would like some bot to do that. There seems to be support for [citest] for retriggering CI on package. Could something similar be used to autobuild PR of people with commit rights on explicitly enabled branches? -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git
What about ability to opt-in into %prep checking on push? Could we add some new rules to gating.yaml for example, allowing few checks on push? Most of package I manage are tiny or small, prep check should not take longer than 10s on most of them. I made mistake of omitting patch our source file multiple time. Could similar check be enabled either by dist-git file or project settings on package sources? I never did any check, but I think the most of packages are quite small. How many packages could have significant size of sources? If we have opt-in first and opt-out for large packages later, would it work? On 1/26/21 6:32 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Jan 26, 2021 at 03:59:18PM +, Jonathan Wakely wrote: >> On 25/01/21 19:58 +0100, Miro Hrončok wrote: ... >> >> Not for the first time, I wonder why we don't have a git server hook >> that rejects a push if it fails %prep. For large packages the %prep is >> too slow, but we could at least check for the common mistake of adding >> a patch to the .spec and forgetting to git add the actual .patch file. >> Why do we allow that, instead of just refusing the push? >> >> Does anybody have a valid reason to want to be able to push a .spec >> that refers to a missing .patch file? Surely it's always an accident >> (as happened with libreoffice last week) and we should use tooling to >> help us avoid such accidents? > > I don't think we should do a full %prep (because that sometimes sources > can be huge and people do some preprocessing in %prep that might take > a few minutes). But we should check that Source* and Patch* is defined > and the spec file is syntactically valid. This would go a long way towards > avoiding stupid mistakes, without significant cost. > > Zbyszek > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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: Artifacts of failed builds for debugging
Thanks for the tips. I eventually narrowed errors to just NUMA builders, and confirmed that once borrowed multicore machine from RH. Turned out the problem is internal to BIND only, reported under MR [1]. It is problematic to hide details on kyua unit testing. Unit tests are built using cmocka and can print nice output. Unfortunately it uses kyua to group multiple results and that tool hides any details. Without easy way to provide them. Not sure which tool should be updated, kyua is the best candidate for more detailed output. It should be always easy to make building more verbose, especially in such weird errors. Thanks for help. 1. https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4582 On 1/19/21 5:32 PM, Vít Ondruch wrote: > It is tedious, but you can try gdb in batch mode, e.g.: > > ~~~ > gdb /usr/bin/ruby-mri -batch \ > -ex 'set breakpoint pending on' \ > -ex 'r -Ilib:test -e '\''Dir.glob %|./test/**/*_test.rb|, > (:require)'\'' -- -v' \ > -ex 'bt full' \ > -ex c \ > -ex 'bt full' \ > -ex quit > ~~~ > > (and of course modify this to fit your use case). > > > Vít > > > Dne 18. 01. 21 v 23:22 Petr Menšík napsal(a): >> Hello, >> >> I am trying to build new bind on Rawhide, but I suddenly get quite high >> rate of failures during builds. Strange is the build is always >> successful, when I try fedpkg mockbuild on my machine. >> >> I tried several tries [1][2][3] and scratch builds fail often. Even >> production builds fail, but I think they haven't failed until recently. >> I were unable to reproduce it at least once in mockbuild. >> >> Is it possible to record crashes during builds using abrt or faf? Is >> there way to obtain more details of failed builds? Is there anything >> similar to mockbuild --no-cleanup-after, which could help me identify >> the cause? >> >> Do you have any hints? I tried deleting /var/lib/mock and >> /var/cache/mock, but that haven't changed anything. COPR [4] haven't >> failed also. >> >> Regards, >> Petr >> >> 1. https://koji.fedoraproject.org/koji/taskinfo?taskID=59974310 >> 2. http://koji.fedoraproject.org/koji/taskinfo?taskID=59985548 >> 3. http://koji.fedoraproject.org/koji/taskinfo?taskID=59985586 >> 4. >> https://copr.fedorainfracloud.org/coprs/pemensik/bind-9.16/build/1886936/ >> >> ___ >> 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 >> > > > ___ > 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 > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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
Artifacts of failed builds for debugging
Hello, I am trying to build new bind on Rawhide, but I suddenly get quite high rate of failures during builds. Strange is the build is always successful, when I try fedpkg mockbuild on my machine. I tried several tries [1][2][3] and scratch builds fail often. Even production builds fail, but I think they haven't failed until recently. I were unable to reproduce it at least once in mockbuild. Is it possible to record crashes during builds using abrt or faf? Is there way to obtain more details of failed builds? Is there anything similar to mockbuild --no-cleanup-after, which could help me identify the cause? Do you have any hints? I tried deleting /var/lib/mock and /var/cache/mock, but that haven't changed anything. COPR [4] haven't failed also. Regards, Petr 1. https://koji.fedoraproject.org/koji/taskinfo?taskID=59974310 2. http://koji.fedoraproject.org/koji/taskinfo?taskID=59985548 3. http://koji.fedoraproject.org/koji/taskinfo?taskID=59985586 4. https://copr.fedorainfracloud.org/coprs/pemensik/bind-9.16/build/1886936/ -- Petr Menšík Software Engineer, Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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: protobuf 3.14 update coming to rawhide
Hi Adrian, I would like to rebuild new BIND 9.16, once this tag is merged. I guess building significant rebase into your tag is not welcome. Is there any ETA, when it could be merged? Could you please send me a mail, once it is merged? Is there any bug for the rebase I can watch? Thanks, Petr On 1/15/21 10:28 AM, Adrian Reber wrote: > On Fri, Jan 15, 2021 at 10:15:11AM +0100, Dan Čermák wrote: >> Adrian Reber writes: >> >>> On Thu, Jan 07, 2021 at 10:18:37AM +0100, Adrian Reber wrote: >>> >>> All rebuilds are done, but I have not merged the side tag yet. >> >> What's the name of the side tag? > > Right, I should have mentioned that: f34-build-side-35763 > > Adrian -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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: Unannounced soname bump: ldns
On 1/4/21 12:38 PM, Miro Hrončok wrote: > On 04. 01. 21 12:26, Petr Menšík wrote: >> I had not time to coordinate rebuilt before Christmas, so I left it >> intentionally without build. It was built by Jeff Law one day before I >> departed to vacation. I haven't noticed that. > > As a matter of opinion (i.e. this is not a policy, but my own views), I > think that the state of distgit should always be "good" and any > provenpackager should safely assume that rebuilding any package does not > cause damage. > > If I need to rebuild many packages because of a dependency, I should not > need to explore if the latest commits are "ready". A work in progress > should be left in a pull request. > > Obviously, this does not always work, because sometimes change in > distgit is necessary for a rebuild from a side tag, but in most cases I > think we should avoid both "I've pushed a breaking upgrade but I > haven't built it" or "I've pushed a broken commit and will push more > later" approaches. > > WDYT? > I thought it was ready and there were no scheduled mass rebuild. ldns usually does not even receive bugs for months, let alone need for immediate build change. I even made a mistake and haven't added sources to upgrade. It should have ended with FTBFS bug instead of broken compose. I did that to save version bumping later, just to have it backed up somewhere. I admit I don't do MR to myself often, thought it was not necessary. I did not expect anyone would have need to touch it for a few weeks. No one touched it whole year and I relied on that. Is there tooling to help with rebases of changelog conflicts? If leave it in my branch and someone bumps the spec, can I make just git rebase equivalent without manual conflict solving? Some git commit message tag or something similar to help make bumps on merge? It is a little of work, but annoying. Is there existing automation for it? Makes MR outdated on any spec change and not too usable. -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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: Unannounced soname bump: ldns
I am sorry for that. I had not time to coordinate rebuilt before Christmas, so I left it intentionally without build. It was built by Jeff Law one day before I departed to vacation. I haven't noticed that. Jeff, were there any specific reason behind your build? It would be nice, if you tried to ping me on IRC first. I think I were still there. I have no commit access to 3 dependencies, I left it after New Year to be coordinated with others. It is fixed now by Adam, thank you for fixing it. On 12/19/20 6:10 PM, Adam Williamson wrote: > A new build of ldns was done for Rawhide yesterday by law/pemensik: > > > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1660180 > > This build changes the soname of libreport from libldns.so.2 to > libldns.so.3. > > This bump was not announced AFAICS, and none of its several > dependencies appear to have been rebuilt: > > dnsperf-0:2.4.0-2.fc34.x86_64 > dnssec-trigger-0:0.17-1.fc34.x86_64 > flamethrower-0:0.11.0-1.fc34.x86_64 > ldns-devel-0:1.7.0-32.fc33.x86_64 > ldns-utils-0:1.7.0-32.fc33.x86_64 > libreswan-0:4.1-3.fc34.x86_64 > netresolve-backends-aresdns-0:0.0.1-0.28.20160317git.fc33.x86_64 > netresolve-backends-avahi-0:0.0.1-0.28.20160317git.fc33.x86_64 > netresolve-backends-compat-0:0.0.1-0.28.20160317git.fc33.x86_64 > netresolve-backends-ubdns-0:0.0.1-0.28.20160317git.fc33.x86_64 > netresolve-compat-0:0.0.1-0.28.20160317git.fc33.x86_64 > netresolve-core-0:0.0.1-0.28.20160317git.fc33.x86_64 > netresolve-tools-0:0.0.1-0.28.20160317git.fc33.x86_64 > nordugrid-arc-plugins-needed-0:6.9.0-1.fc34.x86_64 > opendnssec-0:2.1.7-1.fc34.x86_64 > python3-ldns-0:1.7.0-32.fc33.x86_64 > > This broke today's Rawhide compose due to a KDE dependency chain that > involves libreswan: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=57780927 > > Please remember to announce soname bumps ahead of time and arrange > rebuilds of dependencies so this kind of problem can be avoided. > Thanks. I will try and rebuild things, at least compose-critical > things, now, but if straight rebuilds don't work might need people to > help out. > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ 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 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)
On 11/17/20 10:12 AM, Lennart Poettering wrote: > On Mo, 16.11.20 21:48, Petr Menšík (pemen...@redhat.com) wrote: > >> But it does not have to learn everything about a server, because it >> switched the active one. If it has to, try to find way to store server >> instance features per server IP, not per link. > > We do exactly this. But we also have a grace period after which we > forget everything again, and go back to the best server feature level again, > which then takes some time to settle back on the actual server feature > level. I think smart RTT checking every few minutes would be better, than forgetting everything about server always responding quickly. > > When we always use the same server, then we probe it once, and use it > for the full grace period without any further delays. When we use > numerous servers, and a different one for each lookup, then this means > we have to probe each and every single one of them once and that slows > down things. You can cache average response time for the server. If answer did not arrive in triple or usuall RTT, send to other servers too. It should not be done for each request. Depends on how long grace period, right? > > It's a very easy calulation: if you use n=1 servers for 500 lookups > within the grace period, you experience 1 slow lookup in the worst > case that required the feature probing, plus 499 speedy lookups > because we already knew the earlier probing results. If otoh you use > n=250 servers for 500 lookups you experience 250 worst case slow > lookups, since we need to learn for each server individually what it > can and can't do, plus 250 speedy lookups. And then, after the grace > period is over, you get another 250 slow lookups... I would think you can detect almost everything from 2 requests and replies. Only special workarounds for broken implementations may take more. It could work by timeout not too visible. It would send few queries to secondary server, metering averate round-trip time. If it was significantly better than the current server, switch to it. Unless connection changed, you can expect previous quirks apply, but still you can test response time. I think dnsmasq sends ocassinally few requests to non-primary. If answers don't arrive withing hundreds of ms, try also others. So user has answer soon and it did measure response time of all used servers. Even if any of them is offline. It does not have to be 50% of queries just to test it. > >>> It might be something to add as opt-in, and come with the warning that >>> you better list DNS servers that aren't crap if you want to use that, >>> so that we never have to downgrade protocol level, and thus the >>> learning phase is short. >> >> Sure enough, many router DNS implementations are bad or ugly. If it can >> choose from full featured validated ISP resolver and crappy router >> implementation, prefer the one with better features. Most likely it is >> much better maintained as well. > > I am sorry, but that is not a suitable approach for an "edge" DNS > clients. We need to go through the DNS server info we acquired through > DHCP or so, since private domains do exist. We must keep router admin > pages accessible. I haven't mentioned using any external DHCP client. Problem is, there is no standard way to configure slit DNS over DHCP. Or even declare private domains used by local networks via autoconfiguration. I tried Mikrotik's 'router' name on rawhide container. # dig @127.0.0.53 router gives status: NXDOMAIN # dig @127.0.0.53 router. gives status: NXDOMAIN /etc/resolv.conf points to /run/systemd/resolve/resolv.conf but getent can deliver results. How is that possible? # getent hosts router 192.168.88.1router # grep hosts /etc/nsswitch.conf hosts: resolve [!UNAVAIL=return] myhostname files mdns4_minimal [NOTFOUND=return] dns Of course, Mikrotik supports only DNS, not LLMNR or mDNS. Are you sure you don't support your router's bogus domain, but forgot about other vendors? What I am saying is, resolved might choose only the second server from DHCP list. Where only first knew about private domains for example. It is kind of broken configuration, but not uncommon. Router's DNS might be out of date, vulnerable to various attacks, but would be first IP on DNS servers from DHCP. Second would be ISP's resolver with up-to-date security backups. Now, systemd-resolved understands DNS servers as a set, but not ordered list, right? Would and should it choose ISP's server or my home router? What are checked metrics? > > Hence, the "server spread" thing where queries are spread over a ton > of DNS servers only really works if configured for the manual opt-in > case. It's not something we could ever deploy by default. By default > we need something that works,
Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)
ne server and 2 to another one. And randomize queries to each connection. Reuse of TLS connection is definitely wanted feature. Again, it might be limitation of current implementation, but it is possible. I admit maintaining multiple connections is much harder to implement (properly). > > or in other words: adding this conflicts with other (and I think more > important) goals here. Thus if we add this, only as option i > figure. It's not suitable as sensible default. > > Lennart > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_0x4931CA5B6C9FC5CB_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ 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 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)
Hi Florian, more below... On 11/11/20 11:39 AM, Florian Weimer wrote: > * Petr Menšík: >>> This proposal is about nscd, not systemd-resolved. > >> systemd-resolved is mentioned in the title and the body of proposal. So >> it seems it is about it. > > Fedora made the decision to promote systemd-resolved as a local DNS > cache. To me, that means that we can gradually remove other DNS caches > from the distribution. I maintain also dnsmasq and I doubt there is reason to remove it from the distribution. I would oppose if anyone intented to do it. > > Even if systemd-resolved has issues, they still need to be fixed because > it's the Fedora default. systemd-resolved brings more changes than were announced. Not all of them have fixes and some were refused. I think systemd people close too many bugs with WORKSFORME reason personally. But sure, bugs should be fixed. On the other hand, there are a lot of use cases, where it works better without systemd-resolved. I think we want alternatives supported regardless what is the default. Need to say I am not happy it became default and I would prefer it would first fix (already) known issues. > >>> If Fedora chooses to adopt another local DNS cache, glibc will use that >>> (probably using the built-in nss_dns service module) systemd-resolved is >>> just what we have for now, so the proposal references it. But any other >>> DNS cache will work as well. > >> I do not think there is another cache like nscd, which does not require >> /etc/resolv.conf change or special nss hosts module. While I admit there >> are more caches, I don't think any provides drop-in replacement. >> Especially resolve nss plugin introduces so many (unannounced) changes, >> I don't think it is a good alternative. Caching via dns module might be >> more predictable even with systemd-resolved. > > What do you mean by “Caching via dns module”? nss_dns does not have any > cache whatsoever. What I mean is omitting resolve module. So hosts db either reads /etc/hosts, or uses /etc/resolv.conf via /lib64/libnss_dns.so.2. > > There seem to be a lot of misconceptions about what nscd does and which > benefits it brings (see the claim about increased privacy). So I think > it's important to be precise here. I expect it would only cache simple name:ip pairs, nothing more. No, I doubt nscd can bring any additional privacy. > > From my point of view, nscd is not a very satisfactory solution for DNS > caching because it can't do DNSSEC, it can't do recursion, it can't do > prefetching, it doesn't have a good way to detect dead servers, it can't > inject local stub zones, and so on. We can argue whether people need DNSSEC. Systemd-resolved cannot work with it correctly and it actively BREAKS its usage. Just like dnsmasq, nscd just caches and no more. It usually does not break anything. I think it preserves most features of libnss_dns.so behaviour. No recursion, dead servers detection or injecting local zones is required. It is not done without the cache anyway. Dead servers detection could be improved I think. > > I also think that not changing /etc/resolv.conf isn't a feasible goal > because that's the file applications use to locate the system DNS > resolver if they can't use the glibc interfaces for some reason. Sure. If they can't use glibc interface, they would not use nscd. That clearly its advantage! It does not have to implement dnssec or edns0, because getaddrinfo api does not include such flags. If clients needs advanced usage, unlike systemd-resolved, it does not stand in the way. I think this is the greatest advantage. Advanced uses can work around only a simple service without problem. They don't collide. > >>> The hosts cache in nscd is arguably the weakest part of it, so >>> deprecating really shouldn't be controversial at all. > >> If you offer alternative, which improves caching without additional >> regressions, sure. I am not sure dnsmasq, systemd-resolved or unbound >> can be compared to no configuration of nscd. Unlike other resolvers, >> nscd caches only getaddrinfo calls, without ever touching outgoing DNS >> client queries or /etc/resolv.conf modification. Is there any other >> service able to do it? >> >> Are there bugs I can help fixing, especially in hosts or ahosts >> databases? > > Thanks for the offer. > > The big one is the general cache instability: > > nscd: Concurrency issues with cache. > <https://sourceware.org/bugzilla/show_bug.cgi?id=25888> > > (Internal bug #1172792.) This bug reminds me bug #1740511 [1], which was very hard for me. Later, mlichvar discovered real reason for it. Atomic operations required different flags to atomic operations. ppc64le platform has differen
Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)
Hi Marius, If you want to randomize requests to different servers, please try stubby package. I think it should offer best anonymity available. It is not true nscd is the only one. I think unbound at least randomizes queries, but I admit it is not configured via /etc/resolv.conf. With I think both dnsmasq and systemd-resolved does not keep strict ordering, which selects random server. But sure, it does not usually spread like option random in resolv.conf. I would suggest local unbound with qname-minimisation: yes. It is fedora default. I think it would also spread the usage, but would have to verify it. Cheers, Petr On 11/7/20 3:33 PM, Marius Schwarz wrote: > Am 05.11.20 um 12:39 schrieb Petr Menšík: >> There is no controversy with nscd, it just caches names and nothing >> more. I think this is its advantage. Unless there is any stronger >> reason, I am against this change in advance. >> > It not only caches names, it also RANDOMIZES the requests to the dns > servers configured, increasing the privacy of ones internet journey. > > AFAIK, it's the only dnscomponent available with fedora to do so. > Deprecating a unique component with no major bugs or flaws seems to be > illogical. > > best regards, > Marius -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_0x4931CA5B6C9FC5CB_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ 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 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)
On 11/5/20 12:49 PM, Florian Weimer wrote: > * Petr Menšík: > > > nscd has more usage downstream, leading to bugs such as: > > <https://bugzilla.redhat.com/show_bug.cgi?id=1551616> I have very limited understanding of sssd principles. But I think it is not comparable to nscd, which you just start or stop. No other configuration is required. > > Most of them are private, but you should be able to view them. Yes, I can. Linked bug references netgroup not cached, I cannot comment it, know no additional information. > >> Instead, I request again, split systemd-resolved into subpackage. I want >> it removed on my system and so do more people. Also, when I disable it, >> I have to fix /etc/resolv.conf by hand. I would think NetworkManager >> restart would refresh classic /etc/resolv.conf, like in F32. > > This proposal is about nscd, not systemd-resolved. systemd-resolved is mentioned in the title and the body of proposal. So it seems it is about it. > > If Fedora chooses to adopt another local DNS cache, glibc will use that > (probably using the built-in nss_dns service module) systemd-resolved is > just what we have for now, so the proposal references it. But any other > DNS cache will work as well. I do not think there is another cache like nscd, which does not require /etc/resolv.conf change or special nss hosts module. While I admit there are more caches, I don't think any provides drop-in replacement. Especially resolve nss plugin introduces so many (unannounced) changes, I don't think it is a good alternative. Caching via dns module might be more predictable even with systemd-resolved. > > The hosts cache in nscd is arguably the weakest part of it, so > deprecating really shouldn't be controversial at all. If you offer alternative, which improves caching without additional regressions, sure. I am not sure dnsmasq, systemd-resolved or unbound can be compared to no configuration of nscd. Unlike other resolvers, nscd caches only getaddrinfo calls, without ever touching outgoing DNS client queries or /etc/resolv.conf modification. Is there any other service able to do it? Are there bugs I can help fixing, especially in hosts or ahosts databases? -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_0x4931CA5B6C9FC5CB_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ 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 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)
scd is not > installed by default. It is usually used on systems configured with > LDAP, where nscd provides caching of remote queries. > * On a system using nscd that is updated to Fedora 34 from a previous > version, the system administrator will need to install and configure > sssd to replace it after the update. Even when this is not done, the > only visible affect will be slower resolution of named service queries > due to a missing cache. > * Users on a system running sssd and systemd-resolved instead of nscd > shouldn't see any noticeable difference in system behaviour or latency > in resolving named services. > > == Dependencies == > * `nss-pam-ldapd` has a weak dependency on nscd that will need to be removed. > * `libuser` has a build dependency on nscd that will also need to be removed. > > Both changes are minimal, requiring a removal of the dependency in the > spec file, and a rebuild. > > == Contingency Plan == > * Contingency mechanism: Revert changes to glibc spec file and > continue to ship nscd. Revert changes to libuser and nss-pam-ldapd > packages; this will need to be done by the respective package > maintainers. > * Contingency deadline: Fedora 34 Beta Freeze > * Blocks release? N/A (not a System Wide Change) > * Blocks product? None > > == Documentation == > N/A (not a System Wide Change) > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_0x4931CA5B6C9FC5CB_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ 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: 389ds making a local dns server for local web app.
On 10/13/20 8:37 AM, rodents...@gmail.com wrote: > Hello, I'm new in using 389ds. I would like to seek for advice regarding on > how to make a local DNS. Like, we have a web app running on > http://192.168.0.101:558 and I want to bind that address to a DNS, so that > the site will be access now using http://foobar.com:558. 192.168.x.x is private IP only for internal networks. foobar.com looks like name on public internet. Main problem is, if you want to run it only on your machine with given name, the easiest solution would be using /etc/hosts file. In case your browser ignores it, try running dnsmasq on localhost and use nameserver 127.0.0.1 in /etc/resolv.conf. If you want others to access your service, public IP adddress is required in general. Private would only on the same private network - on home LAN for example. 389ds is a complicated way to run just a DNS server. Is it your requirement? > > I followed the instructions on this guide. > https://directory.fedoraproject.org/docs/389ds/howto/howto-bind.html > > Somehow I got errors like: > [13/Oct/2020:06:26:25.344862514 +] - ERR - oc_check_allowed_sv - Entry > "cn=foobar.com,ou=DNS,dc=local" -- attribute "dnstype" not allowed > [13/Oct/2020:06:26:25.348760695 +] - ERR - setup_internal_backends - > Please edit the file to correct the reported problems and then restart the > server. > > > All of the attribute are not supported. > > I installed 389ds on an ubuntu 18.04 server. Following this guide. > https://www.youtube.com/watch?v=HI4u7vQH0EM > > Also, the links of examples on the official docs says "Not found". > ___ > 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 > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: F34 Change proposal: DNS Over TLS (System-Wide Change)
I would like to request pausing any new systemd-resolved features system-wide, until its current bugs and deficiencies are resolved sufficiently. And no, repeating that non-sense again, saying DNSSEC is only the server stuff nobody needs on desktop, would not count as fixed bug. Every TLS endpoint needs certificate. DNS has also signatures on zone data, which should be verified even over encrypted channel. Visit [1] to read more about difference between the two terms. And how they go along each other. In our view, current systemd-resolved has brought many regressions into F33. Let's wait with its new features, users can enable DNS over TLS any time already. Fix please years old issues first. 1. https://blog.apnic.net/2018/08/20/dnssec-and-dns-over-tls/ Best Regards, Petr On 9/29/20 10:29 PM, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/DNS_Over_TLS > > == Summary == > Fedora will attempt to use DNS over TLS (DoT) if supported by > configured DNS servers. > > == Owner == > * Name: [[User:catanzaro|Michael Catanzaro]] > * Email: > * Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]] > * Email: > > == Detailed Description == > > We will build systemd with `-Ddefault-dns-over-tls=opportunistic` to > protect DNS queries against passive network attackers. An active > network attacker can trivially subvert this protection, but we cannot > make DoT mandatory because other operating systems do not do so and > many (or most?) DNS servers do not support it. DoT will only be used > if the configured DNS server supports it and if it is not blocked by > an active network attacker. > > Note that DoT is different from DNS over HTTPS (DoH). In particular, > DoT is not an anti-censorship tool like DoH. It does not look like > regular HTTPS traffic, and it can be blocked by network administrators > if desired, so it should not be a problem for corporate networks. > > > == Benefit to Fedora == > > DNS queries are encrypted and private by default, if the user's ISP > supports DoT. Most probably don't, but users who manually configure a > custom DNS server (e.g. Cloudflare or Google) will automatically > benefit from DNS over TLS. > > == Scope == > * Proposal owners: change meson flags in systemd.spec > * Other developers: N/A (nothing should be required) > * Release engineering: [https://pagure.io/releng/issue/9772 #9772] (a > check of an impact with Release Engineering is needed) > * Policies and guidelines: N/A (nothing should be required) > * Trademark approval: N/A (not needed for this Change) > * Alignment with Objectives: Nope > > == Upgrade/compatibility impact == > DoT will be enabled automatically on upgrade to F34. If DoT is > unsupported, systemd-resolved will fall back to unencrypted DNS, so > there should be no compatibility impact. > > == How To Test == > Load any website in a web browser. If you succeed, then name > resolution probably works. > > Try using `resolvectl query fedoraproject.org` to see that resolvectl > still works. > > Bonus points: set your DNS server to 1.1.1.1 or 8.8.8.8, then use > Wireshark to see if your DNS is really encrypted or not. > > == User Experience == > Users should not notice any difference in behavior. > > == Dependencies == > No dependencies. > > == Contingency Plan == > > * Contingency mechanism: revert the change > * Contingency deadline: can be done at any time, before F34 beta > freeze would be best > * Blocks release? No > * Blocks product? No > > == Documentation == > See the section `DNSOverTLS=` in the manpage `resolved.conf(5)` > > == Release Notes == > systemd-resolved now enables DNS over TLS (DoT) support by default, in > opportunistic mode. DoT will be used only if supported by your DNS > server, and provides only best-effort encryption to protect against > passive network observers. For compatibility with existing DNS > servers, systemd-resolved will fall back to unencrypted DNS if DoT > does not appear to be supported, reducing the security benefit. If you > wish to manually configure systemd-resolved to prevent fallback to > unencrypted DNS, set `DNSOverTLS=yes` in `/etc/systemd/resolved.conf`. > Note that DoT is different than DNS over HTTPS (DoH) in that it does > not use HTTPS and is therefore easy to distinguish from HTTPS traffic. > > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB signature.asc Description: OpenPGP digital signature ___ 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: libvirt and systemd-resolved integration?
On 10/7/20 6:44 AM, Pavel Zhukov wrote: > > I don't think it's a good idea. > dnsmasq is not dns resolver but acts as DHCP and DNS server. It provides > VMs with IP > address/lease and create corresponding dns record for it. In case of > resolved ip addresses and dns records must be managed either manually > or... with dnsmasq. That is not true. Any query sent to @192.168.122.1 would get reply. I use for example unbound on localhost and all my machines use .vm. domain suffix. rhel7.vm. is machine with rhel7. Dnsmasq manages automatically lease names of all its dhcp clients, it works as dynamic DNS connected with DHCP just out of the box. unbound-control forward_add +i vm 192.168.122.1 Or permanent configuration in /etc/unbound/conf.d/vm.conf: server: domain-insecure: "vm" domain-insecure: "122.168.192.IN-ADDR.ARPA" forward-zone: name: "vm" forward-addr: 192.168.122.1 forward-first: no forward-zone: name: "122.168.192.IN-ADDR.ARPA" forward-addr: 192.168.122.1 forward-first: no Then I used in virsh edit-network default, inside element: dnsmasq is not full resolver, just like systemd-resolver. It just forwards queries it does not have answer to /etc/resolv.conf forwarders. If systemd-resolved does not running on the host, it also offers working DNSSEC environment to all VMs. Since systemd-resolved can do split DNS, it is able to do that also. But it seems current domain redirection is private API for NM. It might work: resolvectl domain virbr0 ~vm But haven't tested it. I am not sure how permanent configuration should look like in resolved.conf. Can it be configured to forward specific domain to specific server? It seems to me it expects such think only per interface, which might work with libvirt too. > On 2020-10-06 at 22:04 CEST, Juan Orti Alcaine wrote... >> Hello, >> >> In the network bridges that libvirt creates there's a dnsmasq daemon to >> resolve the VM's IPs. Is there any way to signal systemd-resolved from >> libvirt to say that in the bridge interface there is a DNS server and a >> domain? >> >> Thank you. > > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB signature.asc Description: OpenPGP digital signature ___ 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 10/1/20 5:44 PM, Vitaly Zaitsev via devel wrote: > On 01.10.2020 16:54, Petr Menšík wrote: >> But DNS over TLS does not bring you more privacy usually. > > It does. DoT and DoH encrypt all DNS traffic. Your ISP can no longer spy > on you and sell the collected data to third parties. > No, it doesn't. Unless you operate the remote resolver as well, it moves ability to see your name lookups from your ISP to DoT or DoH provider. They can see it instead. It makes you able to choose different receiver, but it does not 'protect' it from other parties in general. Now your DoH provider can sell the collected data to third parties. Living in the EU, I expect GDPR protects me better than DoH in the US. My ISP needs legal consent to sell such information. Cheers, Petr -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB signature.asc Description: OpenPGP digital signature ___ 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: This is bad, was Re: Fedora 33 System-Wide Change proposal:?? systemd-resolved
On 10/2/20 2:16 PM, Michael Catanzaro wrote: > On Fri, Oct 2, 2020 at 12:34 am, Marius Schwarz > wrote: >> If you send a DNS REQUEST to a US DNS server from within a company >> network, and with ipv6 the internal ip is sent out i learned lately, you >> have sent personal data which is protected under the GDRP. It's not >> unlikely to use company pcs for private webvisits while having a meal >> break. > > Hm, thanks for the explanation. I guess the DNS request would indeed be > the *first* way you lose, because you have to do DNS before you do > anything else. But you are going to lose immediately after anyway: > > * Immediately after you connect to the network, Fedora connects to > http://fedoraproject.org/static/hotspot.txt to see if you're behind a > captive portal Fedora is contacting fedora server, seems predictable. > * Next, GNOME Software starts checking for updates in the background. > You've leaked "personal data" to fedoraproject.org again, and also fwupd. It checks also to Fedora servers, right? > * You open Firefox, it downloads Safe Browsing data from Google. > (Admittedly this one is probably only behind a European CDN, but maybe > Google is having a bad day, or maybe IP address logs are sent to the > US.) Oh yeah, it also displays news from Pocket. Probably it does more > connections to the US that I don't know about. > * You switch to Financial Mode in Calculator, it downloads exchange rate > data. Might ask question to user, whether that is okay. Can you please fill a RFE bug? > * Anything crashes. A truncated stack trace gets sent to Fedora. > > I'm sure my list is missing quite a lot. If your interpretation is > correct, then I suppose German companies should immediately discontinue > use of Fedora, and also most other computer operating systems I think you are missing one important detail. When you choose to install Fedora, you are likely to accept it sends something to its servers. Anyway, they would usually have your IP somewhere, when you downloaded system image. However, forwarding queries to every name you visit online to some party, which you never agreed to or maybe heard its name, is something different. It just provides your site history to company never mentioned even in configuration files. It is only mentioned by resolvectl, which normal user would never hear about. It seems this should be easily configurable on installation (kickstart default or something), but by default should be empty. Prepared commented out FallbackDNS=8.8.8.8,... would work well. -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB signature.asc Description: OpenPGP digital signature ___ 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 4/16/20 5:43 PM, Tomasz Torcz wrote: > On Thu, Apr 16, 2020 at 07:41:07AM -0700, John M. Harris Jr wrote: >> >> Really, it may be best to go about this in the same way as Ubuntu, with nss- >> dns instead of nss-resolve.. Editing /etc/resolv.conf is still commonly done >> on Fedora, especially on servers. In fact, I never knew that NetworkManager >> would clobber that until this thread. If this isn't mean to wreck everyone's >> systems, backwards compatibility is key. > > Relying on nss_dns causes bugs like > https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624320 > (systemd-resolved appends 127.0.0.53 to resolv.conf alongside existing > entries). > It still gets (angry) comments, years after it was filled. > It is not nss_dns use, which makes angry comments from people. It should not be pushed into nameservers list when its broken. It should be possible to use resolved just for mdns and llmnr and leave dns for proper servers. If it were opt-in and not opt-out, no annoyed comments would be required. -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB signature.asc Description: OpenPGP digital signature ___ 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
