sd commands (except swlist) failing on permissions

[Don Ferderber]

Hi All ! ...

Having trouble executing SD commands on one of my HP-UX systems running HP-UX 11.11. Getting the following error (using swverify in this example):

# /usr/sbin/swverify PHSS_34428

======= 07/31/09 13:32:42 EDT BEGIN swverify SESSION
(non-interactive) (jobid=zrtph0v0-3219)

* Session started for user "root@zrtph0v0".

* Beginning Selection
ERROR: "zrtph0v0:/": You do not have the required permissions to
select this target. Check permissions using the "swacl"
command or see your system administrator for assistance. Or,
to manage applications designed and packaged for nonprivileged
mode, see the "run_as_superuser" option in the "sd" man page.
* Target connection failed for "zrtph0v0:/".
ERROR: More information may be found in the daemon logfile on this
target (default location is
zrtph0v0:/var/adm/sw/swagentd.log).
* Selection had errors.



======= 07/31/09 13:32:42 EDT END swverify SESSION (non-interactive)
(jobid=zrtph0v0-3219)

I do know, from looking through log files, that at one point during an install something went wrong. From that point on, SD commands (other than swlist) seem to fail. Is there a lock file or something that is preventing me from executing SD commands ?

Any help would be greatly appreciated.

[SoorajCleris]

Hi,
Did you try to restard swagent?

you may try

/usr/sbin/swagentd -r

Regards,
Sooraj U

[Don Ferderber]

Yes ...

Swagentd has been restarted multiple times.

[Dennis Handly]

>swagentd has been restarted multiple times.

Have you checked networking? Some other threads:
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1343044
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1336598
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1140576
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1071134
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=251328
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1343466

[Don Ferderber]

Hi Again ...

Thanks for your replies. I went through all of the links you supplied and none of them apply. I need to repeat that I am unable to execute ANY SD commands except swlist. Even something like swverify to verify the installation of a patch fails with the previously mentioned message. I cannot execute swinstall, swacl, swverify, swcopy, etc.

This restricts my ability to install patches, or anything else for that matter. I am fairly well versed in SD commands, but am pulling my hair out on this one. Is it possible that there is a lock file, or that an INDEX file is corrupt ?

(Thanks and) Regards,
Don

[Mel Burslan]

Since you have said you are well versed in SD family of commands, I am sure you have already removed /var/adm/sw/products/swlock file before restarting swagentd. Sometimes it causes nasties but lately, I did nothave to do it for quite a while. So, you might try if you have not already.

[Dennis Handly]

>I am unable to execute ANY SD commands except swlist.

If it's not swagentd or networking and swlist works, can you provide this output:
swacl -l root

Are all of the sw* executables hardlinks to the same file?
ll -i /usr/sbin/sw*

[Don Ferderber]

Hi Everyone ...

I appreciate the interest in this one ... it still has me perplexed. Thank you for the suggestion of swlock, but that file does not exist. As for the output from swacl, unfortunately it reacts the same way as the other sd commands. I have included the output:

# cd /var/adm/sw/products
# ls sw*
sw* not found


# swacl -l root
#
# swacl Installed Software Access Control List
#
# For host: zrtph0v0:/
#
# Date: Sat Aug 1 00:55:51 2009
#

ERROR: You are not authorized to perform the requested operation on
the "root" ACL at "zrtph0v0:/". Depending on whether you are
attempting to list or modify the ACL, you do not have the
required "test" or "control" permission, respectively. (Use
the "id" command to find out the identity information used by
SD to determine your access permissions.)
#


As I mentioned earlier, this all seems to have stemmed from an install that went bad. I believe the system "may" have unexpectedly rebooted during an install (I cannot be sure) and this has corrupted something.

This is where my knowledge of how sd works is limited. Something is now preventing the commands to recognize that they are being executed as root.

[Don Ferderber]

As for the sd commands being link to the same executable, it looks like they are (bummer! ... thought we may have been onto something!) ... here is the output:

# ll -i /usr/sbin/sw*
78033 -r-sr-xr-x 11 root bin 2478080 Feb 16 2007 /usr/sbin/swacl
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
78033 -r-sr-xr-x 11 root bin 2478080 Feb 16 2007 /usr/sbin/swask
78033 -r-sr-xr-x 11 root bin 2478080 Feb 16 2007 /usr/sbin/swconfig
78033 -r-sr-xr-x 11 root bin 2478080 Feb 16 2007 /usr/sbin/swcopy
78033 -r-sr-xr-x 11 root bin 2478080 Feb 16 2007 /usr/sbin/swinstall
78033 -r-sr-xr-x 11 root bin 2478080 Feb 16 2007 /usr/sbin/swjob
78033 -r-sr-xr-x 11 root bin 2478080 Feb 16 2007 /usr/sbin/swlist
78034 -r-sr-xr-x 2 root bin 1462272 Feb 16 2007 /usr/sbin/swmodify
78034 -r-sr-xr-x 2 root bin 1462272 Feb 16 2007 /usr/sbin/swpackage
78033 -r-sr-xr-x 11 root bin 2478080 Feb 16 2007 /usr/sbin/swreg
78033 -r-sr-xr-x 11 root bin 2478080 Feb 16 2007 /usr/sbin/swremove
78033 -r-sr-xr-x 11 root bin 2478080 Feb 16 2007 /usr/sbin/swverify

[R.K. #]

Hi Don,

How about checking file:
/var/adm/sw/security/secrets

[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

[Don Ferderber]

I think I may be the first to be taking a crack at it, so hopefully nothing else has been destroyed. And as for IUX and DRD, I agree ... must educate the masses (heh heh).

[mvpel]

How odd, I've got exactly the same problem here, and have gone through essentially the same troubleshooting steps without much luck. I'm going to go back and double-check a few things, but I'll be interested to hear what you find.

[Tingli]

How about /var/adm/sw, is it empty?

[mvpel]

I found it - turned out to be a case of too much, or not enough, coffee.

The nsswitch.conf was changed to check files first instead of dns since for whatever reason "loopback" is not in DNS, and there was a subtle typo in the line for the host's own name in /etc/hosts.

Thus the lan0 IP address didn't match the /etc/hosts IP address, and the change to nsswitch.conf uncovered this issue.

Once the IP in /etc/hosts for the host's own name was fixed, swinstall started working along with the DTlogin screen.

[Don Ferderber]

No such luck on my end ...

This is still an outstanding issue here ... nsswitch.conf is cool ... /etc/hosts is cool as well ... argh !