As I understand, winbind is a package to help integrate a machine into a Windows network. Documentation in "Integrating MS Windows Networks with Samba" http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/integrate-ms-networks.html is a good resource for novice like me. It seems we need to add wins to nsswitch.conf. Then I realize, libnss-mdns does put its entries into nsswitch.conf via package script. I thought it may be nice for winbind to do the similar. $ grep nsswitch.conf * ... libnss-mdns.postinst:# try to insert mdns entries to the "hosts" line in /etc/nsswitch.conf to libnss-mdns.postinst: # abort if /etc/nsswitch.conf does not exist libnss-mdns.postinst: if ! [ -e /etc/nsswitch.conf ]; then libnss-mdns.postinst: log "Could not find /etc/nsswitch.conf." libnss-mdns.postinst: ' /etc/nsswitch.conf libnss-mdns.postinst: # nsswitch.conf already contains mdns entries) libnss-mdns.postinst: if [ -e /etc/nsswitch.conf ]; then libnss-mdns.postinst: /etc/nsswitch.conf libnss-mdns.postinst: /etc/nsswitch.conf libnss-mdns.postrm: # abort if /etc/nsswitch.conf does not exist libnss-mdns.postrm: if ! [ -e /etc/nsswitch.conf ]; then libnss-mdns.postrm: log "Could not find /etc/nsswitch.conf." libnss-mdns.postrm: ' /etc/nsswitch.conf Regards, Osamu
Are you actually having difficulties? WINS is not used by recent Windows anymore and could better be avoided if possible. Cheers Luk
Hi, I see. I have no problem since I do not do this wins thing here. One of a bug reported pushed wins to be documented in Debian Reference. I have no idea what to tell him. What is used by recent Windows and what is a good pointer for documentation of such mixed system integration? Osamu
Quoting Osamu Aoki (osamu@debian.org): Thanks for you suggestion and bug report, Aoki-san. However, I think it really should be up to the local admin to decide what to do, here. I never added wins to nsswitch.conf on any of my samba servers and they're still working fairly well. At the very minimum, this should be done through a (low priority) debconf question (defaulting to not do anything). Given that, I'm far from being convinced of this being really useful, I will eventually consider this.....if we get a working patch implementing this, including debconf question..:)
The current mechanism used by libnss-mdns for updating /etc/nsswitch.conf is not policy-compliant. I would be happy to have the winbind package (actually the libpam-winbind package, in unstable) integrate with an appropriate nsswitch updating mechanism, but I won't perpetuate the policy-violating modification of another package's config file. Cheers,
The nss_wins module handles all NetBIOS name resolution, including broadcast resolution. So while no one with a recent version of Windows is likely to be setting up WINS, it's still the only way to resolve (at the Unix level) Windows hostnames that aren't in DNS. So it's still relevant, although I certainly wouldn't have the package enabling this by default. (In my first reply, I mistakenly thought this bug report was about nss_winbind, which probably *should* be enabled by default, if an appropriate updating mechanism were made available.)
Recent Windows systems use DNS instead. Where is the bug report asking for wins to be documented? We can probably give a better answer seeing the user's exact use case.
Hi, Thanks for clarification. Is it? Actually, I initially thought it was not policy-compliant without looking into facts. But /etc/nsswitch.conf does not look like conffile. It is a generated file by base-files.postinst. So, as long as base-files and libnss-mdns maintainers cordinate each other, I see no problem in terms of policy. Yes, *appropriate nsswitch updating mechanism* is what is needed. I am happy to know Windows system uses the sane host name resolution via DNS these days. I will continue discuss this topic with the original bug reporter who insisted to use NETBIOS for hostname resolution at http://bugs.debian.org/626736 . It seems even MS has howto for integrating their DHCP server with their DNS server. http://technet.microsoft.com/en-us/library/cc787034(v=WS.10).aspx (Certainly, we can do the equivalent on Debian) user and group management via libpam-winbind package on windows dominated world still seems good idea. Osamu
Quoting Osamu Aoki (osamu@debian.org): Oh, doh. Shouldn't it be a conffile anyway? As a local admin, I would hate seeing my carefully crafted nsswitch.conf file broken by packages' updates just because "it is policy-compliant as this is not a conffile". And I certainly know about Debian-haters who would happily use this as an argument to bash us for doing that (forgetting that most other distros happily break such files during upgrades...) So, well, sounds like a goodpolicy-compliant method to update nsswitch.conf would indeed be a great enhancemeent to bring. Thinking out loud, it could be something like /etc/nsswitch.conf.d/ but I'm not sure that's easy to do without hacking many things.
a) they don't coordinate
b) this config file is initially populated by base-files, but it's
configuration for libc, not for base-files, and there's no coordination
being done with glibc
c) the policy requirement is not just that they coordinate, but that they
use a *standard programmatic interface* for updating the config file:
If it is desirable for two or more related packages to share a
configuration file _and_ for all of the related packages to be able to
modify that configuration file, then the following should be done:
1. One of the related packages (the "owning" package) will manage
the configuration file with maintainer scripts as described in
the previous section.
2. The owning package should also provide a program that the other
packages may use to modify the configuration file.
3. The related packages must use the provided program to make any
desired modifications to the configuration file. They should
either depend on the core package to guarantee that the
configuration modifier program is available or accept gracefully
that they cannot modify the configuration file if it is not.
(This is in addition to the fact that the configuration file may
not even be present in the latter scenario.)
d) the current semantics of libnss-mdns are not at all scalable and need
some serious reworking before they could be made a standard process.
Yes, and we already integrate with PAM and would gladly integrate with
nsswitch - but more infrastructure is needed first.
Absolutely not!
The fact that you intend to "carefully craft" it is proof that it should not
be a conffile. Files should only be marked conffiles if in the vast
majority of cases the file will not need to be changed (by either the
package maintainer or the admin).
tags 649265 wontfix thanks I went through this bug log and I saw nothing really convincing that we should add "wins" to nsswitch.conf.....assuming we would have a good method for doing that (which we don't have). So, I'm very tempted to mark this as wontfix. So tempted indeed, that I'm doing it right now. If someone disagrees, then please untag..:-)
tags 649265 wontfix thanks I went through this bug log and I saw nothing really convincing that we should add "wins" to nsswitch.conf.....assuming we would have a good method for doing that (which we don't have). So, I'm very tempted to mark this as wontfix. So tempted indeed, that I'm doing it right now. If someone disagrees, then please untag..:-)
retitle 649265 provide coordinated mechanism to manage /etc/nsswitch.conf among packages tags 649265 - wontfix reassign 649265 base-files thanks Hi, Let me summarize a bit for http://bugs.debian.org/649265 The original motivation of this bug report was addressed through discussion.
[ Cc:ing everybody who participated in this bug ]. infrastructure for updating /etc/nsswitch.conf in a tiny package like base-files. This file is in base-files for historical reasons, but it is really a configuration file for libc6. Could we consider putting such scripts in libc-bin instead? This package exists since 2009 and it has conffiles (like base-files) and also binaries (which base-files has not). It would be really strange to add binaries to base-files. In the meantime: Anybody who needs his package to modify /etc/nsswitch.conf please say so in this bug and tell how it should be modified in the most precise way that you can. BTW: I'm not sure we can express the problem in a way that it has a solution. Imagine this: Package A: Needs to add "foo" at the end of the hosts: line. Package B: Needs to add "bar" at the end of the hosts: line. Clearly, we can't write a script to make both packages A and B happy. Either we have "foo" at the end or we have "bar" at the end, but not both. Will we need some kind of priority system?
Dear Maintainer,
I spoke with Steve Langasek on irc a few moments ago after reviewing
this bug. He informs me that there is still not a coordinated way to
manage /etc/nsswitch.conf.
I am working on a project to migrate a number of NIS machines to use
Active Directory user and group management, authentication and
authorization. The following is an excerpt from a script we are using
to update the CentOS 5 hosts, and I will likely use most of it for
Debian and Ubuntu since there is not really a better option:
# Configure system
echo "- Running authconfig"
authconfig --enablekrb5 --enablewinbind --enablewinbindauth --update
echo "- Processing ${NSS}"
cp ${NSS} ${BACKUP_DIR}/${NSS_FILE}.${TIMESTAMP}
TEMP_FILE="/tmp/${NSS_FILE}.${TIMESTAMP}"
cp -f ${NSS} ${TEMP_FILE}
echo "-- Switching order of passwd line"
cat ${TEMP_FILE} | sed "s/^passwd:.*/passwd: files winbind nis/" > ${TEMP_FILE}.1
mv -f ${TEMP_FILE}.1 ${TEMP_FILE}
echo "-- Switching order of shadow line"
cat ${TEMP_FILE} | sed "s/^shadow:.*/shadow: files winbind nis/" > ${TEMP_FILE}.1
mv -f ${TEMP_FILE}.1 ${TEMP_FILE}
echo "-- Switching order of group line"
cat ${TEMP_FILE} | sed "s/^group:.*/group: files winbind nis/" > ${TEMP_FILE}.1
mv -f ${TEMP_FILE}.1 ${TEMP_FILE}
mv -f ${TEMP_FILE} ${NSS}
V/R,
C.J.
There is. It is called augeas. Bastian
It would be quite useful to have a way to allow autofs to put the entry it needs into nsswitch.conf. It needs something like: autofs: nis files Everytime I install autofs I spend a while trying to remember how to do this.
There is a package in Ubuntu called 'auth-client-config' [1] which does that. For example, when I wanted to add authentication using OpenLDAP, I just ran this command after installing libnss_ldap & so: auth-client-config -t nss -p lac_ldap [1] http://packages.ubuntu.com/trusty/auth-client-config