From sacadmin Thu May 4 18:11:14 2006 Received: from phys-bur1-1 (phys-bur1-1.East.Sun.COM [129.148.13.15]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k451BDIQ020010 for ; Thu, 4 May 2006 18:11:13 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IYR00N01PGD0B@bur-mail2.east.sun.com> (original mail from sebastien.roy@sun.com) for psarc@sac.sfbay.sun.com; Thu, 04 May 2006 21:11:13 -0400 (EDT) Received: from strat.East.Sun.COM (strat.East.Sun.COM [129.148.174.103]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IYR00L6FPYPI0@bur-mail2.east.sun.com>; Thu, 04 May 2006 21:11:13 -0400 (EDT) Date: Thu, 04 May 2006 21:11:13 -0400 From: Sebastien Roy Subject: 2006/299 Single hosts File To: psarc@sac.sfbay.sun.com Cc: Rishi Srivatsavai Message-id: <1146791473.23989.56.camel@strat.East.Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.6.1 Content-type: text/plain Content-transfer-encoding: 7BIT Status: RO Content-Length: 13539 I'm sponsoring the following fast-track for Rishi Srivatsavai. The timer expires on 05/11/2006. Single hosts File ================= Release binding: Minor Problem ======= The /etc/inet/ipnodes database was created to hold both IPv4 and IPv6 host addresses. The ipnodes database is searched first by applications using the getaddrinfo()/getnameinfo() API. The /etc/inet/hosts database was left for legacy applications supporting only IPv4 addresses and calling the gethostby* API. Changes were approved in case PSARC/1998/039 and integrated in Solaris 8. The drawback of the split is IPv4 entries in both databases have to be always in sync. Problems arise in applications when an entry differs in the two databases and host lookup results vary depending on the API used. System administrators must make it a point when changing one file to update the other. The problem is documented in CR 6219146. Solution ======== This case proposes to remove the current limitation in maintaining two databases for IP addresses and to avoid the problems posed when entries in the two databases are conflicting. The /etc/inet/hosts database will be the single configuration file that associates host names with their IP addresses, both IPv4 and IPv6 addresses. The /etc/inet/ipnodes file will be left as a symlink to /etc/inet/hosts for backwards compatibility. Adding IPv6 address entries in /etc/inet/hosts does not break host lookups using the gethostby* API. In the gethostby* implementation addresses found in the database not in IPv4 address format are disregarded during the search. Host lookups using the getaddrinfo()/getnameinfo() API will also be unaffected after the ipnodes conversion to a symlink. We chose to leave the /etc/inet/ipnodes as a symlink and not remove the file entirely in keeping with the file's classification as a 'Stable' interface. Removing the file entirely runs the risk of breaking existing applications depending on the file and may cause users to re-create the ipnodes file to satisfy such applications. Keeping the symlink could also cause issues in applications expecting two distinct files holding IPv4 addresses. F.e. an application adding IPv4 addresses previously to two distinct hosts and ipnodes files may now add entries twice in the same hosts file. We feel the advantages of keeping a stable interface by keeping the ipnodes file as a symlink outweigh risks with applications continuing to treat the two files as distinct. Merge Script ============ The task of merging entries from the ipnodes database to the hosts database is performed by a class action script in the SUNWcsr package. The merge script copies over entries from the ipnodes database to the hosts database and in the resulting hosts file removes duplicate entries and coalesces multiple address entries of a hostname. When removing duplicate address lines the hostname entry from ipnodes is preserved over one in hosts database. The reason is nsswitch looks up entries first in ipnodes before hosts and we want to preserve that behavior after the merge. For hostname entry with multiple addresses, all entries are moved to consecutive lines in the resulting hosts file. When a duplicate entry is removed by the merge script any comment lines preceding the entry are also removed. However if the removed entry is the first in the file any preceding comment lines possibly specifying the file header are not removed. Solaris Upgrade =============== Solaris OS upgrade detects any configuration file changes in new package versions and renames the modified files as reference copies prior to the upgrade. The ipnodes file change to a symlink when found in the new package, the existing ipnodes file is renamed before upgrading the system. But this safeguard against losing configuration changes due to upgrade does not permit the class action script to merge ipnodes contents into hosts correctly. An entry therefore will be added in the SUNWcsr pkghistory to ignore the ipnodes file change and not rename the file. NIS ipnodes =========== This case does not propose any changes to nsswitch nor removing the ipnodes database from the switch file. NIS and NIS+ servers shall continue to use separate maps for hosts and ipnodes. We expect to resolve the ipnodes backend issue at a later time. Interface Table =================== The following existing interfaces are affected: /etc/inet/hosts Stable /etc/inet/ipnodes Stable * Please note that PSARC/1998/039 case includes references to /etc/inet/hosts6 file. During review one of the issues raised was on the choice of filename. Though there is no explicit mention of ipnodes being chosen as the new filename the proposed /etc/inet/hosts6 filename was changed to /etc/inet/ipnodes. References ========== 1. PSARC/1998/039 "Naming Services Support of IPv6" 2. CR 6219146 "/etc/inet/hosts and /etc/inet/ipnodes need to be the same file" Manual page changes =================== The new hosts man page is listed below: File Formats hosts(4) NAME hosts - host name database SYNOPSIS /etc/inet/hosts /etc/hosts + /etc/inet/ipnodes + DESCRIPTION The hosts file is a local database that associates the names - of hosts with their Internet Protocol (IP) addresses. The + of hosts with their Internet Protocol (IP) addresses. IP + addresses can be either an IPv4 or an IPv6 address. The hosts file can be used in conjunction with, or instead of, other hosts databases, including the Domain Name System (DNS), the NIS hosts map, the NIS+ hosts table, or informa- tion from an LDAP server. Programs use library interfaces to access information in the hosts file. The hosts file has one entry for each IP address of each host. If a host has more than one IP address, it will have one entry for each, on consecutive lines. The format of each line is: IP-address official-host-name nicknames... Items are separated by any number of SPACE and/or TAB char- acters. The first item on a line is the host's IP address. The second entry is the host's official name. Subsequent entries on the same line are alternative names for the same machine, or "nicknames." Nicknames are optional. For a host with more than one IP address, consecutive entries for these addresses may contain the same or differ- ing nicknames. Different nicknames are useful for assigning distinct names to different addresses. A call to gethostbyname(3NSL) returns a hostent structure - containing the union of all addresses and nicknames from - each line containing a matching official name or nickname. + containing the union of all IPv4 addresses and nicknames + from each line containing a matching official name or + nickname. A call to getipnodebyname(3SOCKET) is similar, + but is capable of returning hostent structures + containing IPv4 and IPv6 addresses. Applications may + also preferably use the address-family independent + getaddrinfo(3SOCKET) API for name to address + lookups. A `#' indicates the beginning of a comment; characters up to the end of the line are not interpreted by routines that search the file. - Network addresses are written in the conventional "decimal - dot" notation and interpreted using the inet_addr routine - from the Internet address manipulation library, - inet(3SOCKET). + Network addresses are written in one of two ways: - This interface supports host names as defined in Internet - RFC 952 which states: + o The conventional "decimal dot" notation and interpreted + using the inet_addr routine from the Internet address + manipulation library, inet(3SOCKET). SunOS 5.10 Last change: 30 Sep 2005 1 File Formats hosts(4) + o The IP Version 6 protocol [IPV6], defined in RFC 1884 + and interpreted using the inet_pton() routine from the + Internet address manipulation library. See + inet(3SOCKET). + These interfaces supports node names as defined in Internet + RFC 952 which states: + A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24 characters drawn from the alphabet (A- Z), digits (0-9), minus sign (-), and period (.). Note that periods are only allowed when they serve to del- imit components of "domain style names". (See RFC 921, "Domain Name System Implementation Schedule," for back- ground). No blank or space characters are permitted as part of a name. No distinction is made between upper- case and lowercase. The first character must be an alpha character [or a digit. (RFC 1123 relaxed RFC 952's limitation of the first character to only alpha characters.)] The last character must not be a minus sign or period. Host names must not consist of numbers only. A host name must contain at least one alphabetical or special character. Although the interface accepts host names longer than 24 characters for the host portion (exclusive of the domain component), choosing names for hosts that adhere to the 24 character restriction will insure maximum interoperability on the Internet. A host which serves as a GATEWAY should have "-GATEWAY" or "-GW" as part of its name. Hosts which do not serve as Internet gateways should not use "-GATEWAY" and "-GW" as part of their names. A host which is a TAC should have "-TAC" as the last part of its host name, if it is a DoD host. Single character names or nicknames are not allowed. EXAMPLES Example 1: Example of a typical line from the hosts file. Here is a typical line from the hosts file: 192.9.1.20 gaia # John Smith + Example 2: Example of an IPv6 address entry. + + 2001:0db8:3c4d:55:a00:20ff:fe8e:f3ad myhost # John Smith + + SEE ALSO gethostbyname(3NSL), inet(3SOCKET), nsswitch.conf(4), resolv.conf(4) + Braden, B., editor, RFC 1123, Requirements for Internet + Hosts - Application and Support, Network Working Group, + October, 1989. + + Harrenstien, K., Stahl, M., and Feinler, E., RFC 952, DOD + INTERNET HOST TABLE SPECIFICATION, Network Working Group, + October 1985. + + Hinden, R., and Deering, S., editors, RFC 1884, IP Version 6 + Addressing Architecture, Network Working Group, December, + 1995. + + Postel, Jon, RFC 921, Domain Name System Implementation + Schedule - Revised, Network Working Group, October 1984. + + NOTES /etc/inet/hosts is the official SVR4 name of the hosts file. The symbolic link /etc/hosts exists for BSD compatibility. + The symbolic link /etc/hosts/ipnodes exists for backwards + compatibility with previous Solaris releases. The nssitch.conf (4) man page is also updated with a new note about the ipnodes file change to a symlink: *** nss Wed May 3 13:24:11 2006 --- nss.new Wed May 3 13:34:24 2006 *************** *** 672,726 **** --- 672,728 ---- getdefaultproj(3PROJECT), inproj(3PROJECT), setproject(3PROJECT), getauthnam(3SECDB), getexecprof(3SECDB), getprofnam(3SECDB), getuserattr(3SECDB), getusernam(3SECDB), ethers(3SOCKET), getaddrinfo(3SOCKET), getnetbyname(3SOCKET), getprotobyname(3SOCKET), getservbyname(3SOCKET), auth_attr(4), netconfig(4), project(4), resolv.conf(4), user_attr(4), ypfiles(4) NOTES Within each process that uses nsswitch.conf, the entire file is read only once; if the file is later changed, the process will continue using the old configuration. The use of both nis and nisplus as sources for the same database is strongly discouraged since both the name ser- vices are expected to store similar information and the lookups on the database may yield different results depend- ing on which name service is operational at the time of the request. The same applies for using ldap along with nis or nisplus. Misspelled names of sources and databases will be treated as legitimate names of (most likely nonexistent) sources and databases. The following functions do not use the switch: fgetgrent(3C), fgetprojent(3PROJECT), fgetpwent(3C), fgetspent(3C), getpw(3C), putpwent(3C), shadow(4). + The files source to both ipnodes and hosts databases is identical + as /etc/inet/ipnodes is a symbolic link to /etc/inet/hosts. From sacadmin Thu May 4 19:22:24 2006 Received: from sineb-mail-2.sun.com ([192.18.19.7]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k452MNIQ023049 for ; Thu, 4 May 2006 19:22:24 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.12.10+Sun/8.12.9) with ESMTP id k452MHFV005490 for ; Fri, 5 May 2006 10:22:18 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IYR00201T3DK500@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for psarc@sac.sfbay.sun.com; Fri, 05 May 2006 10:22:17 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IYR00D4HT93332J@mail-apac.sun.com>; Fri, 05 May 2006 10:22:17 +0800 (SGT) Date: Thu, 04 May 2006 19:18:21 -0700 From: Darren Reed Subject: Re: 2006/299 Single hosts File In-reply-to: <1146791473.23989.56.camel@strat.East.Sun.COM> Sender: Darren.Reed@Sun.COM To: Rishi Srivatsavai Cc: Sebastien Roy , psarc@sac.sfbay.sun.com Message-id: <445AB5ED.3040705@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <1146791473.23989.56.camel@strat.East.Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041221 Status: RO Content-Length: 1259 Sebastien Roy wrote: >I'm sponsoring the following fast-track for Rishi Srivatsavai. The >timer expires on 05/11/2006. > >Single hosts File >================= > >Release binding: Minor > >Problem >======= > >The /etc/inet/ipnodes database was created to hold both IPv4 and IPv6 >host addresses. The ipnodes database is searched first by >applications using the getaddrinfo()/getnameinfo() API. The >/etc/inet/hosts database was left for legacy applications >supporting only IPv4 addresses and calling the gethostby* API. >Changes were approved in case PSARC/1998/039 and integrated in >Solaris 8. > >The drawback of the split is IPv4 entries in both databases have to be >always in sync. Problems arise in applications when an entry differs >in the two databases and host lookup results vary depending on the API >used. System administrators must make it a point when changing one >file to update the other. The problem is documented in CR 6219146. > What does this case have to say for software that independantly parses /etc/hosts and emits an error (and maybe stops processing the file) if it doesn't find a line that is one of: a) empty b) a comment c) starts with an IP address Darren From sacadmin Thu May 4 20:01:19 2006 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k4531JIQ023762 for ; Thu, 4 May 2006 20:01:19 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4531HWa005768; Thu, 4 May 2006 23:01:17 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k4531Hhf016233; Thu, 4 May 2006 23:01:17 -0400 (EDT) Subject: Re: 2006/299 Single hosts File From: Bill Sommerfeld To: Darren Reed Cc: Rishi Srivatsavai , Sebastien Roy , psarc@sac.sfbay.sun.com In-Reply-To: <445AB5ED.3040705@sun.com> References: <1146791473.23989.56.camel@strat.East.Sun.COM> <445AB5ED.3040705@sun.com> Content-Type: text/plain Message-Id: <1146798076.22586.75.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.333 Date: Thu, 04 May 2006 23:01:17 -0400 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1117 On Thu, 2006-05-04 at 22:18, Darren Reed wrote: > What does this case have to say for software that independantly > parses /etc/hosts and emits an error (and maybe stops processing > the file) if it doesn't find a line that is one of: > > a) empty > b) a comment > c) starts with an IP address I don't know what this case has to say about it, but as best as I can tell, implementation experience on other unix platforms (including one I *know* you use) which didn't bother exiling IPv6 addresses to a separate file (in other words, everyone but us) suggests that such software either (a) doesn't exist, (b) is extremely rare, or (c) has already been fixed. IMHO this is obviously an acceptable risk in a Minor release. That said, on a number of aliases I've seen recommendations that people symlink the files to each other rather than keeping them in sync manually. I discovered that if you *do* symlink the files, an upgrade will break the link and give you a separate ipnodes file back. Maybe it's not this project but it sure would be nice if a future S10Ux update didn't do that any more. - Bill From sacadmin Fri May 5 02:43:32 2006 Received: from nis-uk.uk.sun.com (nis-uk.UK.Sun.COM [129.156.85.41]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k459hVIQ003845 for ; Fri, 5 May 2006 02:43:31 -0700 (PDT) Received: from enospc.uk.sun.com (enospc [129.156.173.14]) by nis-uk.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k459hRoR016410; Fri, 5 May 2006 10:43:28 +0100 (BST) Received: from [129.156.173.228] (coptic [129.156.173.228]) by enospc.uk.sun.com (8.13.4+Sun/8.13.3/CTE 3.0) with ESMTP id k459hRKR028413; Fri, 5 May 2006 10:43:27 +0100 (BST) Message-ID: <445B1DF7.4080301@sun.com> Date: Fri, 05 May 2006 10:42:15 +0100 From: Julian Pullen - Sun Microsystems User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060405 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sebastien Roy CC: psarc@sac.sfbay.sun.com, Rishi Srivatsavai Subject: Re: 2006/299 Single hosts File References: <1146791473.23989.56.camel@strat.East.Sun.COM> In-Reply-To: <1146791473.23989.56.camel@strat.East.Sun.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 129 Be careful when merging the files. There can be comments and blank lines between consecutive entries for the same host. Julian From sacadmin Fri May 5 04:17:19 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k45BHIIQ009232 for ; Fri, 5 May 2006 04:17:19 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k45BHIUA009089; Fri, 5 May 2006 07:17:18 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k45BHIbj009086; Fri, 5 May 2006 07:17:18 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17499.13374.326161.584262@gargle.gargle.HOWL> Date: Fri, 5 May 2006 07:17:18 -0400 From: James Carlson To: Bill Sommerfeld , Julian Pullen - Sun Microsystems Cc: Darren Reed , Rishi Srivatsavai , Sebastien Roy , psarc@sac.sfbay.sun.com Subject: Re: 2006/299 Single hosts File In-Reply-To: Bill Sommerfeld's message of 4 May 2006 23:01:17 References: <1146791473.23989.56.camel@strat.East.Sun.COM> <445B1DF7.4080301@sun.com> <445AB5ED.3040705@sun.com> <1146798076.22586.75.camel@thunk> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 908 Bill Sommerfeld writes: > I discovered that if you *do* symlink the files, an upgrade will break > the link and give you a separate ipnodes file back. > > Maybe it's not this project but it sure would be nice if a future S10Ux > update didn't do that any more. This project fixes that problem by using pkghistory; see the original specification. Julian Pullen - Sun Microsystems writes: > Be careful when merging the files. There can be comments and blank lines > between consecutive entries for the same host. Indeed. And the script does handle those cases specially. If you're concerned about it, you might want to contact Sebastien off-line and volunteer to review the code. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Fri May 5 04:20:17 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k45BKHIQ009319 for ; Fri, 5 May 2006 04:20:17 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k45BKHbI009097; Fri, 5 May 2006 07:20:17 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k45BKHId009094; Fri, 5 May 2006 07:20:17 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17499.13551.536909.255941@gargle.gargle.HOWL> Date: Fri, 5 May 2006 07:20:15 -0400 From: James Carlson To: Bill Sommerfeld , Julian Pullen - Sun Microsystems , Darren Reed , Rishi Srivatsavai , Sebastien Roy , psarc@sac.sfbay.sun.com Subject: Re: 2006/299 Single hosts File In-Reply-To: James Carlson's message of 5 May 2006 07:17:18 References: <1146791473.23989.56.camel@strat.East.Sun.COM> <445B1DF7.4080301@sun.com> <445AB5ED.3040705@sun.com> <1146798076.22586.75.camel@thunk> <17499.13374.326161.584262@gargle.gargle.HOWL> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 590 James Carlson writes: > > Maybe it's not this project but it sure would be nice if a future S10Ux > > update didn't do that any more. > > This project fixes that problem by using pkghistory; see the original > specification. Ah, but for Minor release only and not for patches. I don't know if we have the right mechanisms (and policies!) to do this with a patch. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Fri May 5 04:28:13 2006 Received: from nis-uk.uk.sun.com (nis-uk.UK.Sun.COM [129.156.85.41]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k45BSCIQ009551 for ; Fri, 5 May 2006 04:28:12 -0700 (PDT) Received: from enospc.uk.sun.com (enospc [129.156.173.14]) by nis-uk.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k45BS7oR000471; Fri, 5 May 2006 12:28:07 +0100 (BST) Received: from [129.156.173.199] (estale [129.156.173.199]) by enospc.uk.sun.com (8.13.4+Sun/8.13.3/CTE 3.0) with ESMTP id k45BS6kT007647; Fri, 5 May 2006 12:28:07 +0100 (BST) Message-ID: <445B36C6.7060101@Sun.COM> Date: Fri, 05 May 2006 12:28:06 +0100 From: Darren J Moffat User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: James Carlson CC: Bill Sommerfeld , Julian Pullen - Sun Microsystems , Darren Reed , Rishi Srivatsavai , Sebastien Roy , psarc@sac.sfbay.sun.com Subject: Re: 2006/299 Single hosts File References: <1146791473.23989.56.camel@strat.East.Sun.COM> <445B1DF7.4080301@sun.com> <445AB5ED.3040705@sun.com> <1146798076.22586.75.camel@thunk> <17499.13374.326161.584262@gargle.gargle.HOWL> <17499.13551.536909.255941@gargle.gargle.HOWL> In-Reply-To: <17499.13551.536909.255941@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 498 James Carlson wrote: > James Carlson writes: >>> Maybe it's not this project but it sure would be nice if a future S10Ux >>> update didn't do that any more. >> This project fixes that problem by using pkghistory; see the original >> specification. > > Ah, but for Minor release only and not for patches. I don't know if > we have the right mechanisms (and policies!) to do this with a patch. and have it work correctly regardless of how the customer installed the system ! -- Darren J Moffat From sacadmin Fri May 5 08:11:31 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k45FBVIQ018355 for ; Fri, 5 May 2006 08:11:31 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k45FBUTF012572 for ; Fri, 5 May 2006 08:11:30 -0700 (PDT) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k45FBUKe012528 for ; Fri, 5 May 2006 09:11:30 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IYS00001SASWI00@mail-amer.sun.com> (original mail from Rishi.Srivatsavai@Sun.COM) for psarc@sac.sfbay.sun.com; Fri, 05 May 2006 09:11:30 -0600 (MDT) Received: from 129.148.174.36 ([129.148.174.36]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IYS00AN0SV59WF7@mail-amer.sun.com>; Fri, 05 May 2006 09:11:30 -0600 (MDT) Date: Fri, 05 May 2006 11:10:54 -0400 From: Rishi Srivatsavai Subject: Re: 2006/299 Single hosts File In-reply-to: <445AB5ED.3040705@sun.com> Sender: Rishi.Srivatsavai@Sun.COM To: Darren Reed Cc: Sebastien Roy , psarc@sac.sfbay.sun.com Message-id: <1146841854.16790.30.camel@waltair> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.333 Content-type: text/plain Content-transfer-encoding: 7BIT References: <1146791473.23989.56.camel@strat.East.Sun.COM> <445AB5ED.3040705@sun.com> Status: RO Content-Length: 1052 On Thu, 2006-05-04 at 22:18, Darren Reed wrote: > What does this case have to say for software that independantly > parses /etc/hosts and emits an error (and maybe stops processing > the file) if it doesn't find a line that is one of: > > a) empty > b) a comment > c) starts with an IP address > NetBSD based UNIXes already have a single hosts file from the beginning. Any portable code out there doing such parsing should already handle such lines in /etc/hosts. It is unlikely that a line of unknown format would cause a parser to bail entirely as opposed to skipping the line (f.e. our own parser in our hosts libnsl backend). Bringing Solaris closer to NetBSD in this regard is also a good thing. We will also be updating the release notes and documentation. There is a tradeoff here but it is also clear which side of the tradeoff we should take based on the problems from the previous design choice. There is greater harm with maintaining two separate files than the harm to customers having to update their parsers. Rishi From sacadmin Fri May 5 08:18:24 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k45FIOIQ018397 for ; Fri, 5 May 2006 08:18:24 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k45FINTF015953 for ; Fri, 5 May 2006 08:18:23 -0700 (PDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k45FINKe017229 for ; Fri, 5 May 2006 09:18:23 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IYS00501SPUPK00@mail-amer.sun.com> (original mail from Rishi.Srivatsavai@Sun.COM) for psarc@sac.sfbay.sun.com; Fri, 05 May 2006 09:18:23 -0600 (MDT) Received: from 129.148.174.36 ([129.148.174.36]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IYS00088T6MYVA0@mail-amer.sun.com>; Fri, 05 May 2006 09:18:23 -0600 (MDT) Date: Fri, 05 May 2006 11:17:47 -0400 From: Rishi Srivatsavai Subject: Re: 2006/299 Single hosts File In-reply-to: <1146798076.22586.75.camel@thunk> Sender: Rishi.Srivatsavai@Sun.COM To: Bill Sommerfeld Cc: Darren Reed , Sebastien Roy , psarc@sac.sfbay.sun.com Message-id: <1146842267.16790.37.camel@waltair> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.333 Content-type: text/plain Content-transfer-encoding: 7BIT References: <1146791473.23989.56.camel@strat.East.Sun.COM> <445AB5ED.3040705@sun.com> <1146798076.22586.75.camel@thunk> Status: RO Content-Length: 442 On Thu, 2006-05-04 at 23:01, Bill Sommerfeld wrote: > That said, on a number of aliases I've seen recommendations that people > symlink the files to each other rather than keeping them in sync > manually. > > I discovered that if you *do* symlink the files, an upgrade will break > the link and give you a separate ipnodes file back. > Yes we ran into this as well and as Jim noted in previous mail we fixed it by using pkghistory. Rishi From sacadmin Fri May 5 08:28:04 2006 Received: from phys-bur1-1 (phys-bur1-1.East.Sun.COM [129.148.13.15]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k45FS3IQ018630 for ; Fri, 5 May 2006 08:28:03 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IYS00301TILE5@bur-mail2.east.sun.com> (original mail from sebastien.roy@sun.com) for psarc@sac.sfbay.sun.com; Fri, 05 May 2006 11:28:03 -0400 (EDT) Received: from punchin-seb.East.Sun.COM (punchin-seb.East.Sun.COM [129.148.19.4]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IYS006ZZTMRQM@bur-mail2.east.sun.com>; Fri, 05 May 2006 11:28:03 -0400 (EDT) Date: Fri, 05 May 2006 11:26:58 -0400 From: Sebastien Roy Subject: Re: 2006/299 Single hosts File In-reply-to: <1146842267.16790.37.camel@waltair> To: Rishi Srivatsavai Cc: Bill Sommerfeld , Darren Reed , psarc@sac.sfbay.sun.com Message-id: <1146842818.3088.37.camel@localhost> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.6.1 Content-type: text/plain Content-transfer-encoding: 7BIT References: <1146791473.23989.56.camel@strat.East.Sun.COM> <445AB5ED.3040705@sun.com> <1146798076.22586.75.camel@thunk> <1146842267.16790.37.camel@waltair> Status: RO Content-Length: 1277 On Fri, 2006-05-05 at 11:17 -0400, Rishi Srivatsavai wrote: > On Thu, 2006-05-04 at 23:01, Bill Sommerfeld wrote: > > That said, on a number of aliases I've seen recommendations that people > > symlink the files to each other rather than keeping them in sync > > manually. > > > > I discovered that if you *do* symlink the files, an upgrade will break > > the link and give you a separate ipnodes file back. > > > Yes we ran into this as well and as Jim noted in previous mail we > fixed it by using pkghistory. No, I think there's confusion about the original comment. What Bill is referring to is that it would be nice if an upgrade to a _s10uX_ build didn't blow away the symbolic links that people had previously manually created from ipnodes to hosts to workaround this mayhem. The point of the comment is that this case doesn't help people who are currently working around the existing brokenness until they upgrade to Nevada. Until they do, those people have to manually maintain those symbolic links on every upgrade, since the package database in s10 still has ipnodes as an editable file. This case doesn't prevent another case from suggesting a method of preserving such symlinks in a patch (if that's possible.) This case doesn't address that issue. -Seb From sacadmin Fri May 5 11:20:35 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.104.45]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k45IKYIQ000872 for ; Fri, 5 May 2006 11:20:35 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with SMTP id k45IKSqS610743; Fri, 5 May 2006 11:20:33 -0700 (PDT) Message-Id: <200605051820.k45IKSqS610743@jurassic.eng.sun.com> Date: Fri, 5 May 2006 08:19:00 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: 2006/299 Single hosts File To: sommerfeld@sun.com, julian.pullen@sun.com, Darren.Reed@sun.com, Rishi.Srivatsavai@sun.com, Sebastien.Roy@sun.com, psarc@sac.sfbay.sun.com, james.d.carlson@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: UEFGr+UPaz6rNhnQscFqpg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 410 So, I seem to remember that this was a serious topic of discussion (Why two files?) in the original IPv6 case. Does anybody remember the significant arguments presented at that time (or do I need to look them up)? If we discussed this at the time (which assumes my memory isn't failing, which might not be a good assumption), we should have those rationalizations in mind when we review this case. - jek3 From sacadmin Fri May 5 11:26:17 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.104.31]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k45IQHIQ001507 for ; Fri, 5 May 2006 11:26:17 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with SMTP id k45IQAgU612765; Fri, 5 May 2006 11:26:16 -0700 (PDT) Message-Id: <200605051826.k45IQAgU612765@jurassic.eng.sun.com> Date: Fri, 5 May 2006 08:24:44 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: 2006/299 Single hosts File To: Rishi.Srivatsavai@sun.com, sebastien.roy@sun.com Cc: sommerfeld@sun.com, Darren.Reed@sun.com, psarc@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: JdyhI1DzeQj0DHT7B+O39g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 478 > From: Sebastien Roy ... > This case doesn't prevent another case from suggesting a method of > preserving such symlinks in a patch (if that's possible.) This case > doesn't address that issue. Just for the record, I'd put such a case under a powerful microscope looking for flaws. I inherited a bunch of install scripts which try to guess what somebody might of done and its a lossing proposition. I understand that this isn't this case. - jek3 From sacadmin Fri May 5 11:36:07 2006 Received: from phys-bur1-1 (phys-bur1-1.East.Sun.COM [129.148.13.15]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k45Ia6IQ001885 for ; Fri, 5 May 2006 11:36:06 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IYT0000122PMQ@bur-mail2.east.sun.com> (original mail from sebastien.roy@sun.com) for psarc@sac.sfbay.sun.com; Fri, 05 May 2006 14:36:06 -0400 (EDT) Received: from punchin-seb.East.Sun.COM (punchin-seb.East.Sun.COM [129.148.19.4]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IYT00H8L2C6HY@bur-mail2.east.sun.com>; Fri, 05 May 2006 14:36:06 -0400 (EDT) Date: Fri, 05 May 2006 14:35:01 -0400 From: Sebastien Roy Subject: Re: 2006/299 Single hosts File In-reply-to: <200605051820.k45IKSqS610743@jurassic.eng.sun.com> To: Joseph Kowalski Cc: sommerfeld@sun.com, Julian.Pullen@Sun.COM, Darren.Reed@Sun.COM, Rishi.Srivatsavai@Sun.COM, psarc@sac.sfbay.sun.com, James.D.Carlson@Sun.COM Message-id: <1146854101.3088.85.camel@localhost> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.6.1 Content-type: text/plain Content-transfer-encoding: 7BIT References: <200605051820.k45IKSqS610743@jurassic.eng.sun.com> Status: RO Content-Length: 2155 On Fri, 2006-05-05 at 08:19 -1000, Joseph Kowalski wrote: > So, I seem to remember that this was a serious topic of discussion (Why > two files?) in the original IPv6 case. > > Does anybody remember the significant arguments presented at that time > (or do I need to look them up)? If we discussed this at the time (which > assumes my memory isn't failing, which might not be a good assumption), we > should have those rationalizations in mind when we review this case. Allow me to quote from the PSARC/1998/039 opinion to bring this into direct context: > The reviewed specification [1] calls for a new set of com- > mands and a new ``hosts6'' database for IPv6 addresses, dis- > joint from and supplementing the existing IPv4 commands and > files. The committee expressed a concern that, if IPv6 is as > successful as it is expected to be, IPv6 addresses will > eventually be used almost universally, and having to search > multiple databases will become an unfortunate historical > artifact. The committee expressed a strong preference that > the project instead create a new database (without ``6'' in > its name!) that incorporates both IPv4 and IPv6 addresses. > IPv6-aware tools could then use the new database > exclusively, The existing database (/etc/hosts and friends), > containing only IPv4 addresses, would be left for the inde- > finite future for the sake of ``legacy'' applications, but > eventually the old interfaces and databases could be > declared obsolete. > > The project team has a leadership role in IETF for IPv6 nam- > ing. The committee required that the team request the IETF > to approve a unified file with a standard name and present a > follow-on case (probably a fast-track) to conform to the > standard. In a way, this case _is_ that follow-on case, as the de-facto industry standard (as implemented by the BSD UNIXs and Linux) is to put everything in /etc/hosts at this point (although the IETF had nothing to do with that). This case is following the spirit of that opinion, in that there will be no split between where IPv6 and IPv4 mappings are stored. -Seb From sacadmin Fri May 5 11:39:17 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k45IdHIQ001954 for ; Fri, 5 May 2006 11:39:17 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k45IdHoc019599 for ; Fri, 5 May 2006 11:39:17 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k45IdGKe019033 for ; Fri, 5 May 2006 12:39:16 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IYT00G0120CME00@mail-amer.sun.com> (original mail from Rishi.Srivatsavai@Sun.COM) for psarc@sac.sfbay.sun.com; Fri, 05 May 2006 12:39:16 -0600 (MDT) Received: from 129.148.174.36 ([129.148.174.36]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IYT00NDA2HF2W40@mail-amer.sun.com>; Fri, 05 May 2006 12:39:16 -0600 (MDT) Date: Fri, 05 May 2006 14:38:40 -0400 From: Rishi Srivatsavai Subject: Re: 2006/299 Single hosts File In-reply-to: <200605051820.k45IKSqS610743@jurassic.eng.sun.com> Sender: Rishi.Srivatsavai@Sun.COM To: Joseph Kowalski Cc: sommerfeld@Sun.COM, julian.pullen@Sun.COM, Darren.Reed@Sun.COM, sebastien.roy@Sun.COM, psarc@sac.sfbay.sun.com, James.D.Carlson@Sun.COM, Rishi.Srivatsavai@Sun.COM Message-id: <1146854320.16790.73.camel@waltair> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.333 Content-type: text/plain Content-transfer-encoding: 7BIT References: <200605051820.k45IKSqS610743@jurassic.eng.sun.com> Status: RO Content-Length: 931 On Fri, 2006-05-05 at 14:19, Joseph Kowalski wrote: > So, I seem to remember that this was a serious topic of discussion (Why > two files?) in the original IPv6 case. > > Does anybody remember the significant arguments presented at that time > (or do I need to look them up)? If we discussed this at the time (which > assumes my memory isn't failing, which might not be a good assumption), we > should have those rationalizations in mind when we review this case. > >From the case logs (sec 4.1) in the original IPv6 case* there was discussion on multiple databases. But in the end a new database (ipnodes) was chosen with the hope that IPv6 will be used universally and the /etc/hosts database will be left for sake of legacy apps and eventually shall be declared obsolete. This hasn't happened and hence we have a problem maintaining two databases. Rishi [*] http://sac.eng/Archives/CaseLog/arc/PSARC/1998/039/opinion.txt From sacadmin Fri May 5 11:47:06 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k45Il5IQ002208 for ; Fri, 5 May 2006 11:47:06 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k45Il41E010719; Fri, 5 May 2006 14:47:04 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k45Il4Zw010716; Fri, 5 May 2006 14:47:04 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17499.40360.667500.747230@gargle.gargle.HOWL> Date: Fri, 5 May 2006 14:47:04 -0400 From: James Carlson To: Sebastien Roy Cc: Joseph Kowalski , sommerfeld@sun.com, Julian.Pullen@sun.com, Darren.Reed@sun.com, Rishi.Srivatsavai@sun.com, psarc@sac.sfbay.sun.com Subject: Re: 2006/299 Single hosts File In-Reply-To: Sebastien Roy's message of 5 May 2006 14:35:01 References: <200605051820.k45IKSqS610743@jurassic.eng.sun.com> <1146854101.3088.85.camel@localhost> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1538 Sebastien Roy writes: > In a way, this case _is_ that follow-on case, as the de-facto industry > standard (as implemented by the BSD UNIXs and Linux) is to put > everything in /etc/hosts at this point (although the IETF had nothing to > do with that). This case is following the spirit of that opinion, in > that there will be no split between where IPv6 and IPv4 mappings are > stored. It's also worth noting that the feared profusion of one address type over the other hasn't happened (if anything, it's much more common to see a v4 host with a large pile of local aliases than a v6 host doing the same), and that where you have a large number of entries, you frankly don't want them in files anyway, as it makes your network unmanageable. That's what the DNS is all about. Also, as it's not bits on the wire, the IETF isn't going to standardize this. At best, if they cared at all (which, with DNS being the standard, I doubt strongly), it'd be an informational document that someone else (Open Group?) could adopt. Even that seems quite doubtful. Thus, being compatible with the rest of the known universe seems like the right path. It'd sort of be nice if we hadn't also done the unattractive /etc/hosts -> /etc/inet/hosts conversion, but that's long past and probably not worth addressing^Wchanging. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Fri May 5 11:51:53 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.104.45]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k45IprIQ002443 for ; Fri, 5 May 2006 11:51:53 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with SMTP id k45Ipk5D633451; Fri, 5 May 2006 11:51:51 -0700 (PDT) Message-Id: <200605051851.k45Ipk5D633451@jurassic.eng.sun.com> Date: Fri, 5 May 2006 08:50:19 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: 2006/299 Single hosts File To: Joseph.Kowalski@eng.sun.com, Sebastien.Roy@Sun.COM Cc: sommerfeld@Sun.COM, Julian.Pullen@Sun.COM, Darren.Reed@Sun.COM, Rishi.Srivatsavai@Sun.COM, psarc@sac.sfbay.sun.com, James.D.Carlson@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: rSoMdEGp9jbKbpONttA6pg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 597 Thanks for the opinion excerpt. I know its not in the mail log, but it might be good to include this somehow in the materials (an appendex in the spec?). I guess the ARC wimped out with the "future case" advisory rather than a "do it now" TCR because of concern that any "do it now" TCR might conflict with future IETF actions. Now we are at the point that any IETF action would need mimic the current common implementation, so we can move forward. I guess the ARC gets "I told you so" points, with a deduction for wimping out. (And we know what "I told you so" points are worth.) - jek3 From sacadmin Fri May 5 11:54:20 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.104.45]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k45IsKIQ002788 for ; Fri, 5 May 2006 11:54:20 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with SMTP id k45IsD3v634670; Fri, 5 May 2006 11:54:18 -0700 (PDT) Message-Id: <200605051854.k45IsD3v634670@jurassic.eng.sun.com> Date: Fri, 5 May 2006 08:52:45 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: 2006/299 Single hosts File To: Joseph.Kowalski@eng.sun.com, Rishi.Srivatsavai@Sun.COM Cc: sommerfeld@Sun.COM, julian.pullen@Sun.COM, Darren.Reed@Sun.COM, sebastien.roy@Sun.COM, psarc@sac.sfbay.sun.com, James.D.Carlson@Sun.COM, Rishi.Srivatsavai@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: E8I4f596mTD8AQr2H6RnHA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 641 > From: Rishi Srivatsavai ... > >From the case logs (sec 4.1) in the original IPv6 case* there was > discussion > on multiple databases. But in the end a new database (ipnodes) was > chosen > with the hope that IPv6 will be used universally and the /etc/hosts > database > will be left for sake of legacy apps and eventually shall be declared > obsolete. > This hasn't happened and hence we have a problem maintaining two > databases. Just to snivel, I'm not sure that universal use of IPv6 still isn't in our future. The abandonment of IPv4 is just happening *much* slower than at least I expected. - jek3 From sacadmin Fri May 5 11:58:35 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.104.45]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k45IwZIQ003070 for ; Fri, 5 May 2006 11:58:35 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with SMTP id k45IwT88636172; Fri, 5 May 2006 11:58:34 -0700 (PDT) Message-Id: <200605051858.k45IwT88636172@jurassic.eng.sun.com> Date: Fri, 5 May 2006 08:57:01 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: 2006/299 Single hosts File To: Joseph.Kowalski@eng.sun.com, Rishi.Srivatsavai@Sun.COM Cc: sommerfeld@Sun.COM, julian.pullen@Sun.COM, Darren.Reed@Sun.COM, sebastien.roy@Sun.COM, psarc@sac.sfbay.sun.com, James.D.Carlson@Sun.COM, Rishi.Srivatsavai@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: MhkiJpBMEgaTeDTKOD8qYw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 517 Perhaps a fair answer is a simple "No", but will this project have any effect on those annoying questions at installation time? Use IPv6? Are you sure? I'm just hoping against hope that this *might* help clean-up one of my pet peeves. (I'm pretty sure the history is that this question and the kerberos question were done out of the main body of install in some release many moons ago due to schedule concerns with the intent of rolling them into the main body in the next release. Never happened.) - jek3 From sacadmin Fri May 5 12:01:20 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.104.45]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k45J1KIQ003308 for ; Fri, 5 May 2006 12:01:20 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with SMTP id k45J1Cjf637803; Fri, 5 May 2006 12:01:18 -0700 (PDT) Message-Id: <200605051901.k45J1Cjf637803@jurassic.eng.sun.com> Date: Fri, 5 May 2006 08:59:45 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: 2006/299 Single hosts File To: sebastien.roy@sun.com, james.d.carlson@sun.com Cc: Joseph.Kowalski@eng.sun.com, sommerfeld@sun.com, Julian.Pullen@sun.com, Darren.Reed@sun.com, Rishi.Srivatsavai@sun.com, psarc@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: vkycJa7UG1NlcJKQtSIdFQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 369 > From: James Carlson ... > It'd sort of be nice if we hadn't also done the unattractive > /etc/hosts -> /etc/inet/hosts conversion, but that's long past and > probably not worth addressing^Wchanging. That goes back to the original SunOS/SVr4 merge and is for SunOS compatibility. Welcome to the Way Back machine Mr. Peabody! 8^) - jek3 From sacadmin Fri May 5 12:03:02 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.104.31]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k45J32IQ003345 for ; Fri, 5 May 2006 12:03:02 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with SMTP id k45J2tXF638520; Fri, 5 May 2006 12:03:00 -0700 (PDT) Message-Id: <200605051903.k45J2tXF638520@jurassic.eng.sun.com> Date: Fri, 5 May 2006 09:01:28 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: 2006/299 Single hosts File To: Joseph.Kowalski@eng.sun.com, Sebastien.Roy@Sun.COM Cc: sommerfeld@Sun.COM, Julian.Pullen@Sun.COM, Darren.Reed@Sun.COM, Rishi.Srivatsavai@Sun.COM, psarc@sac.sfbay.sun.com, James.D.Carlson@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: q4ExWz/TdLpIKwhcS2EdUA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 213 Sorry... > Thanks for the opinion excerpt. I know its not in the mail log, but it Should be "now in the mail log". Far be it for me to assert our mail archiving tools might be broken. 8^) - jek3 From sacadmin Fri May 5 12:10:53 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k45JAqIQ003833 for ; Fri, 5 May 2006 12:10:52 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k45JApx8010927; Fri, 5 May 2006 15:10:51 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k45JAp2V010924; Fri, 5 May 2006 15:10:51 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17499.41787.458476.108274@gargle.gargle.HOWL> Date: Fri, 5 May 2006 15:10:51 -0400 From: James Carlson To: Joseph Kowalski Cc: Rishi.Srivatsavai@Sun.COM, sommerfeld@Sun.COM, julian.pullen@Sun.COM, Darren.Reed@Sun.COM, sebastien.roy@Sun.COM, psarc@sac.sfbay.sun.com Subject: Re: 2006/299 Single hosts File In-Reply-To: Joseph Kowalski's message of 5 May 2006 08:57:01 References: <200605051858.k45IwT88636172@jurassic.eng.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 969 Joseph Kowalski writes: > Perhaps a fair answer is a simple "No", but will this project have any > effect on those annoying questions at installation time? > > Use IPv6? > > Are you sure? I don't see how it could. Those questions result either in having IPv6 interface plumbed or not plumbed, and the system makes some subtle (and not so subtle) choices based on the "one or more IPv6 interfaces plumbed" flag at boot time. They're really not about the /etc/hosts file. This case is. I agree the install-time question is awful, and needs to be nuked. We need to figure out how to do so without breaking existing v4-only users, and I don't think this case (which just fixes up the ipnodes botch) is the right one to carry that burden. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Mon May 8 14:55:45 2006 Received: from n1arc.sfbay.sun.com (n1arc.SFBay.Sun.COM [10.11.1.49]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k48LtjIQ019895 for ; Mon, 8 May 2006 14:55:45 -0700 (PDT) Received: from [192.168.100.83] (vpn-129-150-21-204.SFBay.Sun.COM [129.150.21.204]) by n1arc.sfbay.sun.com (8.13.4+Sun/8.13.3) with ESMTP id k48LtLBd011641; Mon, 8 May 2006 14:55:21 -0700 (PDT) In-Reply-To: <1146791473.23989.56.camel@strat.East.Sun.COM> References: <1146791473.23989.56.camel@strat.East.Sun.COM> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: psarc@sac.sfbay.sun.com, Rishi Srivatsavai Content-Transfer-Encoding: 7bit From: Allen Wittenauer Subject: Re: 2006/299 Single hosts File Date: Mon, 8 May 2006 14:56:03 -0700 To: Sebastien Roy X-Mailer: Apple Mail (2.746.2) Status: RO Content-Length: 648 On May 4, 2006, at 6:11 PM, Sebastien Roy wrote: > This case proposes to remove the current limitation in maintaining two > databases for IP addresses and to avoid the problems posed when > entries > in the two databases are conflicting. The /etc/inet/hosts database > will be the single configuration file that associates host names with > their IP addresses, both IPv4 and IPv6 addresses. The /etc/inet/ > ipnodes > file will be left as a symlink to /etc/inet/hosts for backwards > compatibility. How does this change impact NIS servers? Currently, the Makefile processes /etc/inet/hosts and /etc/inet/ipnodes differently. From sacadmin Tue May 9 01:03:04 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k49834IQ027451 for ; Tue, 9 May 2006 01:03:04 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k48NxToc015584 for ; Mon, 8 May 2006 16:59:29 -0700 (PDT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k48NxTKe010657 for ; Mon, 8 May 2006 17:59:29 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IYZ00D010CMOM00@mail-amer.sun.com> (original mail from Rishi.Srivatsavai@Sun.COM) for psarc@sac.sfbay.sun.com; Mon, 08 May 2006 17:59:28 -0600 (MDT) Received: from waltair.East.Sun.COM ([129.148.174.36]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IYZ003PG1B3OHA0@mail-amer.sun.com>; Mon, 08 May 2006 17:59:28 -0600 (MDT) Date: Mon, 08 May 2006 20:58:54 -0400 From: Rishi.Srivatsavai@sun.com Subject: Re: 2006/299 Single hosts File In-reply-to: Sender: Rishi.Srivatsavai@sun.com To: Allen Wittenauer Cc: Sebastien Roy , psarc@sac.sfbay.sun.com, Rishi Srivatsavai Message-id: <20060509005854.GA10688@waltair> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-Operating-System: Solaris Nevada/5.11 (i86pc) References: <1146791473.23989.56.camel@strat.East.Sun.COM> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 910 Allen Wittenauer (allenw@sun.com) wrote: > > On May 4, 2006, at 6:11 PM, Sebastien Roy wrote: > > >This case proposes to remove the current limitation in maintaining two > >databases for IP addresses and to avoid the problems posed when > >entries > >in the two databases are conflicting. The /etc/inet/hosts database > >will be the single configuration file that associates host names with > >their IP addresses, both IPv4 and IPv6 addresses. The /etc/inet/ > >ipnodes > >file will be left as a symlink to /etc/inet/hosts for backwards > >compatibility. > > How does this change impact NIS servers? Currently, the Makefile > processes /etc/inet/hosts and /etc/inet/ipnodes differently. This case proposes no changes to NIS ipnodes backend. As noted in the case proposal NIS servers shall continue to use separate maps for hosts and ipnodes. This will be handled in another case. Rishi From sacadmin Tue May 9 16:30:09 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.56.36]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k49NU9u8005445 for ; Tue, 9 May 2006 16:30:09 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k49NU7PV873273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 9 May 2006 16:30:09 -0700 (PDT) Message-ID: <446125FF.6060001@sun.com> Date: Tue, 09 May 2006 16:30:07 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Joseph Kowalski CC: sommerfeld@sun.com, julian.pullen@sun.com, Darren.Reed@sun.com, Rishi.Srivatsavai@sun.com, Sebastien.Roy@sun.com, psarc@sac.sfbay.sun.com, james.d.carlson@sun.com Subject: Re: 2006/299 Single hosts File References: <200605051820.k45IKSqS610743@jurassic.eng.sun.com> In-Reply-To: <200605051820.k45IKSqS610743@jurassic.eng.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 4122 Joseph Kowalski wrote: > So, I seem to remember that this was a serious topic of discussion (Why > two files?) in the original IPv6 case. > > Does anybody remember the significant arguments presented at that time > (or do I need to look them up)? If we discussed this at the time (which > assumes my memory isn't failing, which might not be a good assumption), we > should have those rationalizations in mind when we review this case. What I recall (which might be disjoint from reality ;-) has the following components: - for DNS we needed two different "databases" since DNS looks up IPv6 and IPv4 using different record types, and we didn't want to pay the overhead of always lookup up both AAAA and A records if the application is only interested in A. - there was a concern about scripts and applications potentially doing their own parsing of /etc/hosts, (and also ypmatch output I think) - we seem to have utterly missed the implication that if folks want "files" first in nsswitch.conf, then since applications/getipnodebyname/getaddrinfo look in ipnodes before hosts, the implication is that folks have to put IPv4 addresses in /etc/inet/ipnodes. The experience seems to indicate that the second concern wasn't much to worry about. But there are several things that concern me about this proposal: - if it is safe to put IPv6 addresses in /etc/hosts, isn't it also safe to put them in the hosts NIS map? - our documentation says that the ipnodes database is the future, but this proposal is essentially reversing this by saying that the hosts database is the future. Thus I think we should make this clear in the documentation. - it still isn't clear to me that we have the interaction and order between the application/getipnodebyname/getaddrinfo preference for IPv6 vs. IPv6 addresses and the name service switch worked out. To dwell on the last point, today if an application says "prefer IPv6" then the system will first do a lookup in ipnodes (which for DNS will look for AAAA records), and if none found, look in hosts (which for DNS will look for A records). For both the hosts and ipnodes lookups we follow nsswitch.conf ordering. But if the hosts and ipnodes databases become the same for files (and probably should become the same for NIS), the that order seems quite awkward. It would seem more natural to have a single backend that would take the preference into account, so that we can look at the nsswitch.conf order first, and then in each backend determine whether the application wants to look for IPv6 before IPv4. (And, the latter is just a performance optimization that we want to retain for DNS; for files and NIS the backend can look for both in the single hosts database and then getaddrinfo/gethostbyname/etc can filter out the undesired address family.) If we turned things around that way we'd get a behavior for getaddrinfo(PF_UNSPEC) of (assuming nsswitch.conf has hosts:files nis dns): - call files backend asking for PF_UNSPEC Returns everything that matched in /etc/inet/hosts - call nis backend asking for PF_UNSPEC Returns everything that matched in hosts map - call dns backend asking for PF_UNSPEC First look for AAAA. If none found look for A records. - getaddrinfo orders the results so that IPv6 addresses come first getaddrinfo(PF_INET) (and gethostbyname) would cause similar things: - call files backend asking for PF_INET Returns everything that matched in /etc/inet/hosts - call nis backend asking for PF_INET Returns everything that matched in hosts map - call dns backend asking for PF_INET Look for A records. - getaddrinfo removes any IPv6 addresses from the result (or this resposibility lies with the backend??) If the above is what we want the future to be, then we should - apply ipnodes->host "symlink" to NIS in addition to files - start the obsolete process for the ipnodes database (documentation) - fix the getXbyY backend/frontend interaction to get the above behavior From this fasttrack I can't tell what we want the future to be, hence I'm a bit concerned. Erik From sacadmin Wed May 10 06:37:01 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4ADb1kS002626 for ; Wed, 10 May 2006 06:37:01 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k4ADbEKK003405; Wed, 10 May 2006 09:37:14 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k4ADbEYR003402; Wed, 10 May 2006 09:37:14 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17505.60554.233449.119704@gargle.gargle.HOWL> Date: Wed, 10 May 2006 09:37:14 -0400 From: James Carlson To: Erik Nordmark Cc: Joseph Kowalski , sommerfeld@sun.com, julian.pullen@sun.com, Darren.Reed@sun.com, Rishi.Srivatsavai@sun.com, Sebastien.Roy@sun.com, psarc@sac.sfbay.sun.com Subject: Re: 2006/299 Single hosts File In-Reply-To: Erik Nordmark's message of 9 May 2006 16:30:07 References: <200605051820.k45IKSqS610743@jurassic.eng.sun.com> <446125FF.6060001@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 4740 Erik Nordmark writes: > - for DNS we needed two different "databases" since DNS looks up IPv6 > and IPv4 using different record types, and we didn't want to pay the > overhead of always lookup up both AAAA and A records if the application > is only interested in A. DNS doesn't actually look up things in /etc/hosts. Instead, named (BIND) reads its own database, which does have separate A and AAAA records. At best, the issue could confuse awk scripts that people have written to convert from /etc/hosts into named files. But, for those folks who actually have named IPv6 addresses to worry about, they've long since done the trivial modifications needed to handle IPv6, because no other platform (as far as we know) actually split these two files up in the way Solaris did. > - if it is safe to put IPv6 addresses in /etc/hosts, isn't it also > safe to put them in the hosts NIS map? It should be. I'd prefer to see hosts.by{name,addr} become just an alias for ipnodes.by{name,addr}, as long as that doesn't introduce compatibility problems across versions. > - our documentation says that the ipnodes database is the future, but > this proposal is essentially reversing this by saying that the hosts > database is the future. Thus I think we should make this clear in the > documentation. Indeed. > To dwell on the last point, today if an application says "prefer IPv6" > then the system will first do a lookup in ipnodes (which for DNS will > look for AAAA records), and if none found, look in hosts (which for DNS > will look for A records). By default, the switch always looks in both places. It then tries to combine, convert, and filter the results from both lookups and present that to the application. And the results from that are quite counter-intuitive. For example, if you ask for IPv4 alone, it'll still look in ipnodes, and if it finds an IPv4 entry there, it'll *IGNORE* any entries in hosts. See: $SRC/lib/libnsl/nss/getipnodeby.c It's not a strict "ipnodes -- if none found -- hosts" sort of relationship. > For both the hosts and ipnodes lookups we > follow nsswitch.conf ordering. Yes, for files/dns/nis/et cetera. > But if the hosts and ipnodes databases become the same for files (and > probably should become the same for NIS), the that order seems quite > awkward. I think it already _is_ awkward. Given that it always does both lookups (except for a few trivial corner cases), and that ipnodes is always a combined file (both types of addresses), I can see no clear benefit to having these two remain separate. If ipnodes were IPv6-only, or if nsswitch.conf actually controlled the v6-versus-v4 query ordering, then there might have been a point. But neither of those seems to be true. > It would seem more natural to have a single backend that would > take the preference into account, so that we can look at the > nsswitch.conf order first, and then in each backend determine whether > the application wants to look for IPv6 before IPv4. (And, the latter is Agreed; the backend likely needs some work. > If we turned things around that way we'd get a behavior for > getaddrinfo(PF_UNSPEC) of (assuming nsswitch.conf has hosts:files nis dns): > - call files backend asking for PF_UNSPEC > Returns everything that matched in /etc/inet/hosts That's not what getaddrinfo does today. Instead, it calls getipnodebyname() with AF_INET6, AI_ALL|AI_V4MAPPED. That causes us to look in both places and merge the results. > - call nis backend asking for PF_UNSPEC > Returns everything that matched in hosts map We look in both hosts and ipnodes here and merge the results. What do we do if the NIS server is older than this project, and has IPv4 and IPv6 strictly segregated? A central problem here seems to be that DNS got this right, and none of the others did. In DNS, you have AAAA records for IPv6, and A records for IPv4. In all of the other databases, you have "ipnodes" for *both* address types, and "hosts" for the IPv4 subset alone. > If the above is what we want the future to be, then we should > - apply ipnodes->host "symlink" to NIS in addition to files Possibly, modulo compatibility concerns. I don't know what assumptions other systems may have made with the hosts/ipnodes maps. > - start the obsolete process for the ipnodes database (documentation) Possibly. There's certainly little point in it. > - fix the getXbyY backend/frontend interaction to get the above behavior That part is not clear to me. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Wed May 10 08:42:46 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4AFgkoO015808 for ; Wed, 10 May 2006 08:42:46 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4AFgkTF021611 for ; Wed, 10 May 2006 08:42:46 -0700 (PDT) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k4AFgiSX021852 for ; Wed, 10 May 2006 09:42:45 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZ2003013C97E00@mail-amer.sun.com> (original mail from Rishi.Srivatsavai@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 10 May 2006 09:42:44 -0600 (MDT) Received: from 129.148.174.36 ([129.148.174.36]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZ20019D3N51B00@mail-amer.sun.com>; Wed, 10 May 2006 09:42:42 -0600 (MDT) Date: Wed, 10 May 2006 11:41:38 -0400 From: Rishi Srivatsavai Subject: Re: 2006/299 Single hosts File In-reply-to: <446125FF.6060001@sun.com> Sender: Rishi.Srivatsavai@Sun.COM To: Erik Nordmark Cc: Joseph Kowalski , sommerfeld@Sun.COM, julian.pullen@Sun.COM, Darren.Reed@Sun.COM, Sebastien.Roy@Sun.COM, psarc@sac.sfbay.sun.com, James.D.Carlson@Sun.COM Message-id: <1147275698.10125.29.camel@waltair.east.sun.com> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.333 Content-type: text/plain Content-transfer-encoding: 7BIT References: <200605051820.k45IKSqS610743@jurassic.eng.sun.com> <446125FF.6060001@sun.com> Status: RO Content-Length: 3936 On Tue, 2006-05-09 at 19:30, Erik Nordmark wrote: > But there are several things that concern me about this proposal: > - if it is safe to put IPv6 addresses in /etc/hosts, isn't it also > safe to put them in the hosts NIS map? Yes that will happen with this case as NIS server running on a build containing these changes will have a merged hosts file. > - our documentation says that the ipnodes database is the future, but > this proposal is essentially reversing this by saying that the hosts > database is the future. Thus I think we should make this clear in the > documentation. Yes doc CRs have been filed. > - it still isn't clear to me that we have the interaction and order > between the application/getipnodebyname/getaddrinfo preference for IPv6 > vs. IPv6 addresses and the name service switch worked out. > > To dwell on the last point, today if an application says "prefer IPv6" > then the system will first do a lookup in ipnodes (which for DNS will > look for AAAA records), and if none found, look in hosts (which for DNS > will look for A records). For both the hosts and ipnodes lookups we > follow nsswitch.conf ordering. > > But if the hosts and ipnodes databases become the same for files (and > probably should become the same for NIS), the that order seems quite > awkward. It would seem more natural to have a single backend that would > take the preference into account, so that we can look at the > nsswitch.conf order first, and then in each backend determine whether > the application wants to look for IPv6 before IPv4. (And, the latter is > just a performance optimization that we want to retain for DNS; for > files and NIS the backend can look for both in the single hosts database > and then getaddrinfo/gethostbyname/etc can filter out the undesired > address family.) That is where we eventually need to end up, but we can't switch all of that at once, as there will be a mix of new clients querying old servers, and old clients querying new servers. Those kinds of compatibility issues can be addressed by a future case. > If we turned things around that way we'd get a behavior for > getaddrinfo(PF_UNSPEC) of (assuming nsswitch.conf has hosts:files nis dns): > - call files backend asking for PF_UNSPEC > Returns everything that matched in /etc/inet/hosts > - call nis backend asking for PF_UNSPEC > Returns everything that matched in hosts map > - call dns backend asking for PF_UNSPEC > First look for AAAA. If none found look for A records. > - getaddrinfo orders the results so that IPv6 addresses come first > > getaddrinfo(PF_INET) (and gethostbyname) would cause similar things: > - call files backend asking for PF_INET > Returns everything that matched in /etc/inet/hosts > - call nis backend asking for PF_INET > Returns everything that matched in hosts map > - call dns backend asking for PF_INET > Look for A records. > - getaddrinfo removes any IPv6 addresses from the result (or this > resposibility lies with the backend??) Yes, this is how we see the switch working in the future. This case doesn't preclude such a transition. > > If the above is what we want the future to be, then we should > - apply ipnodes->host "symlink" to NIS in addition to files This is being done by this case implicitly. NIS server will provide identical maps for hosts and ipnodes because of the symlink. > - start the obsolete process for the ipnodes database (documentation) Yes. > - fix the getXbyY backend/frontend interaction to get the above behavior It is not clear that this change as suggested can be done compatibly. For eg. what if a new client, expecting everything to be returned by a hosts query, queries an old server that only returns IPv4 in its hosts replies. The client won't be able to access IPv6 entries unless the client detects it is an old server, and automatically queries the ipnodes map. Rishi From sacadmin Wed May 10 08:53:48 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4AFrm7b016243 for ; Wed, 10 May 2006 08:53:48 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k4AFs2XR003986; Wed, 10 May 2006 11:54:02 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k4AFs2QL003983; Wed, 10 May 2006 11:54:02 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17506.3225.467049.891154@gargle.gargle.HOWL> Date: Wed, 10 May 2006 11:54:01 -0400 From: James Carlson To: Rishi Srivatsavai Cc: Erik Nordmark , Joseph Kowalski , sommerfeld@sun.com, julian.pullen@sun.com, Darren.Reed@sun.com, Sebastien.Roy@sun.com, psarc@sac.sfbay.sun.com Subject: Re: 2006/299 Single hosts File In-Reply-To: Rishi Srivatsavai's message of 10 May 2006 11:41:38 References: <200605051820.k45IKSqS610743@jurassic.eng.sun.com> <446125FF.6060001@sun.com> <1147275698.10125.29.camel@waltair.east.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1097 Rishi Srivatsavai writes: > > - fix the getXbyY backend/frontend interaction to get the above behavior > > It is not clear that this change as suggested can be done compatibly. > For eg. what if a new client, expecting everything to be returned > by a hosts query, queries an old server that only returns IPv4 in > its hosts replies. The client won't be able to access IPv6 entries > unless the client detects it is an old server, and automatically > queries the ipnodes map. Right. This implies that the client side must _always_ query both sides of the split when doing a query over the network. There's no real guarantee that anyone will ever upgrade those name server hosts. (Often, bits of infrastructure like that are on machines gathering dust in a closet somewhere. They're probably all still running 2.5.1. ;-}) We can probably revisit it in 2050 or so. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Wed May 10 10:28:53 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.104.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4AHSrtt025936 for ; Wed, 10 May 2006 10:28:53 -0700 (PDT) Received: from [192.168.100.83] (vpn-129-150-21-204.SFBay.Sun.COM [129.150.21.204]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4AHSqAI833563; Wed, 10 May 2006 10:28:52 -0700 (PDT) In-Reply-To: <1147275698.10125.29.camel@waltair.east.sun.com> References: <200605051820.k45IKSqS610743@jurassic.eng.sun.com> <446125FF.6060001@sun.com> <1147275698.10125.29.camel@waltair.east.sun.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Sebastien Roy , psarc@sac.sfbay.sun.com Content-Transfer-Encoding: 7bit From: Allen Wittenauer Subject: Re: 2006/299 Single hosts File Date: Wed, 10 May 2006 10:29:38 -0700 To: Rishi Srivatsavai X-Mailer: Apple Mail (2.746.2) Status: RO Content-Length: 574 On May 10, 2006, at 8:41 AM, Rishi Srivatsavai wrote: > On Tue, 2006-05-09 at 19:30, Erik Nordmark wrote: >> But there are several things that concern me about this proposal: >> - if it is safe to put IPv6 addresses in /etc/hosts, isn't it also >> safe to put them in the hosts NIS map? > > Yes that will happen with this case as NIS server running on a build > containing these changes will have a merged hosts file. ... except the /var/yp/Makefile will kick them out via stdhosts. [Which is why I asked earlier and basically told to wait for another case...] From sacadmin Wed May 10 10:37:30 2006 Received: from billybob.sfbay.sun.com (billybob.SFBay.Sun.COM [129.146.224.123]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4AHbUcL026382 for ; Wed, 10 May 2006 10:37:30 -0700 (PDT) Received: from billybob (billybob [129.146.224.123]) by billybob.sfbay.sun.com (8.13.6+Sun/8.13.6) with SMTP id k4AHfEo7104660; Wed, 10 May 2006 10:41:14 -0700 (PDT) Message-Id: <200605101741.k4AHfEo7104660@billybob.sfbay.sun.com> Date: Wed, 10 May 2006 10:41:14 -0700 (PDT) From: Shudong Zhou Reply-To: Shudong Zhou Subject: Re: 2006/299 Single hosts File To: Rishi.Srivatsavai@sun.com, allenw@sun.com Cc: Sebastien.Roy@sun.com, psarc@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 9UYV6Qj3DtQY++Q2eKNUjg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_13 SunOS 5.11 i86pc i386 Status: RO Content-Length: 190 Given the amount of email discussions, could the submitter clarify what the final propsal is? If there are changes from the original proposal, please send an updated spec. Thanks, Shudong From sacadmin Wed May 10 13:23:12 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4AKNBQQ007936 for ; Wed, 10 May 2006 13:23:11 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4AKNBTF018059 for ; Wed, 10 May 2006 13:23:11 -0700 (PDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k4AKNBKe007293 for ; Wed, 10 May 2006 14:23:11 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZ200D01G5WVJ00@mail-amer.sun.com> (original mail from Rishi.Srivatsavai@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 10 May 2006 14:23:11 -0600 (MDT) Received: from 129.148.174.36 ([129.148.174.36]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZ200DMKGMMEEQ0@mail-amer.sun.com>; Wed, 10 May 2006 14:23:11 -0600 (MDT) Date: Wed, 10 May 2006 16:22:08 -0400 From: Rishi Srivatsavai Subject: Re: 2006/299 Single hosts File In-reply-to: Sender: Rishi.Srivatsavai@Sun.COM To: Allen Wittenauer Cc: Sebastien Roy , psarc@sac.sfbay.sun.com Message-id: <1147292528.10125.45.camel@waltair.east.sun.com> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.333 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT References: <200605051820.k45IKSqS610743@jurassic.eng.sun.com> <446125FF.6060001@sun.com> <1147275698.10125.29.camel@waltair.east.sun.com> Status: RO Content-Length: 846 On Wed, 2006-05-10 at 13:29, Allen Wittenauer wrote: > On May 10, 2006, at 8:41 AM, Rishi Srivatsavai wrote: > > > On Tue, 2006-05-09 at 19:30, Erik Nordmark wrote: > >> But there are several things that concern me about this proposal: > >> - if it is safe to put IPv6 addresses in /etc/hosts, isn't it also > >> safe to put them in the hosts NIS map? > > > > Yes that will happen with this case as NIS server running on a build > > containing these changes will have a merged hosts file. > > ... except the /var/yp/Makefile will kick them out via stdhosts. > [Which is why I asked earlier and basically told to wait for another > case...] Yes that is correct, stdhosts filters out non-IPv4 addresses from the merged hosts file when creating NIS hosts map. I shall reflect the same in the updated spec I shall be mailing out. Rishi From sacadmin Wed May 10 15:51:22 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.68.36]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4AMpMi8019995 for ; Wed, 10 May 2006 15:51:22 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4AMpIff191140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 10 May 2006 15:51:20 -0700 (PDT) Message-ID: <44626E66.4010406@sun.com> Date: Wed, 10 May 2006 15:51:18 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: James Carlson CC: Joseph Kowalski , sommerfeld@sun.com, julian.pullen@sun.com, Darren.Reed@sun.com, Rishi.Srivatsavai@sun.com, Sebastien.Roy@sun.com, psarc@sac.sfbay.sun.com Subject: Re: 2006/299 Single hosts File References: <200605051820.k45IKSqS610743@jurassic.eng.sun.com> <446125FF.6060001@sun.com> <17505.60554.233449.119704@gargle.gargle.HOWL> In-Reply-To: <17505.60554.233449.119704@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 5793 James Carlson wrote: > Erik Nordmark writes: >> - for DNS we needed two different "databases" since DNS looks up IPv6 >> and IPv4 using different record types, and we didn't want to pay the >> overhead of always lookup up both AAAA and A records if the application >> is only interested in A. > > DNS doesn't actually look up things in /etc/hosts. Instead, named > (BIND) reads its own database, which does have separate A and AAAA > records. I know, and the behavior of the DNS *server* is not the issue here. The term "database" is what we use in e.g. nsswitch.conf(4) to describe the general concepts, which can be serviced by files, nis, dns, etc. > By default, the switch always looks in both places. It then tries to > combine, convert, and filter the results from both lookups and present > that to the application. > > And the results from that are quite counter-intuitive. For example, > if you ask for IPv4 alone, it'll still look in ipnodes, and if it > finds an IPv4 entry there, it'll *IGNORE* any entries in hosts. Odder than I thought. > Given that it always does both lookups (except for a few trivial > corner cases), and that ipnodes is always a combined file (both types > of addresses), I can see no clear benefit to having these two remain > separate. Agreed. > If ipnodes were IPv6-only, or if nsswitch.conf actually controlled the > v6-versus-v4 query ordering, then there might have been a point. But > neither of those seems to be true. > >> It would seem more natural to have a single backend that would >> take the preference into account, so that we can look at the >> nsswitch.conf order first, and then in each backend determine whether >> the application wants to look for IPv6 before IPv4. (And, the latter is > > Agreed; the backend likely needs some work. Actually, after I sent the mail I realized it might be possible to do the work in the getXbyY frontends (if it is too hard to change the frontend to backend interfaces). But it seems like to behavior we need is to first follow nsswitch.conf order, and then for each backend do the IPv6/IPv4 order that matches what the application asked for. >> If we turned things around that way we'd get a behavior for >> getaddrinfo(PF_UNSPEC) of (assuming nsswitch.conf has hosts:files nis dns): >> - call files backend asking for PF_UNSPEC >> Returns everything that matched in /etc/inet/hosts > > That's not what getaddrinfo does today. Instead, it calls > getipnodebyname() with AF_INET6, AI_ALL|AI_V4MAPPED. That causes us > to look in both places and merge the results. FWIW I was discussing the large scale behavior and not the implementation. > >> - call nis backend asking for PF_UNSPEC >> Returns everything that matched in hosts map > > We look in both hosts and ipnodes here and merge the results. What do > we do if the NIS server is older than this project, and has IPv4 and > IPv6 strictly segregated? I suspect we need to continue to merge the two for both the nis backend and the files backend. For the files backend we could argue that Install/Upgrade will make the /etc/inet/ipnodes link to /etc/inet/hosts, but if a customer has their own working content for those files, they might copy over whatever install/upgrade did. Maybe there are some worth while optimizations for both files and nis. For nis in many cases there might not be an ipnodes map, hence no merging work needed. For files we can have the backend stat /etc/inet/ipnodes and /etc/inet/hosts to check if one is a symlink to the other. But those are optimizations; for compatibility I suspect we need the behavior for both to be that of operating on the merged hosts and ipnodes files/maps. > A central problem here seems to be that DNS got this right, and none > of the others did. In DNS, you have AAAA records for IPv6, and A > records for IPv4. In all of the other databases, you have "ipnodes" > for *both* address types, and "hosts" for the IPv4 subset alone. I have vague recollections that the original IPv6 project team started with a hosts6 database with only IPv6 addresses in it. Somewhere during ARC review this was changed to be ipnodes and that it contain both IPv4 and IPv6 addresses. In hindsight having both in a single database was the right thing - it was just that it should have been called "hosts" instead of "ipnodes". (And the reason for a single database was so that in some future things would be efficient with only having to look in one place. But unfortunately we seem to be stuck for a while looking in both hosts and ipnodes.) I wish the project team and the ARC had had more courage to just put IPv6 addresses in /etc/inet/hosts. >> If the above is what we want the future to be, then we should >> - apply ipnodes->host "symlink" to NIS in addition to files > > Possibly, modulo compatibility concerns. I don't know what > assumptions other systems may have made with the hosts/ipnodes maps. By "systems" do you mean "operating systems", "computers", or something else? >> - start the obsolete process for the ipnodes database (documentation) > > Possibly. There's certainly little point in it. > >> - fix the getXbyY backend/frontend interaction to get the above behavior > > That part is not clear to me. If the desired end state is that with nsswitch.conf saying files, nis, dns, that the search order is as follows: 1. look for IPv6 in files 2. look for IPv4 in files 3. look for IPv6 in nis 4. look for IPv4 in nis 5. look for IPv6 in dns 6. look for IPv4 in dns then we need to change the behavior. Today we can't get the above order; we get the order 1, 3, 5, 2, 4, 6. The symlink of /etc/inet/ipnodes to /etc/inet/hosts effectively take care of the 1-2 order, but does nothing for 3-4. Erik From sacadmin Wed May 10 15:55:09 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.226.130]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4AMt9V8020793 for ; Wed, 10 May 2006 15:55:09 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4AMt6TX192399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 10 May 2006 15:55:08 -0700 (PDT) Message-ID: <44626F4A.7000706@sun.com> Date: Wed, 10 May 2006 15:55:06 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Rishi Srivatsavai CC: Joseph Kowalski , sommerfeld@sun.com, julian.pullen@sun.com, Darren.Reed@sun.com, Sebastien.Roy@sun.com, psarc@sac.sfbay.sun.com, James.D.Carlson@sun.com Subject: Re: 2006/299 Single hosts File References: <200605051820.k45IKSqS610743@jurassic.eng.sun.com> <446125FF.6060001@sun.com> <1147275698.10125.29.camel@waltair.east.sun.com> In-Reply-To: <1147275698.10125.29.camel@waltair.east.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 827 Rishi Srivatsavai wrote: > It is not clear that this change as suggested can be done compatibly. > For eg. what if a new client, expecting everything to be returned > by a hosts query, queries an old server that only returns IPv4 in > its hosts replies. The client won't be able to access IPv6 entries > unless the client detects it is an old server, and automatically > queries the ipnodes map. As I said in the response to Jim, for both files and nis, I suspect we need to have the client look in both databases to be able to provide compatibility. But if we are going down this path, then I think we should effectively remove the ipnodes line from nsswitch.conf; the backends for files and nis can look in both places, but there will be no need to control the order separately for "ipnodes" and "hosts". Erik From sacadmin Thu May 11 10:03:55 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4BH3t5b000081 for ; Thu, 11 May 2006 10:03:55 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4BH3toc016953 for ; Thu, 11 May 2006 10:03:55 -0700 (PDT) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k4BH3sSX003880 for ; Thu, 11 May 2006 11:03:54 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZ4001011MM3900@mail-amer.sun.com> (original mail from Rishi.Srivatsavai@Sun.COM) for psarc@sac.sfbay.sun.com; Thu, 11 May 2006 11:03:54 -0600 (MDT) Received: from waltair.East.Sun.COM ([129.148.174.36]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZ40090222H4M40@mail-amer.sun.com>; Thu, 11 May 2006 11:03:54 -0600 (MDT) Date: Thu, 11 May 2006 13:02:51 -0400 From: Rishi.Srivatsavai@Sun.COM Subject: Re: 2006/299 Single hosts File In-reply-to: <200605101741.k4AHfEo7104660@billybob.sfbay.sun.com> Sender: Rishi.Srivatsavai@Sun.COM To: Shudong Zhou Cc: Rishi.Srivatsavai@Sun.COM, allenw@Sun.COM, Sebastien.Roy@Sun.COM, psarc@sac.sfbay.sun.com Message-id: <20060511170250.GA14945@waltair> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-Operating-System: Solaris Nevada/5.11 (i86pc) References: <200605101741.k4AHfEo7104660@billybob.sfbay.sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 15114 Shudong Zhou (szhou@billybob.sfbay.sun.com) wrote: > Given the amount of email discussions, could the submitter clarify > what the final propsal is? If there are changes from the original > proposal, please send an updated spec. I have included an updated spec below. ----------------------------- Single hosts file Release binding: minor Problem ============== The /etc/inet/ipnodes database was created to hold both IPv4 and IPv6 host addresses. The ipnodes database is searched first by applications using the getaddrinfo()/getnameinfo() API. The /etc/inet/hosts database was left for legacy applications supporting only IPv4 addresses and calling the gethostby* API. Changes were approved in case PSARC/1998/039 and integrated in Solaris 8. The drawback of the split is IPv4 entries in both databases have to be always in sync. Problems arise in applications when an entry differs in the two databases and host lookup results vary depending on the API used. System administrators must make it a point when changing one file to update the other. The problem is documented in CR 6219146. The opinion for PSARC/1998/039 explains that a database separate from /etc/hosts be used to store both IPv4 and IPv6 addresses (this became /etc/inet/ipnodes), and that /etc/hosts remain for legacy applications and eventually be declared obsolete as IPv6 gains traction and IPv4 is phased out. The opinion also requested a follow-on case be filed to confirm a standard name agreed upon by the IETF for this new combined database. Since then, the rest of the industry has converged on using /etc/hosts as a combined database, not /etc/inet/ipnodes. This case is that follow-on case, confirming that /etc/hosts is the industry standard for storing all IP address mappings. Solution ======== This case proposes to remove the current limitation in maintaining two databases for IP addresses and to avoid the problems posed when entries in the two databases are conflicting. The /etc/inet/hosts database will be the single configuration file that associates host names with their IP addresses, both IPv4 and IPv6 addresses. The /etc/inet/ipnodes file will be left as a symlink to /etc/inet/hosts for backwards compatibility. Adding IPv6 address entries in /etc/inet/hosts does not break host lookups using the gethostby* API. In the gethostby* implementation addresses found in the database not in IPv4 address format are disregarded during the search. Host lookups using the getaddrinfo()/getnameinfo() API will also be unaffected after the ipnodes conversion to a symlink. We chose to leave the /etc/inet/ipnodes as a symlink and not remove the file entirely in keeping with the file's classification as a 'Stable' interface. Removing the file entirely runs the risk of breaking existing applications depending on the file and may cause users to re-create the ipnodes file to satisfy such applications. Keeping the symlink could also cause issues in applications expecting two distinct files holding IPv4 addresses. F.e. an application adding IPv4 addresses previously to two distinct hosts and ipnodes files may now add entries twice in the same hosts file. We feel the advantages of keeping a stable interface by keeping the ipnodes file as a symlink outweigh risks with applications continuing to treat the two files as distinct. Experience from other unix platforms which use a single hosts file suggests that software having problems parsing /etc/inet/hosts file with IPv6 address entries is extremely rare. Even if there are the cost of modifying such software is far less than the incurred cost in maintaining two separate databases. NetBSD based UNIXes and Linux have a single hosts file from the beginning. Bringing Solaris closer to NetBSD and Linux in this regard is also a good thing. Merge Script ============ The task of merging entries from the ipnodes database to the hosts database is performed by a class action script in the SUNWcsr package. The merge script copies over entries from the ipnodes database to the hosts database and in the resulting hosts file removes duplicate entries and coalesces multiple address entries of a hostname. When removing duplicate address lines the hostname entry from ipnodes is preserved over one in hosts database. The reason is nsswitch looks up entries first in ipnodes before hosts and we want to preserve that behavior after the merge. For hostname entry with multiple addresses, all entries are moved to consecutive lines in the resulting hosts file. When a duplicate entry is removed by the merge script any comment lines preceding the entry are also removed. However if the removed entry is the first in the file any preceding comment lines possibly specifying the file header are not removed. Solaris Upgrade =============== Solaris OS upgrade detects any configuration file changes in new package versions and renames the modified files as reference copies prior to the upgrade. The ipnodes file change to a symlink when found in the new package, the existing ipnodes file is renamed before upgrading the system. But this safeguard against losing configuration changes due to upgrade does not permit the class action script to merge ipnodes contents into hosts correctly. An entry therefore will be added in the SUNWcsr pkghistory to ignore the ipnodes file change and not rename the file. NIS ipnodes =========== This case does not propose any changes to nsswitch nor removing the ipnodes database from the switch file. NIS servers upgrading to a build containing the above changes will have a merged hosts file. But the maps for hosts and ipnodes will continue to be distinct as /var/yp/Makefile filters out all non-IPv4 addresses when creating the hosts map. The ipnodes map will have both IPv4 and IPv6 addresses. Interface Table =================== The following existing interfaces are affected: /etc/inet/hosts Stable /etc/inet/ipnodes Stable * Please note that PSARC/1998/039 case includes references to /etc/inet/hosts6 file. During review one of the issues raised was on the choice of filename. Though there is no explicit mention of ipnodes being chosen as the new filename the proposed /etc/inet/hosts6 filename was changed to /etc/inet/ipnodes. References ========== 1. PSARC/1998/039 "Naming Services Support of IPv6" 2. CR 6219146 "/etc/inet/hosts and /etc/inet/ipnodes need to be the same file" Manual page changes =================== The new hosts man page is listed below: File Formats hosts(4) NAME hosts - host name database SYNOPSIS /etc/inet/hosts /etc/hosts + /etc/inet/ipnodes + DESCRIPTION The hosts file is a local database that associates the names - of hosts with their Internet Protocol (IP) addresses. The + of hosts with their Internet Protocol (IP) addresses. IP + addresses can be either an IPv4 or an IPv6 address. The hosts file can be used in conjunction with, or instead of, other hosts databases, including the Domain Name System (DNS), the NIS hosts map, the NIS+ hosts table, or informa- tion from an LDAP server. Programs use library interfaces to access information in the hosts file. The hosts file has one entry for each IP address of each host. If a host has more than one IP address, it will have one entry for each, on consecutive lines. The format of each line is: IP-address official-host-name nicknames... Items are separated by any number of SPACE and/or TAB char- acters. The first item on a line is the host's IP address. The second entry is the host's official name. Subsequent entries on the same line are alternative names for the same machine, or "nicknames." Nicknames are optional. For a host with more than one IP address, consecutive entries for these addresses may contain the same or differ- ing nicknames. Different nicknames are useful for assigning distinct names to different addresses. A call to gethostbyname(3NSL) returns a hostent structure - containing the union of all addresses and nicknames from - each line containing a matching official name or nickname. + containing the union of all IPv4 addresses and nicknames + from each line containing a matching official name or + nickname. A call to getipnodebyname(3SOCKET) is similar, + but is capable of returning hostent structures + containing IPv4 and IPv6 addresses. Applications may + also preferably use the address-family independent + getaddrinfo(3SOCKET) API for name to address + lookups. A `#' indicates the beginning of a comment; characters up to the end of the line are not interpreted by routines that search the file. - Network addresses are written in the conventional "decimal - dot" notation and interpreted using the inet_addr routine - from the Internet address manipulation library, - inet(3SOCKET). + Network addresses are written in one of two ways: - This interface supports host names as defined in Internet - RFC 952 which states: + o The conventional "decimal dot" notation and interpreted + using the inet_addr routine from the Internet address + manipulation library, inet(3SOCKET). SunOS 5.10 Last change: 30 Sep 2005 1 File Formats hosts(4) + o The IP Version 6 protocol [IPV6], defined in RFC 1884 + and interpreted using the inet_pton() routine from the + Internet address manipulation library. See + inet(3SOCKET). + These interfaces supports node names as defined in Internet + RFC 952 which states: + A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24 characters drawn from the alphabet (A- Z), digits (0-9), minus sign (-), and period (.). Note that periods are only allowed when they serve to del- imit components of "domain style names". (See RFC 921, "Domain Name System Implementation Schedule," for back- ground). No blank or space characters are permitted as part of a name. No distinction is made between upper- case and lowercase. The first character must be an alpha character [or a digit. (RFC 1123 relaxed RFC 952's limitation of the first character to only alpha characters.)] The last character must not be a minus sign or period. Host names must not consist of numbers only. A host name must contain at least one alphabetical or special character. Although the interface accepts host names longer than 24 characters for the host portion (exclusive of the domain component), choosing names for hosts that adhere to the 24 character restriction will insure maximum interoperability on the Internet. A host which serves as a GATEWAY should have "-GATEWAY" or "-GW" as part of its name. Hosts which do not serve as Internet gateways should not use "-GATEWAY" and "-GW" as part of their names. A host which is a TAC should have "-TAC" as the last part of its host name, if it is a DoD host. Single character names or nicknames are not allowed. EXAMPLES Example 1: Example of a typical line from the hosts file. Here is a typical line from the hosts file: 192.9.1.20 gaia # John Smith + Example 2: Example of an IPv6 address entry. + + 2001:0db8:3c4d:55:a00:20ff:fe8e:f3ad myhost # John Smith + + SEE ALSO gethostbyname(3NSL), inet(3SOCKET), nsswitch.conf(4), resolv.conf(4) + Braden, B., editor, RFC 1123, Requirements for Internet + Hosts - Application and Support, Network Working Group, + October, 1989. + + Harrenstien, K., Stahl, M., and Feinler, E., RFC 952, DOD + INTERNET HOST TABLE SPECIFICATION, Network Working Group, + October 1985. + + Hinden, R., and Deering, S., editors, RFC 1884, IP Version 6 + Addressing Architecture, Network Working Group, December, + 1995. + + Postel, Jon, RFC 921, Domain Name System Implementation + Schedule - Revised, Network Working Group, October 1984. + + NOTES /etc/inet/hosts is the official SVR4 name of the hosts file. The symbolic link /etc/hosts exists for BSD compatibility. + The symbolic link /etc/hosts/ipnodes exists for backwards + compatibility with previous Solaris releases. The nssitch.conf (4) man page is also updated with a new note about the ipnodes file change to a symlink: *** nss Wed May 3 13:24:11 2006 --- nss.new Wed May 3 13:34:24 2006 *************** *** 672,726 **** --- 672,728 ---- getdefaultproj(3PROJECT), inproj(3PROJECT), setproject(3PROJECT), getauthnam(3SECDB), getexecprof(3SECDB), getprofnam(3SECDB), getuserattr(3SECDB), getusernam(3SECDB), ethers(3SOCKET), getaddrinfo(3SOCKET), getnetbyname(3SOCKET), getprotobyname(3SOCKET), getservbyname(3SOCKET), auth_attr(4), netconfig(4), project(4), resolv.conf(4), user_attr(4), ypfiles(4) NOTES Within each process that uses nsswitch.conf, the entire file is read only once; if the file is later changed, the process will continue using the old configuration. The use of both nis and nisplus as sources for the same database is strongly discouraged since both the name ser- vices are expected to store similar information and the lookups on the database may yield different results depend- ing on which name service is operational at the time of the request. The same applies for using ldap along with nis or nisplus. Misspelled names of sources and databases will be treated as legitimate names of (most likely nonexistent) sources and databases. The following functions do not use the switch: fgetgrent(3C), fgetprojent(3PROJECT), fgetpwent(3C), fgetspent(3C), getpw(3C), putpwent(3C), shadow(4). + The files source to both ipnodes and hosts databases is identical + as /etc/inet/ipnodes is a symbolic link to /etc/inet/hosts. From sacadmin Thu May 11 10:08:27 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4BH8RS9000101 for ; Thu, 11 May 2006 10:08:27 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4BH8RTF009741 for ; Thu, 11 May 2006 10:08:27 -0700 (PDT) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k4BH8QSX006890 for ; Thu, 11 May 2006 11:08:26 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZ4003012611D00@mail-amer.sun.com> (original mail from Rishi.Srivatsavai@Sun.COM) for psarc@sac.sfbay.sun.com; Thu, 11 May 2006 11:08:26 -0600 (MDT) Received: from waltair.East.Sun.COM ([129.148.174.36]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZ4009782A14M40@mail-amer.sun.com>; Thu, 11 May 2006 11:08:26 -0600 (MDT) Date: Thu, 11 May 2006 13:07:24 -0400 From: Rishi.Srivatsavai@Sun.COM Subject: Re: 2006/299 Single hosts File In-reply-to: <44626F4A.7000706@sun.com> Sender: Rishi.Srivatsavai@Sun.COM To: Erik Nordmark Cc: Rishi Srivatsavai , Joseph Kowalski , sommerfeld@Sun.COM, julian.pullen@Sun.COM, Darren.Reed@Sun.COM, Sebastien.Roy@Sun.COM, psarc@sac.sfbay.sun.com, James.D.Carlson@Sun.COM Message-id: <20060511170723.GB14945@waltair> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-Operating-System: Solaris Nevada/5.11 (i86pc) References: <200605051820.k45IKSqS610743@jurassic.eng.sun.com> <446125FF.6060001@sun.com> <1147275698.10125.29.camel@waltair.east.sun.com> <44626F4A.7000706@sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1073 Erik Nordmark (erik.nordmark@sun.com) wrote: > Rishi Srivatsavai wrote: > > >It is not clear that this change as suggested can be done compatibly. > >For eg. what if a new client, expecting everything to be returned > >by a hosts query, queries an old server that only returns IPv4 in > >its hosts replies. The client won't be able to access IPv6 entries > >unless the client detects it is an old server, and automatically > >queries the ipnodes map. > > As I said in the response to Jim, for both files and nis, I suspect we > need to have the client look in both databases to be able to provide > compatibility. > > But if we are going down this path, then I think we should effectively > remove the ipnodes line from nsswitch.conf; the backends for files and > nis can look in both places, but there will be no need to control the > order separately for "ipnodes" and "hosts". Agreed, the switch needs to be updated. We are only fixing one high priority bug with this case. This case does not prevent future work in this area nor making it difficult. Rishi From sacadmin Thu May 11 15:03:45 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4BM3jVm017556 for ; Thu, 11 May 2006 15:03:45 -0700 (PDT) Received: from nwkes-gis-mail-2.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4BM3jTF007225 for ; Thu, 11 May 2006 15:03:45 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwkes-gis-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id k4BM3dgL010059 for ; Thu, 11 May 2006 15:03:39 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZ400001FWG5C00@d1-sfbay-09.sun.com> (original mail from Doug.Leavitt@Sun.COM) for psarc@sac.sfbay.sun.com; Thu, 11 May 2006 15:03:39 -0700 (PDT) Received: from [192.9.61.34] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZ4009MOFY20QD0@d1-sfbay-09.sun.com>; Thu, 11 May 2006 15:03:39 -0700 (PDT) Date: Thu, 11 May 2006 17:03:37 -0500 From: Doug Leavitt Subject: Re: 2006/299 Single hosts File In-reply-to: <20060511170250.GA14945@waltair> Sender: Doug.Leavitt@Sun.COM To: Rishi.Srivatsavai@Sun.COM Cc: Shudong Zhou , allenw@Sun.COM, Sebastien.Roy@Sun.COM, psarc@sac.sfbay.sun.com Message-id: <4463B4B9.5000908@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200605101741.k4AHfEo7104660@billybob.sfbay.sun.com> <20060511170250.GA14945@waltair> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 1599 My apologies for jumping late into this discussion. I have no objections to this fast track. Speaking for the sparks project, I agree with the previous discussion comments that further work in the name service switch including the need to resolve the double database problem in nsswitch.conf, the potential backend inefficiencies and the DB population issues. I feel that these tasks should be addressed by the naming services team in the next phase of the Sparks project/development, and not by this project at this time. I have submitted CR 6424959 Single hosts file exposes redundant nsswitch issues so that the naming team can prioritize and schedule this development. I have referenced CR 6424959 back to CR 6219146 and PSARC/2006/266 so that there is a starting point for that discussion. I agree with this statement: Rishi.Srivatsavai@Sun.COM wrote: > Shudong Zhou (szhou@billybob.sfbay.sun.com) wrote: > NIS ipnodes > =========== > > This case does not propose any changes to nsswitch nor removing the > ipnodes database from the switch file. NIS servers upgrading to a > build containing the above changes will have a merged hosts file. But > the maps for hosts and ipnodes will continue to be distinct as > /var/yp/Makefile filters out all non-IPv4 addresses when creating the > hosts map. The ipnodes map will have both IPv4 and IPv6 addresses. I look forward to submitting a separate PSARC case that addresses these other nsswitch issues, in the future, if that would be acceptable to PSARC, and allow this case, PSARC/2006/299, to move forward. Doug. From sacadmin Thu May 11 18:17:42 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.68.130]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4C1HWKu003080 for ; Thu, 11 May 2006 18:17:42 -0700 (PDT) Received: from [192.168.100.83] (vpn-129-150-21-204.SFBay.Sun.COM [129.150.21.204]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4C1HQ0Y351516; Thu, 11 May 2006 18:17:26 -0700 (PDT) In-Reply-To: <20060511170250.GA14945@waltair> References: <200605101741.k4AHfEo7104660@billybob.sfbay.sun.com> <20060511170250.GA14945@waltair> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <61F1B244-B702-4510-8124-395552E1C0F4@sun.com> Cc: Shudong Zhou , Sebastien.Roy@sun.com, psarc@sac.sfbay.sun.com Content-Transfer-Encoding: 7bit From: Allen Wittenauer Subject: Re: 2006/299 Single hosts File Date: Thu, 11 May 2006 18:18:14 -0700 To: Rishi.Srivatsavai@sun.com X-Mailer: Apple Mail (2.746.2) Status: RO Content-Length: 687 On May 11, 2006, at 10:02 AM, Rishi.Srivatsavai@Sun.COM wrote: > NIS ipnodes > =========== > > This case does not propose any changes to nsswitch nor removing the > ipnodes database from the switch file. NIS servers upgrading to a > build containing the above changes will have a merged hosts file. But > the maps for hosts and ipnodes will continue to be distinct as > /var/yp/Makefile filters out all non-IPv4 addresses when creating the > hosts map. The ipnodes map will have both IPv4 and IPv6 addresses. Does this also mean we're comfortable with stdhosts spitting out a warning message for every IPv6 address it comes across while processing hosts? From sacadmin Thu May 11 18:47:03 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4C1l3cT004112 for ; Thu, 11 May 2006 18:47:03 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4C1l3TF015345 for ; Thu, 11 May 2006 18:47:03 -0700 (PDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k4C1l3xW008046 for ; Thu, 11 May 2006 19:47:03 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZ400601PD4NP00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc@sac.sfbay.sun.com; Thu, 11 May 2006 19:47:03 -0600 (MDT) Received: from strat.East.Sun.COM ([129.148.174.103]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZ40099VQAEAM71@mail-amer.sun.com>; Thu, 11 May 2006 19:47:02 -0600 (MDT) Date: Thu, 11 May 2006 21:47:01 -0400 From: Sebastien Roy Subject: Re: 2006/299 Single hosts File In-reply-to: <61F1B244-B702-4510-8124-395552E1C0F4@sun.com> Sender: Sebastien.Roy@Sun.COM To: Allen Wittenauer Cc: Rishi.Srivatsavai@Sun.COM, Shudong Zhou , psarc@sac.sfbay.sun.com Message-id: <1147398421.14041.91.camel@strat.East.Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.6.1 Content-type: text/plain Content-transfer-encoding: 7BIT References: <200605101741.k4AHfEo7104660@billybob.sfbay.sun.com> <20060511170250.GA14945@waltair> <61F1B244-B702-4510-8124-395552E1C0F4@sun.com> Status: RO Content-Length: 475 On Thu, 2006-05-11 at 18:18 -0700, Allen Wittenauer wrote: > Does this also mean we're comfortable with stdhosts spitting out a > warning message for every IPv6 address it comes across while > processing hosts? I'll wait until Rishi can respond to this before closing this case (the timer expires today), but it doesn't sound like it would be difficult to have stdhosts suppress the warnings when it runs into an IPv6 entry and it's called without the -n flag. -Seb From sacadmin Thu May 11 20:16:26 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4C3GQQI007018 for ; Thu, 11 May 2006 20:16:26 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4C3GQoc019419 for ; Thu, 11 May 2006 20:16:26 -0700 (PDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k4C3GQSX014542 for ; Thu, 11 May 2006 21:16:26 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZ400A01U4XKY00@mail-amer.sun.com> (original mail from Rishi.Srivatsavai@Sun.COM) for psarc@sac.sfbay.sun.com; Thu, 11 May 2006 21:16:26 -0600 (MDT) Received: from waltair.East.Sun.COM ([129.148.174.36]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZ4009ULUFCAN41@mail-amer.sun.com>; Thu, 11 May 2006 21:16:25 -0600 (MDT) Date: Thu, 11 May 2006 23:15:24 -0400 From: Rishi Srivatsavai Subject: Re: 2006/299 Single hosts File In-reply-to: <61F1B244-B702-4510-8124-395552E1C0F4@sun.com> Sender: Rishi.Srivatsavai@Sun.COM To: Allen Wittenauer Cc: Rishi.Srivatsavai@Sun.COM, Shudong Zhou , Sebastien.Roy@Sun.COM, psarc@sac.sfbay.sun.com Message-id: <20060512031524.GA29554@waltair> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-Operating-System: Solaris Nevada/5.11 (i86pc) References: <200605101741.k4AHfEo7104660@billybob.sfbay.sun.com> <20060511170250.GA14945@waltair> <61F1B244-B702-4510-8124-395552E1C0F4@sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 15957 Allen Wittenauer (allenw@sun.com) wrote: > > On May 11, 2006, at 10:02 AM, Rishi.Srivatsavai@Sun.COM wrote: > >NIS ipnodes > >=========== > > > >This case does not propose any changes to nsswitch nor removing the > >ipnodes database from the switch file. NIS servers upgrading to a > >build containing the above changes will have a merged hosts file. But > >the maps for hosts and ipnodes will continue to be distinct as > >/var/yp/Makefile filters out all non-IPv4 addresses when creating the > >hosts map. The ipnodes map will have both IPv4 and IPv6 addresses. > > Does this also mean we're comfortable with stdhosts spitting out a > warning message for every IPv6 address it comes across while > processing hosts? That's true, stdhosts should be updated to run on the merged hosts file. I have updated the spec and included it inline below. Rishi -------------------------- Single hosts file Release binding: minor Problem ============== The /etc/inet/ipnodes database was created to hold both IPv4 and IPv6 host addresses. The ipnodes database is searched first by applications using the getaddrinfo()/getnameinfo() API. The /etc/inet/hosts database was left for legacy applications supporting only IPv4 addresses and calling the gethostby* API. Changes were approved in case PSARC/1998/039 and integrated in Solaris 8. The drawback of the split is IPv4 entries in both databases have to be always in sync. Problems arise in applications when an entry differs in the two databases and host lookup results vary depending on the API used. System administrators must make it a point when changing one file to update the other. The problem is documented in CR 6219146. The opinion for PSARC/1998/039 explains that a database separate from /etc/hosts be used to store both IPv4 and IPv6 addresses (this became /etc/inet/ipnodes), and that /etc/hosts remain for legacy applications and eventually be declared obsolete as IPv6 gains traction and IPv4 is phased out. The opinion also requested a follow-on case be filed to confirm a standard name agreed upon by the IETF for this new combined database. Since then, the rest of the industry has converged on using /etc/hosts as a combined database, not /etc/inet/ipnodes. This case is that follow-on case, confirming that /etc/hosts is the industry standard for storing all IP address mappings. Solution ======== This case proposes to remove the current limitation in maintaining two databases for IP addresses and to avoid the problems posed when entries in the two databases are conflicting. The /etc/inet/hosts database will be the single configuration file that associates host names with their IP addresses, both IPv4 and IPv6 addresses. The /etc/inet/ipnodes file will be left as a symlink to /etc/inet/hosts for backwards compatibility. Adding IPv6 address entries in /etc/inet/hosts does not break host lookups using the gethostby* API. In the gethostby* implementation addresses found in the database not in IPv4 address format are disregarded during the search. Host lookups using the getaddrinfo()/getnameinfo() API will also be unaffected after the ipnodes conversion to a symlink. We chose to leave the /etc/inet/ipnodes as a symlink and not remove the file entirely in keeping with the file's classification as a 'Stable' interface. Removing the file entirely runs the risk of breaking existing applications depending on the file and may cause users to re-create the ipnodes file to satisfy such applications. Keeping the symlink could also cause issues in applications expecting two distinct files holding IPv4 addresses. F.e. an application adding IPv4 addresses previously to two distinct hosts and ipnodes files may now add entries twice in the same hosts file. We feel the advantages of keeping a stable interface by keeping the ipnodes file as a symlink outweigh risks with applications continuing to treat the two files as distinct. Experience from other unix platforms which use a single hosts file suggests that software having problems parsing /etc/inet/hosts file with IPv6 address entries is extremely rare. Even if there are the cost of modifying such software is far less than the incurred cost in maintaining two separate databases. NetBSD based UNIXes and Linux have a single hosts file from the beginning. Bringing Solaris closer to NetBSD and Linux in this regard is also a good thing. Merge Script ============ The task of merging entries from the ipnodes database to the hosts database is performed by a class action script in the SUNWcsr package. The merge script copies over entries from the ipnodes database to the hosts database and in the resulting hosts file removes duplicate entries and coalesces multiple address entries of a hostname. When removing duplicate address lines the hostname entry from ipnodes is preserved over one in hosts database. The reason is nsswitch looks up entries first in ipnodes before hosts and we want to preserve that behavior after the merge. For hostname entry with multiple addresses, all entries are moved to consecutive lines in the resulting hosts file. When a duplicate entry is removed by the merge script any comment lines preceding the entry are also removed. However if the removed entry is the first in the file any preceding comment lines possibly specifying the file header are not removed. Solaris Upgrade =============== Solaris OS upgrade detects any configuration file changes in new package versions and renames the modified files as reference copies prior to the upgrade. The ipnodes file change to a symlink when found in the new package, the existing ipnodes file is renamed before upgrading the system. But this safeguard against losing configuration changes due to upgrade does not permit the class action script to merge ipnodes contents into hosts correctly. An entry therefore will be added in the SUNWcsr pkghistory to ignore the ipnodes file change and not rename the file. NIS ipnodes =========== This case does not propose any changes to nsswitch nor removing the ipnodes database from the switch file. NIS servers upgrading to a build containing the above changes will have a merged hosts file. But the maps for hosts and ipnodes will continue to be distinct as /var/yp/Makefile filters out all non-IPv4 addresses when creating the hosts map. The ipnodes map will have both IPv4 and IPv6 addresses. The stdhosts filter used by /var/yp/Makefile will be updated to support the merged hosts file. Running the filter on the hosts file to convert IPv4 addresses should not generate warnings due to IPv6 address entries. Interface Table =================== The following existing interfaces are affected: /etc/inet/hosts Stable /etc/inet/ipnodes Stable * Please note that PSARC/1998/039 case includes references to /etc/inet/hosts6 file. During review one of the issues raised was on the choice of filename. Though there is no explicit mention of ipnodes being chosen as the new filename the proposed /etc/inet/hosts6 filename was changed to /etc/inet/ipnodes. References ========== 1. PSARC/1998/039 "Naming Services Support of IPv6" 2. CR 6219146 "/etc/inet/hosts and /etc/inet/ipnodes need to be the same file" Manual page changes =================== The new hosts man page is listed below: File Formats hosts(4) NAME hosts - host name database SYNOPSIS /etc/inet/hosts /etc/hosts + /etc/inet/ipnodes + DESCRIPTION The hosts file is a local database that associates the names - of hosts with their Internet Protocol (IP) addresses. The + of hosts with their Internet Protocol (IP) addresses. IP + addresses can be either an IPv4 or an IPv6 address. The hosts file can be used in conjunction with, or instead of, other hosts databases, including the Domain Name System (DNS), the NIS hosts map, the NIS+ hosts table, or informa- tion from an LDAP server. Programs use library interfaces to access information in the hosts file. The hosts file has one entry for each IP address of each host. If a host has more than one IP address, it will have one entry for each, on consecutive lines. The format of each line is: IP-address official-host-name nicknames... Items are separated by any number of SPACE and/or TAB char- acters. The first item on a line is the host's IP address. The second entry is the host's official name. Subsequent entries on the same line are alternative names for the same machine, or "nicknames." Nicknames are optional. For a host with more than one IP address, consecutive entries for these addresses may contain the same or differ- ing nicknames. Different nicknames are useful for assigning distinct names to different addresses. A call to gethostbyname(3NSL) returns a hostent structure - containing the union of all addresses and nicknames from - each line containing a matching official name or nickname. + containing the union of all IPv4 addresses and nicknames + from each line containing a matching official name or + nickname. A call to getipnodebyname(3SOCKET) is similar, + but is capable of returning hostent structures + containing IPv4 and IPv6 addresses. Applications may + also preferably use the address-family independent + getaddrinfo(3SOCKET) API for name to address + lookups. A `#' indicates the beginning of a comment; characters up to the end of the line are not interpreted by routines that search the file. - Network addresses are written in the conventional "decimal - dot" notation and interpreted using the inet_addr routine - from the Internet address manipulation library, - inet(3SOCKET). + Network addresses are written in one of two ways: - This interface supports host names as defined in Internet - RFC 952 which states: + o The conventional "decimal dot" notation and interpreted + using the inet_addr routine from the Internet address + manipulation library, inet(3SOCKET). SunOS 5.10 Last change: 30 Sep 2005 1 File Formats hosts(4) + o The IP Version 6 protocol [IPV6], defined in RFC 1884 + and interpreted using the inet_pton() routine from the + Internet address manipulation library. See + inet(3SOCKET). + These interfaces supports node names as defined in Internet + RFC 952 which states: + A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24 characters drawn from the alphabet (A- Z), digits (0-9), minus sign (-), and period (.). Note that periods are only allowed when they serve to del- imit components of "domain style names". (See RFC 921, "Domain Name System Implementation Schedule," for back- ground). No blank or space characters are permitted as part of a name. No distinction is made between upper- case and lowercase. The first character must be an alpha character [or a digit. (RFC 1123 relaxed RFC 952's limitation of the first character to only alpha characters.)] The last character must not be a minus sign or period. Host names must not consist of numbers only. A host name must contain at least one alphabetical or special character. Although the interface accepts host names longer than 24 characters for the host portion (exclusive of the domain component), choosing names for hosts that adhere to the 24 character restriction will insure maximum interoperability on the Internet. A host which serves as a GATEWAY should have "-GATEWAY" or "-GW" as part of its name. Hosts which do not serve as Internet gateways should not use "-GATEWAY" and "-GW" as part of their names. A host which is a TAC should have "-TAC" as the last part of its host name, if it is a DoD host. Single character names or nicknames are not allowed. EXAMPLES Example 1: Example of a typical line from the hosts file. Here is a typical line from the hosts file: 192.9.1.20 gaia # John Smith + Example 2: Example of an IPv6 address entry. + + 2001:0db8:3c4d:55:a00:20ff:fe8e:f3ad myhost # John Smith + + SEE ALSO gethostbyname(3NSL), inet(3SOCKET), nsswitch.conf(4), resolv.conf(4) + Braden, B., editor, RFC 1123, Requirements for Internet + Hosts - Application and Support, Network Working Group, + October, 1989. + + Harrenstien, K., Stahl, M., and Feinler, E., RFC 952, DOD + INTERNET HOST TABLE SPECIFICATION, Network Working Group, + October 1985. + + Hinden, R., and Deering, S., editors, RFC 1884, IP Version 6 + Addressing Architecture, Network Working Group, December, + 1995. + + Postel, Jon, RFC 921, Domain Name System Implementation + Schedule - Revised, Network Working Group, October 1984. + + NOTES /etc/inet/hosts is the official SVR4 name of the hosts file. The symbolic link /etc/hosts exists for BSD compatibility. + The symbolic link /etc/hosts/ipnodes exists for backwards + compatibility with previous Solaris releases. The nssitch.conf (4) man page is also updated with a new note about the ipnodes file change to a symlink: *** nss Wed May 3 13:24:11 2006 --- nss.new Wed May 3 13:34:24 2006 *************** *** 672,726 **** --- 672,728 ---- getdefaultproj(3PROJECT), inproj(3PROJECT), setproject(3PROJECT), getauthnam(3SECDB), getexecprof(3SECDB), getprofnam(3SECDB), getuserattr(3SECDB), getusernam(3SECDB), ethers(3SOCKET), getaddrinfo(3SOCKET), getnetbyname(3SOCKET), getprotobyname(3SOCKET), getservbyname(3SOCKET), auth_attr(4), netconfig(4), project(4), resolv.conf(4), user_attr(4), ypfiles(4) NOTES Within each process that uses nsswitch.conf, the entire file is read only once; if the file is later changed, the process will continue using the old configuration. The use of both nis and nisplus as sources for the same database is strongly discouraged since both the name ser- vices are expected to store similar information and the lookups on the database may yield different results depend- ing on which name service is operational at the time of the request. The same applies for using ldap along with nis or nisplus. Misspelled names of sources and databases will be treated as legitimate names of (most likely nonexistent) sources and databases. The following functions do not use the switch: fgetgrent(3C), fgetprojent(3PROJECT), fgetpwent(3C), fgetspent(3C), getpw(3C), putpwent(3C), shadow(4). + The files source to both ipnodes and hosts databases is identical + as /etc/inet/ipnodes is a symbolic link to /etc/inet/hosts. From sacadmin Thu May 11 20:34:59 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4C3YxZR007117 for ; Thu, 11 May 2006 20:34:59 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4C3YxTF010369 for ; Thu, 11 May 2006 20:34:59 -0700 (PDT) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k4C3YwKe016026 for ; Thu, 11 May 2006 21:34:58 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZ400G01V5KPT00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc@sac.sfbay.sun.com; Thu, 11 May 2006 21:34:58 -0600 (MDT) Received: from punchin-seb.East.Sun.COM ([129.148.19.4]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZ4009K2VA94MI0@mail-amer.sun.com> for psarc@sac.sfbay.sun.com; Thu, 11 May 2006 21:34:58 -0600 (MDT) Date: Thu, 11 May 2006 23:33:31 -0400 From: Sebastien Roy Subject: Re: 2006/299 Single hosts File In-reply-to: <1146791473.23989.56.camel@strat.East.Sun.COM> Sender: Sebastien.Roy@Sun.COM To: psarc@sac.sfbay.sun.com Cc: Rishi Srivatsavai Message-id: <1147404811.3433.11.camel@localhost> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.6.1 Content-type: text/plain Content-transfer-encoding: 7BIT References: <1146791473.23989.56.camel@strat.East.Sun.COM> Status: RO Content-Length: 698 The timer on this fast-track has expired, and all issues have been resolved in a final spec that was sent by Rishi, and that I've copied into the spec.txt file in the materials directory. I have marked the case "closed approved". Here is a summary of the modifications made to the spec since it was initially submitted: - added a paragraph giving some context related to the 1998/039 opinion. - added a paragraph explaining why external applications parsing /etc/hosts is not expected to be problematic. - clarified that a modification will be made to the stdhosts tool used by /var/yp/Makefile so that it does not utter warnings when pruning IPv6 entries from the hosts file. Thanks, -Seb From sacadmin Fri May 12 13:36:36 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.68.36]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4CKaaHX000389 for ; Fri, 12 May 2006 13:36:36 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with SMTP id k4CKaTFf230501; Fri, 12 May 2006 13:36:35 -0700 (PDT) Message-Id: <200605122036.k4CKaTFf230501@jurassic.eng.sun.com> Date: Fri, 12 May 2006 10:36:27 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: 2006/299 Single hosts File To: allenw@sun.com, Sebastien.Roy@sun.com Cc: Rishi.Srivatsavai@sun.com, szhou@billybob.sfbay.sun.com, psarc@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ocsijhGQ33oSjKEw4pQQvw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 543 > From: Sebastien Roy ... > I'll wait until Rishi can respond to this before closing this case (the > timer expires today), but it doesn't sound like it would be difficult to > have stdhosts suppress the warnings when it runs into an IPv6 entry and > it's called without the -n flag. I don't think the discussion has terminated. Therefore, I'll officially ask for more time. Let's start with COB 5/15. Personally, I'm not real comfortable about the nsswitch deferal. This project doesn't smell complete. - jek3 From sacadmin Fri May 12 16:13:57 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4CNDu3e006306 for ; Fri, 12 May 2006 16:13:57 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4CNDuTF027204 for ; Fri, 12 May 2006 16:13:56 -0700 (PDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k4CNDuKe024392 for ; Fri, 12 May 2006 17:13:56 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZ600701DLTKR00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc@sac.sfbay.sun.com; Fri, 12 May 2006 17:13:56 -0600 (MDT) Received: from punchin-seb.East.Sun.COM ([129.148.19.4]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZ600DVXDV7E0B1@mail-amer.sun.com>; Fri, 12 May 2006 17:13:56 -0600 (MDT) Date: Fri, 12 May 2006 19:12:26 -0400 From: Sebastien Roy Subject: Re: 2006/299 Single hosts File In-reply-to: <200605122036.k4CKaTFf230501@jurassic.eng.sun.com> Sender: Sebastien.Roy@Sun.COM To: Joseph Kowalski Cc: allenw@Sun.COM, Rishi.Srivatsavai@Sun.COM, szhou@billybob.sfbay.sun.com, psarc@sac.sfbay.sun.com Message-id: <1147475546.3726.20.camel@localhost> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.6.1 Content-type: text/plain Content-transfer-encoding: 7BIT References: <200605122036.k4CKaTFf230501@jurassic.eng.sun.com> Status: RO Content-Length: 230 On Fri, 2006-05-12 at 10:36 -1000, Joseph Kowalski wrote: > I don't think the discussion has terminated. Therefore, I'll officially > ask for more time. Let's start with COB 5/15. Okay, I've extended the timer to 5/15. -Seb From sacadmin Fri May 12 16:15:17 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.56.36]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4CNFHN8006365 for ; Fri, 12 May 2006 16:15:17 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with SMTP id k4CNFCv0361931; Fri, 12 May 2006 16:15:16 -0700 (PDT) Message-Id: <200605122315.k4CNFCv0361931@jurassic.eng.sun.com> Date: Fri, 12 May 2006 13:15:09 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: 2006/299 Single hosts File To: psarc@sac.sfbay.sun.com, Sebastien.Roy@sun.com Cc: Rishi.Srivatsavai@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 6EE2aKD1aJ0+GeOYBnss0Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1267 > From: Sebastien Roy ... > The timer on this fast-track has expired, and all issues have been > resolved in a final spec that was sent by Rishi, and that I've copied > into the spec.txt file in the materials directory. I have marked the > case "closed approved". > > Here is a summary of the modifications made to the spec since it was > initially submitted: > > - added a paragraph giving some context related to the 1998/039 opinion. > > - added a paragraph explaining why external applications > parsing /etc/hosts is not expected to be problematic. > > - clarified that a modification will be made to the stdhosts tool used > by /var/yp/Makefile so that it does not utter warnings when pruning IPv6 > entries from the hosts file. > > Thanks, > -Seb Sebastien has agreed to keep this case open until COB Monday at my request. It wasn't clear to me that the nsswitch issue had closed. I know I saw a response ("yea, we are working on it"), but I'm not completely comfortable that the changes proposed in this case constitutes a complete and coherent change to the system without nsswitch being updated. I must admit, its not an obvious call - rather on the edge. I wonder if this is just me or if others feel this way. - jek3 From sacadmin Mon May 15 19:11:00 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.68.130]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4G2B0PJ005301 for ; Mon, 15 May 2006 19:11:00 -0700 (PDT) Received: from lowpost (lowpost.SFBay.Sun.COM [129.146.226.81]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with SMTP id k4G2AxnT385209; Mon, 15 May 2006 19:10:59 -0700 (PDT) Message-Id: <200605160210.k4G2AxnT385209@jurassic.eng.sun.com> Date: Mon, 15 May 2006 19:10:44 -0700 (PDT) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: 2006/299 Single hosts File To: psarc@sac.sfbay.sun.com, Sebastien.Roy@sun.com, Joseph.Kowalski@eng.sun.com Cc: Rishi.Srivatsavai@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: od360ZNBuCAVRC23SC/4tA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc Status: RO Content-Length: 312 Since nobody said "I'm concerned too" in response to nsswitch not being updated as part of this project, I'm inclined to let this be Closed Approved. Since my request was until COB today, in a sense this has already happened. Thanks to Sebastien for putting up with this last minute delay. - cheers, - jek3 From sacadmin Mon May 15 21:05:04 2006 Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk.SFBay.Sun.COM [129.146.11.21]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4G45446007222 for ; Mon, 15 May 2006 21:05:04 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4G451jH024181; Mon, 15 May 2006 21:05:01 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id k4G446K2016859; Mon, 15 May 2006 21:04:06 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id k4G446IA016858; Mon, 15 May 2006 21:04:06 -0700 (PDT) Date: Mon, 15 May 2006 21:04:06 -0700 (PDT) From: Gary Winiger Message-Id: <200605160404.k4G446IA016858@marduk.eng.sun.com> To: psarc@sac.sfbay.sun.com, Sebastien.Roy@sun.com, Joseph.Kowalski@eng.sun.com Subject: Re: 2006/299 Single hosts File Cc: Rishi.Srivatsavai@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 411 > Since nobody said "I'm concerned too" in response to nsswitch not being > updated as part of this project, I'm inclined to let this be Closed Approved. > Since my request was until COB today, in a sense this has already happened. > > Thanks to Sebastien for putting up with this last minute delay. Hummm, I thought I read that nsswitch was going to eliminate the redundant entry. Is that not so? Gary.. From sacadmin Tue May 16 08:15:51 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4GFFpeR025918 for ; Tue, 16 May 2006 08:15:51 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4GFFooc024332 for ; Tue, 16 May 2006 08:15:51 -0700 (PDT) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k4GFFnxW021571 for ; Tue, 16 May 2006 09:15:50 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZD00C0164OQQ00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc@sac.sfbay.sun.com; Tue, 16 May 2006 09:15:49 -0600 (MDT) Received: from punchin-seb.East.Sun.COM ([129.148.19.4]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZD009VS6EC4MC2@mail-amer.sun.com>; Tue, 16 May 2006 09:15:49 -0600 (MDT) Date: Tue, 16 May 2006 11:15:40 -0400 From: Sebastien Roy Subject: Re: 2006/299 Single hosts File In-reply-to: <200605160404.k4G446IA016858@marduk.eng.sun.com> Sender: Sebastien.Roy@Sun.COM To: Gary Winiger Cc: psarc@sac.sfbay.sun.com, Joseph.Kowalski@eng.sun.com, Rishi.Srivatsavai@Sun.COM Message-id: <1147792540.1661.118.camel@localhost> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.6.1 Content-type: text/plain Content-transfer-encoding: 7BIT References: <200605160404.k4G446IA016858@marduk.eng.sun.com> Status: RO Content-Length: 1133 Gary, On Mon, 2006-05-15 at 21:04 -0700, Gary Winiger wrote: > > Hummm, I thought I read that nsswitch was going to eliminate the > redundant entry. Is that not so? This case does not propose any changes to the name service switch. It is doing away with the /etc/inet/ipnodes file and replacing it with a symbolic link to /etc/inet/hosts for compatibility so that customers aren't faced with forgetting to update two files when changing their IP address or hostname. This case is addressing this P2 bug, on which are now 11 service request records followed by a angry mob in the interest list: 6219146 /etc/inet/hosts and /etc/inet/ipnodes need to be the same file Customers are already required to keep identical data in these two files. This case is easing their pain by making these two files the same. Future work, as Doug Leavitt from the Sparks team has agreed to take on in the context of the next phase of the Sparks project, involves reworking the switch as a whole to address (among other things) the nsswitch issues that Erik Nordmark pointed out up earlier last week. Does that answer your question? -Seb From sacadmin Tue May 16 08:41:02 2006 Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk.SFBay.Sun.COM [129.146.11.21]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4GFf2cS027414 for ; Tue, 16 May 2006 08:41:02 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4GFf1jH001249; Tue, 16 May 2006 08:41:01 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id k4GFe63B017361; Tue, 16 May 2006 08:40:06 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id k4GFe6LQ017360; Tue, 16 May 2006 08:40:06 -0700 (PDT) Date: Tue, 16 May 2006 08:40:06 -0700 (PDT) From: Gary Winiger Message-Id: <200605161540.k4GFe6LQ017360@marduk.eng.sun.com> To: gww@eng.sun.com, Sebastien.Roy@sun.com Subject: Re: 2006/299 Single hosts File Cc: psarc@sac.sfbay.sun.com, Joseph.Kowalski@eng.sun.com, Rishi.Srivatsavai@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 57 > Does that answer your question? Yes, thanks. Gary.. From sacadmin Tue May 16 09:44:15 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4GGiF0X001588 for ; Tue, 16 May 2006 09:44:15 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4GGiEoc006851 for ; Tue, 16 May 2006 09:44:14 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k4GGiEKe009232 for ; Tue, 16 May 2006 10:44:14 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZD00F01A3RL600@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc@sac.sfbay.sun.com; Tue, 16 May 2006 10:44:14 -0600 (MDT) Received: from punchin-seb.East.Sun.COM ([129.148.19.4]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZD00K6NAHPTLU0@mail-amer.sun.com> for psarc@sac.sfbay.sun.com; Tue, 16 May 2006 10:44:14 -0600 (MDT) Date: Tue, 16 May 2006 12:44:04 -0400 From: Sebastien Roy Subject: Re: 2006/299 Single hosts File In-reply-to: <1146791473.23989.56.camel@strat.East.Sun.COM> Sender: Sebastien.Roy@Sun.COM To: psarc@sac.sfbay.sun.com Cc: Rishi Srivatsavai Message-id: <1147797844.1661.129.camel@localhost> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.6.1 Content-type: text/plain Content-transfer-encoding: 7BIT References: <1146791473.23989.56.camel@strat.East.Sun.COM> Status: RO Content-Length: 41 This case is now closed approved. -Seb From sacadmin Tue May 30 14:02:31 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.68.130]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4UL2VGw006298 for ; Tue, 30 May 2006 14:02:31 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4UL2PYO295098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 30 May 2006 14:02:27 -0700 (PDT) Message-ID: <447CABBB.9040903@sun.com> Date: Tue, 30 May 2006 13:31:55 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Doug Leavitt CC: Rishi.Srivatsavai@sun.com, Shudong Zhou , allenw@sun.com, Sebastien.Roy@sun.com, psarc@sac.sfbay.sun.com Subject: Re: 2006/299 Single hosts File References: <200605101741.k4AHfEo7104660@billybob.sfbay.sun.com> <20060511170250.GA14945@waltair> <4463B4B9.5000908@sun.com> In-Reply-To: <4463B4B9.5000908@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1244 Doug Leavitt wrote: > My apologies for jumping late into this discussion. I have no objections > to this fast track. Speaking for the sparks project, I agree with > the previous discussion comments that further work in the name service > switch including the need to resolve the double database problem in > nsswitch.conf, the potential backend inefficiencies and the DB population > issues. > > I feel that these tasks should be addressed by the naming services team > in the next phase of the Sparks project/development, and not by this > project at this time. > > I have submitted > CR 6424959 Single hosts file exposes redundant nsswitch issues > > so that the naming team can prioritize and schedule this development. I > have referenced CR 6424959 back to CR 6219146 and PSARC/2006/266 so that > there is a starting point for that discussion. Sounds good. One thing I'd like to suggest for 2006/299 is to make it clear in the documentation that even though /etc/inet/ipnodes "disappears" (becomes a symlink) that the customer must still maintain the ipnodes: line in nsswitch.conf. Otherwise somebody could easily infer from the ipnodes() man page change that there is no more ipnodes: needed in nsswitch.conf. Erik From sacadmin Mon Oct 9 15:11:58 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99MBwAD006668 for ; Mon, 9 Oct 2006 15:11:58 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k99MBwqb020506 for ; Mon, 9 Oct 2006 15:11:58 -0700 (PDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k99MBwYi014203 for ; Mon, 9 Oct 2006 16:11:58 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6W00K012J4QK00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc@sac.sfbay.sun.com; Mon, 09 Oct 2006 16:11:58 -0600 (MDT) Received: from strat ([129.148.174.103]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6W000CK2ZX8Y33@mail-amer.sun.com> for psarc@sac.sfbay.sun.com; Mon, 09 Oct 2006 16:11:58 -0600 (MDT) Date: Mon, 09 Oct 2006 18:11:57 -0400 From: Sebastien Roy Subject: 2006/299 Single hosts File - updated spec Sender: Sebastien.Roy@Sun.COM To: psarc Message-id: <1160431917.22514.48.camel@strat> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.6.2 Content-type: text/plain Content-transfer-encoding: 7BIT Status: RO Content-Length: 1559 One of the results of the discussion surrounding 2006/530 was a clarification of the hosts and ipnodes merge script's behavior. Rishi has provided an updated spec for this case in which the paragraph entitled "Merge Script" was updated as follows: Merge Script ============ The task of merging entries from the ipnodes database to the hosts database is performed by a class action script in the SUNWcsr package. The merge script creates copies of the existing hosts and ipnodes config files before making any changes. The merge script also adds a comment in the resulting hosts file about the occurrence of a merge. The merge script copies over entries from the ipnodes database to the hosts database and in the resulting hosts file removes duplicate entries and coalesces multiple address entries of a hostname. Entries that exist with both IP address and host name aliases identical (often when the same entry is added in both hosts and ipnodes) are considered duplicates and only one such entry is kept. For hostname entry with multiple addresses, all entries are moved to consecutive lines in the resulting hosts file. When a duplicate entry is removed by the merge script any comment lines preceding the entry are also removed. However if the removed entry is the first in the file any preceding comment lines possibly specifying the file header are not removed. This change has been made to the spec in the materials directory. -Seb