Rebuild Kerberos Database 3

[sendhilk]

When i am rebuilding my Kerberos database do i have to do a nodecond and reboot the nodes or is it possible for me to built the database otherwise.These are production nodes and i can't afford to have them down even for a minute.cud anyone please send me the procedure on how to build the kerberos database.
Also when i am trying to open an s1term for any of my nodes it gives me the login prompt and when i type the user id root it hangs there. thats the reason why i want to rebuild the database

Thanks,
Sendhilk

 

[call]

How to Rebuild the Kerberos Database



About this document
The following procedure outlines how to destroy the Kerberos database on the IBM RS/6000 Scalable POWERparallel System and then rebuild it.
This procedure applies to:
· Parallel System Support Programs Version 2.1 or later
· AIX Version 4.1.3 and later

About this procedure
Following is a list of possible reasons for rebuilding the Kerberos database:
· if the database becomes corrupted
· if problems occur when configuring the database with /usr/lpp/ssp/bin/setup_authent
· when changing the host names of any of the nodes or the control workstation
· when switching name resolution from DNS to /etc/hosts or vice versa

Procedure
At the control workstation (CW), log in as root and execute the following commands:
/usr/lpp/ssp/kerberos/bin/kdestroy
The kdestroy command destroys the user's authentication tickets, which are located in /tmp/tkt<uid>.
/usr/lpp/ssp/kerberos/etc/kdb_destroy
The kdb_destroy command destroys the kerberos authentication database, which is located in /var/kerberos/*.
rm /etc/krb*
This removes the following files:
· krb-srvtab: contains the keys for services on the nodes
· krb.conf: contains the SP authentication configuration
· krb.realms: specifies the translations from host names to authentication realms
rm /.klogin
This removes the .klogin file which contains a list of principals that are authorized to invoke processes as the root user with the SP-authenticated remote commands [rsh,rcp].
rm /.k
This removes the Kerberos Master key cache file.
rm /var/kerberos/database/*
This command insures that the authentication database files are completely removed.
/usr/lpp/ssp/bin/setup_authent
This command configures SP authentication services. Executing this command invokes an interactive dialog in which various utility programs are invoked to accomplish this configuration. (Refer to Chapter 1, the &quot;Understanding RS/6000 SP Installation&quot; section of the IBM RISC System/6000 Scalable POWERparallel Systems Installation Guide.)
NOTE: In PSSP 2.3 and later this step will also perform the actions listed in steps 9 and 10.
/usr/lpp/ssp/install/bin/hmreinit
This command will recycle the hardmon daemon and let it get a new hardmon ticket so it can monitor the hardware properly.
NOTE: if you are running PSSP 2.3 or later you may skip to step 11 after completing step 8.
/usr/lpp/ssp/bin/setup_server
This command will add the necessary remote command (RCMD) principals for the nodes to the Kerberos database based on what is defined in the SDR for those nodes.
Set the nodes to customize to create the new srvtab files.
Execute the command smitty node_data.
Select BOOT/INSTALL/USR SERVER INFORMATION.
Enter START FRAME, START SLOT and NODE COUNT or NODE LIST.
Set RESPONSE FROM SERVER TO BOOTP REQUEST to customize.
Verify that RUN SETUP SERVER ON THE CW is set to yes.
Press Enter to execute setup_server.
The final step involves propagating the /etc/krb-srvtab files onto the nodes. This can be done automatically or manually as described below.
AUTOMATICALLY (requires a reboot of the nodes):
Shut down and reboot the nodes (do not use netboot).
MANUALLY (reboot of the nodes is not required):
On the CW, cd into the /tftpboot directory and verify that there is a <node_name>-new-srvtab file for each node.
ftp each node's respective /tftpboot/<node-name>-new-srvtab file from the CW to the node and rename the file to /etc/krb-srvtab.
Compare the following files located on the control workstation to those located on the nodes:
· /etc/krb.realms (may be zero length, but must exist)
· /etc/krb.conf
· /.klogin (must be in $HOME for every Kerberos user)
If they differ, ftp the files from the control workstation out to the nodes.
Set the nodes back to disk via smit node_data on the control workstation.
Once the nodes are customized with the new /etc/krb-srvtab, you can test the functionality of Kerberos by obtaining a ticket (kinit root.admin) and executing the /usr/lpp/ssp/rcmd/bin/rsh <any_node> date command.

 

[sendhilk]

Hi call,
when i am running setup_authent it asks for principal name and instance , any idea what this have to be???

thanks for the document on how to build the database

sendhilk

 

[sendhilk]

i have a problem with the installation. After i rebuild the database and try to start a s1term i get the error
s1term : 0026-607 configuration information cannot be obtained from the SDR.
i guess the problems is because of the host file entries in the control workstation and the nodes. i have multiple NICs in my system.
I have a doubt here,
does the hostname of the system be the same as the entry against the private ethernet ip in the hostfile.please help.

thanks,
sendhil

 

[call]

Principal name should be....root
Instance should be....admin

Try checking the SDR
Run SDR_test see what comes back
Also Cat /etc/SDR_dest_info
see if there is any info in it.

Also check to see if the sdrd is running command lssrc -g sdr

The destination is either the host name or TCP/IP address of the target system partition. This IP address is associated with the HOSTNAME network interface on the control workstation via use of the ifconfig alias command.
I hope this helps
If not maybe aixqueen can help.

 

[sendhilk]

call,

I am able to run rsh commands after i built my database and am able to run perspectives too, but when i am trying to open an s1term i get the same error that i mentioned before ( config info cannot be obtained from SDR ).
please help me if ya know more on this or maybe i shud wait for queen to solve this puzzle !!!!

thanks for all the help call

sendhil

 

[aixqueen]

#> echo $SP_NAME and see what returns... same as host? is your system
partitioned?

I believe that more happened to your system than we know...maybe
someone played with IP or info in the SDR or something.. or somehow the SDR
(system data repository)got corrupted?..the s1term -w 1 1
is a simple tty hardware via the serial link to get to the node... You do not
know if there is an SDR_Archive somewhere..? or what happened originally
that corrupted kerberos? Or what other symptoms started happening
that you needed to rebuild kerberos?

Since your system is an active one that cannot afford
to be down, perhaps you would be well advised to call IBM software support
and get more detailed help...so they can walk you through everything
that could be wrong...so we don't miss something else that changed.... or cause
you other problems that cannot be fixed without a restore.....
Good Luck....


================
Did you Try checking the SDR?
Run SDR_test see what comes back
Also Cat /etc/SDR_dest_info
see if there is any info it?

======================
Here is what the error means...

0026-607
Configuration information cannot be obtained from the SDR.


Explanation: The named command either cannot establish a session with the System
Data Repository or the SDR does not contain the required Hardware Monitor
configuration information.

User Response: Verify that the SDR has been properly configured and that the
Hardware Monitor configuration information is present in the SDR. Refer to the man
page for the hardmon command for a description of this configuration information.

If this command has been executed on a workstation other than the control workstation, or your system is partitioned....
verify that the SP_NAME environment variable is defined to the host name of the
control workstation prior to running this command.
=============================

 

[sendhilk]

Thanks queen,

echo $SP_NAME doest return anything , it just gives blank line, probably the variable is not set atall in the first place. when i am trying to run SDR_test it says SDR_Test: verification succeeded. All this problem started when i started changing some entries in the host file of the nodes,( not the IP's) the hostname of the nodes.

maybe i will call up IBM and take their help.

Thanks for all your help.

 

[aixqueen]

Sendhilk:
I still think it is a good idea to call IBM...but here is the site
for changing the node names ....as you can see it is very task oriented...
not as easy as one would think...even just for a hostname of a node change...

perhaps just a step was missed...and it will be a quick call to IBM....
to fix...........Good luck.....

http://www.rs6000.ibm.com/doc_link/en_US/a_doc_lib/sp32/ssp/admin/spa3mst238.html

 

[aixqueen]

One last thing I forgot to mention

The reason we asked about SP_NAME

The SP_NAME environment variable identifies the system partition to subsystems. (If this environment variable is
not set, the system partition is defined by
the primary: stanza in the /etc/SDR_dest_info file.)
Most tasks performed on the control workstation that get
information from the SDR will get the information for that
particular system partition. So if it was partitioned, and
you did not have the variable set, it would give you errors.
If there never was a SP_NAME set it is not important.

I don't know, perhaps you could put the names back the way they were and just alias the new names? Well I am sure IBM
will be able to assist..

 

[call]

Yes good luck on calling IBM like aixqueen said you might have a bigger problem
Also when you get it to work please post what ibm had you do just incase this happen again to someone else.

Good luck.

 

[sendhilk]

It was indeed a quick call to IBM. Everything looked prefect expect that i was asked to run

/usr/lpp/ssp/install/hmreinit

this restarts the hardmon.. in this process i was told if fetches a new ticked. Now i am able to open an s1term too

everything looks fine now.

Thanks call and queen for all your help

sendhil

 

[call]

Glad to here everything is ok now. Thanks for letting us know what you did to fix it.