stuck in a loop with a few swverify errors

[dave.s]

Currently when I change a date stamp, ownership or permissions on a few select files & directories swverify reports that it should be something else. Then when I change it to that something else it tells me that it should be what it was previously set to.

Files & directories in question

ERROR: File "/usr/newconfig/etc/passwd" should have owner,uid "root,0" but the actual owner,uid is "other,100".

WARNING: Directory "/var/opt/OV" should have mode "555" but the actual mode is "2555".
WARNING: Directory "/var/opt/OV/tmp" should have mode "777" but the actual mode is "2775".
ERROR: File "/opt/VRTSob/lib/vxicudt20b.dat" should have owner,uid root,0" but the actual owner,uid is "other,100".
ERROR: File "/opt/perf/bin/perfalarm" should have group,gid "bin,2" but the actual group,gid is "sys,3".
ERROR: File "/opt/perf/bin/perfalarm" should have mtime "1145784626" but the actual mtime is "1170107386".
ERROR: File "/var/opt/OV/share/help/C/pv/OVW/Dialogs/pvconfig.dbx"
should have group,gid "bin,2" but the actual group,gid is "root,0".
ERROR: File "/var/opt/OV/share/help/C/pv/OVW/Functions/ackalarm.fun"
should have group,gid "bin,2" but the actual group,gid is "root,0".
ERROR: File "/var/opt/OV/share/help/C/pv/OVW/Functions/startpv.fun"
should have owner,uid "root,0" but the actual owner,uid is "bin,2".
ERROR: File "/var/opt/OV/share/help/C/pv/OVW/Tasks/ackalarm" should have owner,uid "root,0" but the actual owner,uid is "bin,2".
ERROR: File "/var/opt/OV/share/help/C/pv/OVW/Tasks/startpv" should have owner,uid "root,0" but the actual owner,uid is "bin,2".
ERROR: File "/usr/local/info/dir" should have mtime "1151585094" but the actual mtime is "1131374561".
ERROR: File "/usr/local/lib/charset.alias" should have mtime "1131627262" but the actual mtime is "1151585098".
ERROR: File "/usr/local/info/dir" should have mode "644" but the actual mode is "600".

Also is there anyway to fix the size difference swverify reports? I have noticed 2 or 3 files that report errors when it isnt the size it thinks it should be.

Thanks

[James R. Ferguson]

Hi Dave:

'swverify' is doing what it has been told to do. That is, when run, 'swverify' uses the 'INDEX' files in the '/var/adm/sw/products' directories to compare the expected timestamp, permission and checksum values with their actual values.

Rembember that the 'var/adm/sw' directory is used by the SD tools and is your Installed Product Database (IPD). You do *not* want to diddle with its contents or risk corrupting it any any way. To do so, will mean that your server can no longer be patched or patched properly.

You need to be sure, if you change the attributes of a file that you understand the consequences.

As for the file sizes, 'cksum' returns both the checksum value and the octet size. Both of these values are assessed for "truth".

Regards!

...JRF...

[dave.s]

Thanks for the timely reply James. As with most things I was assigned this task after the fact. Someone conveniently removed /var/adm/sw/save and has left the system in a state of confusion. I have never tinkered around with putting a corrupt system like this back together because save has always been there until cleanup came along. I will take a look at the INDEX file you mention to see if there is anything can do.

[Bob E Campbell · Accepted solution]

My guess is that you have more than one object that own the file and do not agree as to the proper values. This could cause you to toggle between an Openview product error and an Openview patch error if the patch has scripts that do not manage the IPD correctly. Use "swlist -l file | grep filename" to spot this type of problem and use swmodify to get the offending filesets in sync.

It could also be that after you fix the ownership and permissions you introduced an mtime failure in their place. Use touch to help here.

In general, never edit the files under newconfig! To do so could block the system from updating "uncustomized" files in the future.

[Bob E Campbell]

One more comment, before using swmodify(1M) to reset the IPD you should try to understand the cause of the error. A seemingly silly error could be a sign of a real problem.

[dave.s]

Thanks Bob, thats what I was looking for. The files in question are referenced several times. I will look into all of them but this solution did work for the first one I tried.

[dave.s]

I agree with both of your concerns. This is a test server so while I am concerned, I have a lot of room to try things. Worst case I will re-image the server.

[James R. Ferguson]

Hi (again) Dave:

You could use :

# swverify -F

...to correct the permissions, ownership, etc. according to the INDEX files.

If only '/var/adm/sw/save' has been emptied (perhaps by 'cleanup') then you have only lost the ability to roll-back patches. The IPD should otherwise be intact.

Regards!

...JRF...

[dave.s]

Thats awesome James, did not know that. I have 0 experience when it comes to cleaning up correct patches so I would like to thank both of you for your help!

Swverify -F < > was able to fix things on its own. Ruling out any questions on what to set things to.

-David

[dave.s]

Thats awesome James, did not know that. I have 0 experience when it comes to cleaning up corrupt patches so I would like to thank both of you for your help!

Swverify -F < > was able to fix things on its own. Ruling out any questions on what to set things to.

-David