From: LOEWENTHAL Simon (sloewenthal@gemini.edu)
Date: Fri Mar 26 2004 - 16:49:43 EST
Dear all,
I have been trying to solve my NIS+ issues over the last couple of days with
the advise from people from this list.
I have a single root domain called cl.gemini.edu. There are two replicas
and one root master.
It seems that there is a credential issue and that one nis+ replica thinks
that it is in charge.
I create credentials for a new user called bpeters@.cl.gemini.edu. the
credentials are created on the root master correctly.
niscat cred.org_dir|grep bpeters will show the credentials. If I niscat
again I see no credentials. If I niscat again I might see some credentials,
or I might not.
It seems that the nis master is 'sometimes' handing off the query to a
replica, but the replica isn't synchronised with the root master, because I
think that it thinks that it is a root master. I reason this because I
snoop|grep NIS to see where the commands went when I ran niscat commands.
I am seeing queries for gemini.edu. edu.cl.egemini.edu.
ctx_dir.cl.gemini.edu. domains but this has never existed, which is very
strange. This could be a red herring.
Other oddities is that some clients cannot authenticate to a NIS+ server.
Restarting RPC solves this problem until is breaks again (/etc/init.d/rpc
stop|start).
Some messages from the root master console:
aguila console login: nis_cache_bind_replica_2(org_dir.gemini.edu.)
nis_cache_bind_replica_2(hosts.org_dir.gemini.edu.)
Mar 26 15:06:47 aguila login: ROOT LOGIN /dev/pts/6 FROM 172.16.12.69
Mar 26 15:09:58 aguila ip: ip_option_process: bad opt 0x5
Mar 26 15:09:58 aguila last message repeated 1 time
Messages seen in snoop|NIS:
cpocsw -> aguila RPCBIND C GETADDR prog=100300 (NIS+) vers=3
cpocsw -> aguila NIS+ C CheckpointTime "cl.gemini.edu."
cpocsw -> aguila NIS+ C CheckpointTime "cl.gemini.edu."
cpocsw -> aguila NIS+ C CheckpointTime "cl.gemini.edu."
cpocsw -> aguila NIS+ C Null
aguila -> cpocsw NIS+ R Null
cpocsw -> aguila RPCBIND C GETADDR prog=100300 (NIS+) vers=3
cpocsw -> aguila RPCBIND C GETADDR prog=100300 (NIS+) vers=3
cpocsw -> aguila NIS+ C Lookup "cl.gemini.edu."
cpocsw -> aguila NIS+ C Lookup "cl.gemini.edu."
testrecs -> aguila NIS+ C IBlist "hosts.org_dir.cl.gemini.edu."
[name
= "polaris"]
--> Checkpoints are taking place between both replicas and the root master.
Is this the bad one:
aguila -> cpocsw RPC R (#1006) XID=1081014549 Can't authenticate
(bogus credentials (seal broken))
Key to above messages:
aguila = root master.
cpocsw, cposbf = root replicas.
all other machines = NIS+ clients.
Other common message clients get are: Unable to Authenticate NIS+ server
I have considered removing the badly behaving replica by using:
On root master:
nisrmdir -f -s sbfcsw.cl.gemini.edu. org_dir.cl.gemini.edu.
nisrmdir -f -s sbfcsw.cl.gemini.edu. group_dir.cl.gemini.edu.
nisrmdir -f -s sbfcsw.cl.gemini.edu. cl.gemini.edu.
On replica:
cp /etc/nsswitch.files /etc/nsswitch.conf
/etc/init.d/rpc stop
rm -f /etc/.rootkey
rm -rf /var/nis/*
/etc/init.d/rpc
I hope that this reduces the complexity of the nis domain.
The Unable to Authenticate NIS+ server message leads me to believe that
root's credentials are messed up, which might account for the bizarre
behaviour I've been seeing. With this in mind is it wise to do this to
recreate the credentials and how long downtime could it need:
---------------------------------------------------------------------
Kill and restart rpc.nisd at security level 0:
ps -ef | grep rpc.nisd
kill <pid>
/usr/sbin/rpc.nisd -r -S 0
Use keylogout to remove roots key:
keylogout -f
Add root's key and push it into the directories:
nisaddcred des
ps -ef | grep keyserv
kill <pid>
nisupdkeys `nisdefaults -d`
nisupdkeys org_dir.`nisdefaults -d`
nisupdkeys groups_dir.`nisdefaults -d`
/usr/sbin/keyserv
Make sure the changes have been propagate:
/usr/lib/nis/nisping `nisdefaults -d`
/usr/lib/nis/nisping org_dir.`nisdefaults -d`
/usr/lib/nis/nisping groups_dir.`nisdefaults -d`
Apply /usr/lib/nis/nisping to any other directories that you may have
created.
Kill & restart NIS at security level 2:
ps -ef | grep rpc.nisd
kill <pid>
/usr/sbin/rpc.nisd -S 2
---------------------------------------------------------------------
But, I don't what effect this could have on the current nis services,
because their might be a good reason clients are preferring to use the
replicas instead of the root master.
I'm sorry that this email isn't very clear, but there is a lot of
information that I am trying to get my head around.
Many thanks in advance for any information and many thanks to those who
replied with help the first time round at the start of this week.
Regards,
Simon.
--- Simon Loewenthal Information Systems Group Gemini Observatory +56 51 205610 ORIGINAL POSTING: -----Original Message----- Sent: Monday, March 22, 2004 11:49 AM Subject: NIS+ password changing Hi everyone, I try and change a user's NIS+ passwd whilst logged on as root on the NIS+ Master. There are 3 replicas in the this domain. There is only one domain. I use the command passwd and get these results: [root@nismaster]/root$ passwd GuestE Enter login(NIS+) password: Why am I asked for the user's password? Especially as no one knows the password because the user has forgotten it. Is it possible that root's credentials are incorrect? This is possible as someone changed the root password recently, but they are unsure exactly the process they used to change the password. i.e passwd; chkey -p. Is there anyway to tell if root's credentials are correct and is there a sure way of correctly them if they are wrong? --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.634 / Virus Database: 406 - Release Date: 18/03/2004 _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagers
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:28:22 EDT