Control: severity -1 normal Hi Simon
Am 12.01.2017 um 20:10 schrieb Simon McVittie: > Control: clone 846944 -2 > Control: reassign -2 libnss-mdns 0.10-7 > > On Thu, 08 Dec 2016 at 15:20:34 +0100, Michael Biebl wrote: >> With multiple packages mangling nsswitch.conf, this feels like it's >> becoming very brittle and maybe we need a proper API like pam-auth-update. > > That would be nice, but let's not block on that for stretch. Nod > On Thu, 08 Dec 2016 at 15:30:53 +0100, Michael Biebl wrote: >>> So maybe the "obvious" fix is to change libnss-mdns to always insert itself >>> before dns *and* resolve? On the other hand, it's quite ugly that mdns >>> needs to >>> be taught to cope with this new nss module. > > Solving this in nss-mdns is pretty easy so I'd be OK with going ahead with > that for stretch (and I'd be prepared to consider it RC). Cloning the > bug accordingly. I've written autopkgtests and they seem to work. Thanks for implementing that. Given this change in libnss-mdns, I'm going to downgrade the severity to non-RC. >> So, libnss-resolve's behaviour of using [!UNAVAIL=return] would break >> LDAP hosts resolution as well. > [...] >> It seems like [!UNAVAIL=return] is generally not safe to use if you >> don't know which NSS modules might come after yours. > > Yes. However, I can't think of any other way to get the desired > behaviour of nss-resolve, which is: if systemd-resolved responds > "that name doesn't exist in DNS", don't ask the dns plugin to look it up > in DNS again. > > I think the real issue here is perhaps that we have modules that try to > prioritize themselves lower than "dns", but are not a mere fallback like > libnss-myhostname is. > >>> libnss-lwres - NSS-Modul um bind9-lwres als Namensdienst zu nutzen > > Installation is not automated, and I don't see why anyone would want to > use this and systemd-resolved on the same system anyway (this one only > does traditional port 53 DNS, so it's a strict subset of systemd-resolved). > > Perhaps libnss-resolve should just have a Conflicts on it? Using both > makes no sense. There are a lot of packages which don't make sense to have installed alongside systemd. Adding Conflicts to all of them is not a path I want to go down > >>> libnss-ldap - NSS-Modul für den Einsatz von LDAP als Namensdienst > > Installation is not automated, but the example suggests appending ldap > after dns, so libnss-resolve will indeed break it. > > But it's orphaned, has many long-standing bugs that to be honest > should probably be RC, and has enough design issues that libnss-ldapd > was written as a replacement... so perhaps libnss-resolve should just > conflict with it and move on. (Remember, this is the plugin that pulls > libldap, GNUTLS, libsasl and Kerberos into every process that looks up > usernames...) > > The example configuration says > > # consult DNS first, we will need it to resolve the LDAP host. (If we > # can't resolve it, we're in infinite recursion, because libldap calls > # gethostbyname(). Careful!) > hosts: dns ldap > > which is just horrible tbh - as a bare minimum it should special-case > its own server name to be skipped! libnss-ldapd fixes that design issue. > >>> libnss-ldapd - NSS-Modul für den Einsatz von LDAP als Namensdienst > > This goes at the end, so libnss-resolve will break it. But > perhaps it shouldn't - its own documentation says > > # hostname lookups through ldap before dns should work now > hosts: files ldap dns > >>> libnss-myhostname - nss module providing fallback resolution for the >>> current hostname > > This goes at the end of the line as a fallback, but systemd-resolved > has all the functionality of libnss-myhostname, so not running it > is harmless. > >>> libnss-docker - nss module for finding Docker containers >>> libnss-gw-name - nss module that names the current gateway’s IP address > > These are prioritized slightly lower than 'files', so they come before > both mdns and resolve - conceptually, it's as though you added all > your containers, and your gateway, to /etc/hosts. That's fine. > >>> libnss-mymachines - nss module to resolve hostnames for local container >>> instances > > This is meant to be after files but before resolve (so the same position > as libnss-docker and libnss-gw-name). Are you deliberately installing it with > a lower priority than upstream's recommendation? We'll have to look into this. This change was made by Felipe in 7da95fd9f9a2330ffd3132c6673b25f929a78f09 for #789006. Maybe it was unintentional for mymachines (the original bug report was for myhostname) Felipe, can you chime in here? >>> libnss-libvirt - nss plugin providing IP add ress resolution for virtual >>> machines > > Not set up automatically. I'm not sure where it's meant to go; presumably > the same place as libnss-docker, in which case it's fine? > >>> libnss-sss - Nss-Modul für den SSS-Daemon (System Security Services) >>> libnss-cache - NSS module for using nsscache-generated files >>> libnss-extrausers - nss module to have an additional passwd, shadow and >>> group file >>> libnss-mysql-bg - NSS module for using MySQL as a naming service >>> libnss-pgsql2 - NSS module for using PostgreSQL as a naming service >>> libnss-securepass - NSS (Name Service Switch) module for Securepass >>> libnss-db - NSS-Modul für die Verwendung der Berkeley-Datenbank als >>> Namensdienst >>> libnss-rainbow2 - nss library for rainbow >>> libnss-winbind - Samba nameservice integration plugins >>> libnss-systemd - nss module providing dynamic user and group name resolution > > These don't seem to do hosts. > >>> libnss-wrapper - NSS wrapper library > > False positive: it's an LD_PRELOAD hack to manipulate the nsswitch, not > a normal nsswitch plugin. Thanks for the detailed analysis! Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
