Description of problem: Hello, the latest release of nss-altfiles seems to be 2.23 from 2016-10-06: https://github.com/aperezdc/nss-altfiles/releases/tag/v2.23.0 It adds support for --with-types, allowing to add more maps beyond passwd and group. Please consider rebasing to the latest upstream. Version-Release number of selected component (if applicable): nss-altfiles as packaged in Fedora 35. How reproducible: Deterministic. Steps to Reproduce: 1. Configure altfiles in /etc/nsswitch.conf for hosts, for example with hosts: files altfiles myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns 1a. It may be necessary to configure it in /etc/authselect/user-nsswitch.conf and then run authselect apply-changes. 2. Add entry for some host to /usr/lib/hosts: echo 192.168.1.3 my.host.example.test >> /usr/lib/hosts 3. getent hosts my.host.example.test Actual results: No output. Expected results: 192.168.1.3 my.host.example.test Additional info:
It may be necessary to update https://src.fedoraproject.org/rpms/nss-altfiles/blob/rawhide/f/0001-build-sys-Inherit-LDFLAGS.patch to the latest code, and add patch from https://github.com/flatcar-linux/nss-altfiles/pull/1 as well. It is possible that https://github.com/flatcar-linux/nss-altfiles might be a more live upstream too.
Hello Colin, do you think that you might be able to get to do this change? Thank you, Jan
> It adds support for --with-types, allowing to add more maps beyond passwd and group. This seems to be specifically https://github.com/aperezdc/nss-altfiles/commit/8a6bbfd97e8990bf6cc4bc9d61dfd32366394a50 > 2. Add entry for some host to /usr/lib/hosts: echo 192.168.1.3 my.host.example.test >> /usr/lib/hosts The intended model for image based update systems is that /usr is read-only (on client systems). Is the idea of this that it's an alternative way to ship host entries in custom OS builds? Who is asking for this and why? In general I think most use cases here should be using a custom DNS server.
This is Fedora, so the request is in the general "ship the latest greatest" realm. My specific use-case is, I want to keep /etc/hosts as pristine as possible (just the default 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 ) because that file is used as a base for /etc/hosts in containers and in more than one case having some custom value in /etc/hosts on the host (think IP address of a previous testing VM) clashed with my docker / podman testing. On my systems, I actually have $ ls -la /usr/lib/hosts lrwxrwxrwx. 1 root root 14 Dec 31 2021 /usr/lib/hosts -> /etc/hosts.alt to go with my custom nss-altfiles-2.23.0 rpm build so any edit I want to do goes to /etc/hosts.alt. I don't do it because I'd have /usr read-only but because having configuration in /etc seems cleaner. If you feel something like /etc/${map}.alt or something similar might be better default for Fedora, or can have discussion about that with the upstream (whichever upstream might be the correct one), I certainly wouldn't object.
It's a low priority for us but PRs are welcomed.
I've filed https://src.fedoraproject.org/rpms/nss-altfiles/pull-request/2 now. The CI test https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/dist-git-build-pipeline/job/master/23649/ seems to have failed, presumably because of the missing nss-altfiles-2.23.0.tar.gz. I'm not sure if I should do fedpkg new-sources or what the protocol might be for getting the failure resolved.
I've respun the changes (with new-sources) and https://koji.fedoraproject.org/koji/taskinfo?taskID=93468481 now passed.
Hello, does the current PR look like it could go in, or is anything else needed to proceed?
Could you please merge https://src.fedoraproject.org/rpms/nss-altfiles/pull-request/2?
Hello, I've filed pull request https://src.fedoraproject.org/rpms/nss-altfiles/pull-request/2 per your suggestion in comment 5. Any chance of getting it reviewed and ideally merged?
Hello, I'm rather concerned that we ship ancient version of the software which prevents us from using useful feature from the latest version. What can I do to get https://src.fedoraproject.org/rpms/nss-altfiles/pull-request/2 reviewed and merged? I'd be happy to be added as a co-maintainer and to run through the process and merge and build the new release if it's a matter of finding time.
FEDORA-2023-2afac62514 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-2afac62514
FEDORA-2023-2afac62514 has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days