+++ This bug was initially created as a clone of Bug #484079 +++

Escalated to Bugzilla from IssueTracker

--- Additional comment from tao on 2009-02-04 12:13:44 EDT ---

Description of problem:
regardless of using ldap or nis as the backend, running "getent networks" shows network map entries with the "aliases" list separated by commas, which doesn't appear to make sense.

Solaris doesn't do this and the format of the /etc/networks file (as defined in oses that have a manpage for it) doesn't contain commas, so... why?

How reproducible: always

Steps to Reproduce:

Actual results:
network_name network_number alias1, alias2, alias3,...

Expected results:
network_name network_number alias1 alias2 alias3...

Additional info:
this is observed on RHEL3, 4 and 5
This event sent from IssueTracker by jbastian  [Support Engineering Group]
 issue 137523

--- Additional comment from tao on 2009-02-04 12:13:45 EDT ---

I don't see a current man page on the system for this, but find an
archived one which meshes with the understanding here:

<snip>
NETWORKS(5)               Linux System Administration             
NETWORKS(5)

NAME
       networks - network name information

DESCRIPTION
       The file /etc/networks is a plain ASCII file that describes known
DARPA
       networks and symbolic names for these networks.  Each line
represents a
       network and has the following structure:

              name number aliases ...

       where  the  fields  are  delimited  by spaces or tabs.  Empty lines
are
       ignored.  If a line contains a hash mark (#), the  hash  mark  and 
the
       remaining part of the line are ignored.

       The field descriptions are:

       name   The symbolic name for the network.

       number The official number for this network in dotted-decimal
notation.
              The trailing ".0" may be omitted.

       aliases
              Optional aliases for the network.

       This file is read by route or netstat utilities.  Only Class A, B
or  C
       networks  are  supported, partitioned networks (i.e. network/26 or
net-
       work/28) are not supported by this facility.

FILES
       /etc/networks
              The networks definition file.

SEE ALSO
       getnetbyaddr(3), getnetbyname(3), getnetent(3), route(8),
netstat(8)

GNU/Linux                         2001-12-22                      
NETWORKS(5)
</snip>

In simple testing, this turns up:

[root@dl585 RPMS]# grep networks /etc/nsswitch.conf 
#networks:  ldap [NOTFOUND=return] files
networks:   files
[root@dl585 RPMS]# cat /etc/networks
loopback     127.0.0.0 foo bar baz fooble
[root@dl585 RPMS]# getent networks
loopback              127.0.0.0 foo, bar, baz, fooble
[root@dl585 RPMS]# rpm -q glibc
glibc-2.3.4-2.36
glibc-2.3.4-2.36



This event sent from IssueTracker by jbastian  [Support Engineering Group]
 issue 137523

--- Additional comment from tao on 2009-02-04 12:13:46 EDT ---

The fix for this is obviously fairly straightforward:

[snip]

--- /tmp/redhat/BUILD/glibc-2.5-20061008T1257/nss/getent.c      2006-01-02
00:45:56.000000000 +0530
+++ /tmp/redhat/BUILD/glibc-2.5-20061008T1257/nss/getent-mkpai.c       
2009-01-27 23:12:18.000000000 +0530
@@ -433,7 +433,7 @@
       fputs_unlocked (net->n_aliases[i], stdout);
       ++i;
       if (net->n_aliases[i] != NULL)
-       putchar_unlocked (',');
+       putchar_unlocked (' ');
     }
   putchar_unlocked ('\n');
 }

[/snip]

The 2 concerns are:

1) What else will break if we "correct" this behavior?
2) What was the rationale (if any) for doing it this way?


This event sent from IssueTracker by jbastian  [Support Engineering Group]
 issue 137523

--- Additional comment from tao on 2009-02-04 12:13:48 EDT ---


Hello Frank,

The comma has been removed upstream.

Please see my tech-list query and Ulrich's response
http://post-office.corp.redhat.com/archives/tech-list/2009-January/msg00581.html
http://post-office.corp.redhat.com/archives/tech-list/2009-January/msg00595.html

Does this call for 3 separate BZs ?

-- Pai


This event sent from IssueTracker by jbastian  [Support Engineering Group]
 issue 137523