sd commands (except swlist) failing on permissions

[Robert-Jan Goossens]

166592 -r-xr-xr-x 1 bin bin 798720 Jun 2 2008 /usr/sbin/swagentd
78183 -r-xr-xr-x 1 bin bin 20480 Sep 7 2004 /usr/sbin/swapinfo
78025 -r-xr-xr-x 1 bin bin 28672 May 13 2004 /usr/sbin/swapon

# chown root:bin /usr/sbin/swagentd
# chown root:bin /usr/sbin/swapinfo
# chown root:bin /usr/sbin/swapon

# /usr/sbin/swagentd -k
# ps -ef | grep swagentd
kill the process if it is still running
# /usr/sbin/swagentd -s

# /usr/sbin/swverify PHSS_34428

Regards,
Robert-Jan

[Matti_Kurkela]

Your symptoms match exactly the situation of swagentd having an incorrect idea of the local hostname and/or IP address(es).

I've seen this caused by:

- errors in /etc/hosts file (not having a line with current IP address and hostname in both short and fully-qualified forms in there, or having the "localhost" line corrupted)

- incomplete information in DNS: both forward and reverse DNS records for this host must be present and agree with each other (although this may cause this particular problem only only if the system is configured to try DNS before /etc/hosts)

- not restarting swagentd after changing the server's IP address without rebooting (or restarting swagentd, but forgetting to update /etc/hosts _before_ it)

- changing the hostname using the "hostname" command, but not updating /etc/hosts to match

When the machine is booting, swagentd is started before the network interfaces are activated, so it cannot look up things from DNS at that time. This is one of the reasons you *must* have a line in /etc/hosts that matches the current hostname.

MK

[Dennis Handly]

>MK: Your symptoms match exactly the situation of swagentd having an incorrect idea of the local hostname and/or IP address(es).

Hmm, I thought that was in one of the links I listed.

[Don Ferderber]

Hi All ...

Thanks for all of your suggestions. BUT ...

Here is what I have found:

# ll /var/adm/sw/security/secrets
-r--r--r-- 1 bin bin 15 Jun 9 2003 /var/adm/sw/security/secrets
# cat /var/adm/sw/security/secrets
default -sdu-

Also tried changing the ownerships of files as mentioned and restarting swagentd ... same result.

/etc/hosts file is fine. DNS lookups are clean. hostname/IP address on this system has been the same for a while.

Hmmm ...

Regards,
Don

[Subhajit Khanbarman]

I am aware of this issue and this occurs due to swagentd having an incorrect idea of the local hostname and/or IP address.

I fully agree with Matti's solution.

In addition, please Check the DNS entry. Check the nsswitch.conf and the resolv.conf files.

Start by trying to reset the swagentd

# swagentd -r

[Bob E Campbell]

Hi Don! Been a long time since Philadelphia!

The one thing that I did not see on Matti's list was if hostname and uname return different values. And yes, if one of them is fully DNS-qualified they don't match.

[Don Ferderber]

Hi All...

Bob: checked out the uname and hostname values and they match. And.. yes it has been a long time since Philadelphia's HP World! We will have to catch up.

nsswitch.conf and resolv.conf are OK ...

I have a feeling that this has something to do with the server having been in the process of applying patches (a while back) and the system was rebooted midstream without completing the patching process. I was engaged to find out why the automated patching process has not worked for a while. I discovered that all SD commands (except swlist) are failing on the above mentioned permission issue.

Is something corrupted that can hopefully be undone ? Is it an INDEX file ? Is it a hidden lock file ?

Any further suggestions would be greatly welcomed.

Regards (and thanks),
Don

[Bob E Campbell]

Do you see anything in syslog or /var/adm/sw/swagentd.log?

[Bob E Campbell]

And while I am still curious what is going on I must say that if we fix *this* problem the only way to confirm that all aspects of that aborted install are repaired is a fresh install. If someone without your skills tried to fix it before you, multiply that opinion by 10.

As a part of that effort you could also show them how to use IUX or DRD for recovery.

[Don Ferderber]

Nothing in syslog...

Everytime I execute sd commands, swagentd.log produces lines like:

ERROR: Cannot authenticate local principal "root".
ERROR: Access denied to start verify agent on /. No user
authenticated. 08/05/09 12:42:50 EDT

or

ERROR: Cannot authenticate local principal "root".
ERROR: Access denied to list socs on host. No user authenticated.
08/05/09 10:23:56 EDT