mirror of
https://sourceware.org/git/glibc.git
synced 2024-12-26 20:51:11 +00:00
a5f891ac8d
In <https://sourceware.org/ml/libc-alpha/2014-01/msg00196.html> I noted it was necessary to add includes of Makeconfig early in various subdirectory makefiles for the tests-special variable settings added by that patch to be conditional on configuration information. No-one commented on the general question there of whether Makeconfig should always be included immediately after the definition of subdir. This patch implements that early inclusion of Makeconfig in each directory (which is a lot easier than consistent placement of includes of Rules). Includes are added if needed, or moved up if already present. Subdirectory "all:" targets are removed, since Makeconfig provides one. There is potential for further cleanups I haven't done. Rules and Makerules have code such as ifneq "$(findstring env,$(origin headers))" "" headers := endif to override to empty any value of various variables that came from the environment. I think there is a case for Makeconfig setting all the subdirectory variables (other than subdir) to empty to ensure no outside value is going to take effect if a subdirectory fails to define a variable. (A list of such variables, possibly out of date and incomplete, is in manual/maint.texi.) Rules and Makerules would give errors if Makeconfig hadn't already been included, instead of including it themselves. The special code to override values coming from the environment would then be obsolete and could be removed. Tested x86_64, including that installed binaries are identical before and after the patch. * argp/Makefile: Include Makeconfig immediately after defining subdir. * assert/Makefile: Likewise. * benchtests/Makefile: Likewise. * catgets/Makefile: Likewise. * conform/Makefile: Likewise. * crypt/Makefile: Likewise. * csu/Makefile: Likewise. (all): Remove target. * ctype/Makefile: Include Makeconfig immediately after defining subdir. * debug/Makefile: Likewise. * dirent/Makefile: Likewise. * dlfcn/Makefile: Likewise. * gmon/Makefile: Likewise. * gnulib/Makefile: Likewise. * grp/Makefile: Likewise. * gshadow/Makefile: Likewise. * hesiod/Makefile: Likewise. * hurd/Makefile: Likewise. (all): Remove target. * iconvdata/Makefile: Include Makeconfig immediately after defining subdir. * inet/Makefile: Likewise. * intl/Makefile: Likewise. * io/Makefile: Likewise. * libio/Makefile: Likewise. (all): Remove target. * locale/Makefile: Include Makeconfig immediately after defining subdir. * login/Makefile: Likewise. * mach/Makefile: Likewise. (all): Remove target. * malloc/Makefile: Include Makeconfig immediately after defining subdir. (all): Remove target. * manual/Makefile: Include Makeconfig immediately after defining subdir. * math/Makefile: Likewise. * misc/Makefile: Likewise. * nis/Makefile: Likewise. * nss/Makefile: Likewise. * po/Makefile: Likewise. (all): Remove target. * posix/Makefile: Include Makeconfig immediately after defining subdir. * pwd/Makefile: Likewise. * resolv/Makefile: Likewise. * resource/Makefile: Likewise. * rt/Makefile: Likewise. * setjmp/Makefile: Likewise. * shadow/Makefile: Likewise. * signal/Makefile: Likewise. * socket/Makefile: Likewise. * soft-fp/Makefile: Likewise. * stdio-common/Makefile: Likewise. * stdlib/Makefile: Likewise. * streams/Makefile: Likewise. * string/Makefile: Likewise. * sunrpc/Makefile: Likewise. (all): Remove target. * sysvipc/Makefile: Include Makeconfig immediately after defining subdir. * termios/Makefile: Likewise. * time/Makefile: Likewise. * timezone/Makefile: Likewise. (all): Remove target. * wcsmbs/Makefile: Include Makeconfig immediately after defining subdir. * wctype/Makefile: Likewise. libidn/ChangeLog: * Makefile: Include Makeconfig immediately after defining subdir. localedata/ChangeLog: * Makefile: Include Makeconfig immediately after defining subdir. (all): Remove target. nptl/ChangeLog: * Makefile: Include Makeconfig immediately after defining subdir. nptl_db/ChangeLog: * Makefile: Include Makeconfig immediately after defining subdir. |
||
---|---|---|
.. | ||
nss_hesiod | ||
Depend | ||
hesiod_p.h | ||
hesiod.c | ||
hesiod.h | ||
Makefile | ||
README.hesiod | ||
Versions |
The GNU C library contains an NSS module for the Hesiod name service. Hesiod is a general name service for a variety of applications and is based on the Berkeley Internet Name Daemon (BIND). Introduction ============ The Hesiod NSS module implements access to all relevant standard Hesiod types, which means that Hesiod can be used for the `group', `passwd' and `services' databases. There is however a restriction. In the same way that it is impossible to use `gethostent()' to iterate over all the data provided by DNS, it is not possible to scan the entire Hesiod database by means of `getgrent()', `getpwent()' and `getservent()'. Besides, Hesiod only provides support for looking up services by name and not for looking them up by port. In essence this means that the Hesiod name service is only consulted as a result of one of the following function calls: * getgrname(), getgrgid() * getpwname(), getpwuid() * getservbyname() and their reentrant counterparts. Configuring your systems ======================== Configuring your systems to make use the Hesiod name service requires one or more of the following steps, depending on whether you are already running Hesiod in your network. Configuring NSS --------------- First you should modify the file `/etc/nsswitch.conf' to tell NSS for which database you want to use the Hesiod name service. If you want to use Hesiod for all databases it can handle your configuration file could look like this: # /etc/nsswitch.conf # # Example configuration of GNU Name Service Switch functionality. # passwd: db files hesiod group: db files hesiod shadow: db files hosts: files dns networks: files dns protocols: db files services: db files hesiod ethers: db files rpc: db files For more information on NSS, please refer to the `The GNU C Library Reference Manual'. Configuring Hesiod ------------------ Next, you will have to configure Hesiod. If you are already running Hesiod in your network, you probably already have a file named `hesiod.conf' on your machines (probably as `/etc/hesiod.conf' or `/usr/local/etc/hesiod.conf'). The Hesiod NSS module looks for `/etc/hesiod.conf' by default. If there is no configuration file you will want to create your own. It should look something like: rhs=.your.domain lhs=.ns classes=in,hs The optional classes settings specifies which DNS classes Hesiod should do lookups in. Possible values are IN (the preferred class) and HS (the deprecated class, still used by some sites). You may specify both classes separated by a comma to try one class first and then the other if no entry is available in the first class. The default value of the classes variable is `IN,HS'. The value of rhs can be overridden by the environment variable `HES_DOMAIN'. Configuring your name servers ----------------------------- In addition, if you are not already running Hesiod in your network, you need to create Hesiod information on your central name servers. You need to run `named' from BIND 4.9 or higher on these servers, and make them authoritative for the domain `ns.your.domain' with a line in `/etc/named.boot' reading something like: primary ns.your.domain named.hesiod or if you are using the new BIND 8.1 or higher add something to `/etc/named.conf' like: zone "ns.your.domain" { type master; file "named.hesiod"; }; Then in the BIND working directory (usually `/var/named') create the file `named.hesiod' containing data that looks something like: ; SOA and NS records. @ IN SOA server1.your.domain admin-address.your.domain ( 40000 ; serial - database version number 1800 ; refresh - sec servers 300 ; retry - for refresh 3600000 ; expire - unrefreshed data 7200 ) ; min NS server1.your.domain NS server2.your.domain ; Actual Hesiod data. libc.group TXT "libc:*:123:gnu,gnat" 123.gid CNAME libc.group gnu.passwd TXT "gnu:*:4567:123:GNU:/home/gnu:/bin/bash" 456.uid CNAME mark.passwd nss.service TXT "nss tcp 789 switch sw " nss.service TXT "nss udp 789 switch sw" where `libc' is an example of a group, `gnu' an example of an user, and `nss' an example of a service. Note that the format used to describe services differs from the format used in `/etc/services'. For more information on `named' refer to the `Name Server Operations Guide for BIND' that is included in the BIND distribution. Security ======== Note that the information stored in the Hesiod database in principle is publicly available. Care should be taken with including vulnerable information like encrypted passwords in the Hesiod database. There are some ways to improve security by using features provided by `named' (see the discussion about `secure zones' in the BIND documentation), but one should keep in mind that Hesiod was never intended to distribute passwords. In the origional design authenticating users was the job of the Kerberos service. More information ================ For more information on the Hesiod name service take a look at some of the papers in ftp://athena-dist.mit.edu:/pub/ATHENA/usenix and the documentation that accompanies the source code for the Hesiod name service library in ftp://athena-dist.mit.edu:/pub/ATHENA/hesiod. There is a mailing list at MIT for Hesiod users, hesiod@mit.edu. To get yourself on or off the list, send mail to hesiod-request@mit.edu.