Dear All,
Thanks to all those experts who responded and all
those whose email is still in the internet somewhere.
The problem was:
----- Begin Included Message -----
I think I may have found a problem with nisplus
(...I wonder if they all understand my ironical
sense of humour...)
Sorry Sun :-) - I have looked through all my patches
and all my manuals and all my previous sunmanagers
summaries and I do not think I have spotted this
- though I could be wrong as that is a large lot
of stuff. Maybe there is still a setup problem though
and I wonder if the great minds out there have any
inkling of what is right/wrong here.
System is solaris 2.3 with
the recommended patches:
101317-09 SunOS 5.3: lp jumbo patch
101318-54 SunOS 5.3: Jumbo patch for kernel (includes libc, lockd)
101327-06 SunOS 5.3: security and miscellaneous tar fixes
101331-03 SunOS 5.3: fixes for package utilities
101344-08 SunOS 5.3: Jumbo NFS patch
101347-01 SunOS 5.3: system hangs due to mblk memory leak
101615-02 SunOS 5.3: miscellaneous utmp fixes
101739-02 SunOS 5.3: sendmail jumbo patch - security
and with some more offered by Sun added later eg:
101318-54 SunOS 5.3: Jumbo patch for kernel
When a groupname is in the nisplus group.org_dir table it
does not get updated correctly by admintool or found
correctly by the routines that interrogate when using
commands like ls -l etc etc unless there is an entry
(with no members list) in /etc/group file of the host
in use also! If either there is no line of the form (say):
groupa::40:
in the file, then the nisplus table does not seem visible to any
commands that use it. ie an ls -l simply gives the group id and
no name. When the line is present, the corresponding entry in
the table and its list of group members works ok.
The permissions on the group.org_dir table seem fine.
My nsswitch.conf has
group: files nisplus
as you might expect on all machines.
The problem means
that whenever a new group is added, it must be added to the
/etc/group file on all machines as well as the root server's
database which is not the way it is meant to work at all.
Does anyone out there (responses from Sun are encouraged if
you have any - I haven't phoned the hotline here yet as
I have a work around and not many hosts) know what this
is and if there is a patch or have I found something new?
----- End Included Message -----
The responses broadly said that admintool was the cause
of the problem as early unpatched versions did not put
the * required by nisplus into the group password field
or that one should maintain the a group file anyway
on the server and always use nistbladm to create the table
from that file (with -f option). My solution will be
to (a) put * in the password fields of all group entries
and remove the /etc/group entries and to get the most
up to date admintool patch 101384-07 (I had actually
previously used -01 which was not adequate.
Thanks again.
Here are the repsonses:
----- Begin Included Message -----
>From casper@fwi.uva.nl Wed Jan 11 11:48 GMT 1995
X-Organisation: Faculty of Mathematics & Computer Science
University of Amsterdam
Kruislaan 403
NL-1098 SJ Amsterdam
The Netherlands
X-Phone: +31 20 525 7463
X-Telex: 10262 hef nl
X-Fax: +31 20 525 7490
To: trevor@if.ssci.liv.ac.uk (Trevor Morrison)
X-Orig-Cc: sun-managers@nsfnet-relay.ac.uk
Subject: Re: NEW nisplus group.org_dir table problem/bug?
Date: Wed, 11 Jan 1995 12:44:47 +0100
From: Casper Dik <casper@fwi.uva.nl>
>I think I may have found a problem with nisplus
>
>(...I wonder if they all understand my ironical
>sense of humour...)
>
>Sorry Sun :-) - I have looked through all my patches
>and all my manuals and all my previous sunmanagers
>summaries and I do not think I have spotted this
>- though I could be wrong as that is a large lot
>of stuff. Maybe there is still a setup problem though
>and I wonder if the great minds out there have any
>inkling of what is right/wrong here.
Have you installed patch
101384-07 SunOS 5.3: Admintool Jumbo patch
Casper
----- End Included Message -----
----- Begin Included Message -----
>From rohank@ochampus.mil Wed Jan 11 13:47 GMT 1995
From: J Kevin Rohan <rohank@ochampus.mil>
Date: Wed, 11 Jan 1995 06:43:22 -0700
To: trevor@if.ssci.liv.ac.uk
Subject: Re: NEW nisplus group.org_dir table problem/bug?
The problem is that a * is not in the passwd location. We wrote a script
that inserts a * in each group. You need to run this script every time
you change info in the group file.
----------------------------------------------------------------------
#!/bin/ksh
Domain=`nisdefaults -p`
Groups=`niscat group | nawk -F : '{print $1}'`
print -n "Editing group: "
for Group in `print $Groups`
do
nistbladm -m passwd=* [name=$Group],group.org_dir.$Domain
print -n "$Group.."
done
print
------------------------------------------------------------------------
----- End Included Message -----
----- Begin Included Message -----
>From clwillia@twcable.com Wed Jan 11 14:08 GMT 1995
Date: Wed, 11 Jan 1995 07:03:33 -0700
To: trevor@if.ssci.liv.ac.uk
Subject: Re: NEW nisplus group.org_dir table problem/bug?
From: Cheryl.Williams@twcable.com
Try patch 101384 (don't know what revision level is current, but I think this
may have been fixed in -02). The bug id is 1151837--something about an invalid
password field in the group entry.
----- End Included Message -----
----- Begin Included Message -----
>From root Wed Jan 11 14:50 GMT 1995
Date: Wed, 11 Jan 1995 09:43:05 +0500
From: jwc@icf.hrb.com
Subject: Re: NEW nisplus group.org_dir table problem/bug?
To: trevor@if.ssci.liv.ac.uk
Content-Transfer-Encoding: 7BIT
> The problem means
> that whenever a new group is added, it must be added to the
> /etc/group file on all machines as well as the root server's
> database which is not the way it is meant to work at all.
> Does anyone out there (responses from Sun are encouraged if
> you have any - I haven't phoned the hotline here yet as
> I have a work around and not many hosts) know what this
> is and if there is a patch or have I found something new?
>
I had the same problem. I execute the following script whenever
I add to the group file using admintool. I think there is a problem
with admintool, (one of many problems)
#!/bin/sh
/usr/bin/rm /tmp/group_list
/usr/lib/nis/nisaddent -d group >/tmp/group_list
/usr/lib/nis/nisaddent -m -f /tmp/group_list group
/usr/bin/rm /tmp/group_list
----- End Included Message -----
----- Begin Included Message -----
>From rickert@cs.niu.edu Wed Jan 11 17:26 GMT 1995
Date: Wed, 11 Jan 1995 11:23:01 -0600
From: Neil Rickert <rickert@cs.niu.edu>
To: trevor@if.ssci.liv.ac.uk
Subject: Re: NEW nisplus group.org_dir table problem/bug?
In info.sun-managers you write:
>When a groupname is in the nisplus group.org_dir table it
>does not get updated correctly by admintool or found
>correctly by the routines that interrogate when using
>commands like ls -l etc etc unless there is an entry
>(with no members list) in /etc/group file of the host
>in use also! If either there is no line of the form (say):
>groupa::40:
I found that the NIS+ table needs to be of the form:
groupa:*:40:
I'm not sure if this is your problem. But some software cannot
tolerate a null in the group password field.
----- End Included Message -----
----- Begin Included Message -----
>From kremvax.demos.su!lab.ipmce.su!zaitcev@moscvax.demos.su Wed Jan 11 18:58 GMT 1995
Date: Wed, 11 Jan 1995 21:38:57 +0300
From: zaitcev@lab.ipmce.su (Pete A. Zaitcev)
To: trevor@if.ssci.liv.ac.uk (Trevor Morrison)
Subject: Re: NEW nisplus group.org_dir table problem/bug?
In article <9501101352.AA04623@faraday.ssci.liv.ac.uk>, you write:
>I think I may have found a problem with nisplus
>
>(...I wonder if they all understand my ironical
>sense of humour...)
No problem, we understand. Once I fight with NIS+ in the heart of Asia,
in Tashkent. Unforgivable entertinment.
>When a groupname is in the nisplus group.org_dir table it
>does not get updated correctly by admintool or found
>correctly by the routines that interrogate when using
>commands like ls -l etc etc unless there is an entry
>(with no members list) in /etc/group file of the host
>in use also! If either there is no line of the form (say):
>
>groupa::40:
Your admintool should make a line with locked password:
groupa:*:40:
(I know that this line does not exist actialy, this is output from niscat).
Worse, I found no way to do this from the serial console. You must to
remove the entry with "nistbladm -r ...". Than create it _with admintool_.
Good luck,
Pete
----- End Included Message -----
----- Begin Included Message -----
>From Anthony.Worrall@reading.ac.uk Thu Jan 12 10:07 GMT 1995
Date: Thu, 12 Jan 1995 10:03:49 +0000
From: Anthony.Worrall@reading.ac.uk (Anthony Worrall)
To: trevor@if.ssci.liv.ac.uk
Subject: Re: NEW nisplus group.org_dir table problem/bug?
The admintool causes the problem. The workaround is the have a
group file on your master server. Edit this file insted of using
the admin tool and then update nis plus with the command
/usr/lib/nis/nisaddent -m -f /etc/nis/group -t group.org_dir group
(/etc/nis/group is the ascii file of groups).
We also use this to maintain extra nis tables for the automounter eg.
/usr/lib/nis/nisaddent -m -f /etc/nis/auto_opt -t auto_opt.org_dir key-value
----- End Included Message -----
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:14 CDT