dupatch problems.

[Robert Walker_8]

Hi,

Sometime ago I installed openssl and looks like I didnt install it correctly - resulting in the openssl installing itself in /usr/ssl.

Along the way dupatch now thinks this is correct and wont allow me to install one of HP's csp's - in particular the later ones with openssl and bind.

It now reports:

- Tru64_UNIX_V5.1B:
Patch 26114.00

and can not be replaced by this patch.

./usr/ssl/include/openssl/x509_vfy.h:
is installed by:


- Tru64_UNIX_V5.1B:
Patch 26114.00

and can not be replaced by this patch.

./usr/ssl/include/openssl/x509v3.h:
is installed by:


- Tru64_UNIX_V5.1B:
Patch 25114.00

and can not be replaced by this patch.

I have tried baselining the server after removing /usr/ssl and with it - without success. I originally deleted /usr/ssl to get this error:

./usr/ssl/include/openssl/x509v3.h:
does not exist on your system,
however, it is in the inventory of installed subsets.

./usr/ssl/lib/libcrypto.a:
does not exist on your system,
however, it is in the inventory of installed subsets.

./usr/ssl/lib/libssl.a:
does not exist on your system,
however, it is in the inventory of installed subsets.

How does one fix up this problem - either way dupatch wont go forward - is there a tool to rebuild the dupatch database from scratch or to override this problem (as in rpm --force !).

I have even deleted the previous PK - PK6 - which it let me do, but reapplying still complains about /usr/ssl either being there when it is or not when its not!

Robert.

[Vladimir Fabecic]

Hello
How did you install openssl? Using setld?
Notice that setld uses /usr/.smdb./ directory for information about installed software.
There is no --force option.
Brute force removal of a subset installed can be done by deleting the OSFSUBSET001.lk and OSFSUBSET001.sts of the named OSFSUBSET001 in /usr/.smdb./ . Without these files setld will think OSFSUBSET001 is not installed.
However, I would do backup of your system before that action.

Also read man pages of fverify.

[Vladimir Fabecic]

Just one thing to add:
DO NOT use "setld -d" or the brute force method for things installed by "dupatch".

[Ann Majeske]

This is a known problem with the Openssl/Bind ERP that you're trying to install. The problem happens if you upgrade from PK4 or PK5 to PK6 and then try to install the ERP. It doesn't happen if you install PK6 directly on the OS and then try to install the ERP. HP is working on fixing this problem with the ERP.

A couple things you could try if you don't want to wait for the fixed ERP (note I have not tried these to see if they work): 1) try using the dupatch option "5 Patch Baseline Analysis/Adjustment" to tell dupatch to ignore the problems and install the patch anyway; 2) delete PK6, PK5, and PK4, then reinstall PK6 and try installing the ERP again.

Ann

[Ann Majeske]

I just want to clarify something I said. Normally using the "Patch Baseline/Adjustment" option of dupatch is NOT recommended when trying to install official patches. Normally if an official patch refuses to install because of conflicting patches you should resolve the conflicting patches instead of trying to force the patch install. In this specific case, for some reason the ERP has an incorrect list of patches that it can install over and the reports of conflicting patches are incorrect, so I think it would be OK to force the install.

Ann

[Robert Walker_8]

Hi,

Just to clarify. The openssl I installed was from openssl.org (no setld etc) - the one provided by HP is fairly slow to get updates and there is an interest to keep the systems secure.

OpenSSL from openssl.org is just a configure make open source install. It was done prior to putting PK6 on. In upgrades we move our SSH components out of the way to allow HP upgrades to work correctly.

The only problem this time was that not specifying the correct configure options in the build resulted in OpenSSL placing its install into /usr rather than /usr/local

Now the new openssl/bind patch has a fit either way (if /usr/ssl is there or not).

Thanks Ann, will try deleting PK6 and others - although dont see them in the dupatch delete option but give that ago.

Will get back to you soon.

Robert.

[Robert Walker_8]

Gday again,

Had some mixed success - on another test system while using the workaround (delete all Patch Kits and then reapply PK6)

When dupatch deleting the last known PK - PK4

1) T64V51BB25AS0004-20040616 and all CSPs dependent upon it

I get the following error:

*** The Patch Kit will delete 64 patches ***
-------------------------------------------------------------------------

- Tru64_UNIX_V5.1B / Filesystem Patches:
Patch 25002.00 - SP04 OSFADVFS540 (SSRT2275)

can not be deleted unless the following patches are also selected or
deleted first:

- - Required -:
New Hardware Base System Support V7.0

-------------------------------------------------------------------------
-------------------------------------------------------------------------

- Tru64_UNIX_V5.1B / Filesystem Patches:
Patch 25003.00 - SP04 OSFADVFSBIN540

can not be deleted unless the following patches are also selected or
deleted first:

- - Required -:
New Hardware Base System Support V7.0

-------------------------------------------------------------------------
-------------------------------------------------------------------------

- Tru64_UNIX_V5.1B / Kernel Patches:
Patch 25009.00 - SP04 OSFBASE540 (SSRT3631 SSRT3469 SSRT2439 ...)

can not be deleted unless the following patches are also selected or
deleted first:

- - Required -:
New Hardware Base System Support V7.0


And so on and so on for 16 patches which after that says it cannot continue to delete PK4 - I dont see any other patches to delete and thus cannot do anything about NHD7.

Any ideas?

Robert.

[Robert Walker_8]

Hi

Ended up logging a call with HP as removing old Patch Kits did work until one which had NHD7 on - game over - cant delete NHD7 to then get rid of PK1 (or whatever!).

They came back and said yes this is a common problem and have released a pre-release patch kit (believed to be going GA very soon - after someone proof reads the release notes or whatever).

Anyway if its not out soon and you have the same problems log a call - you probably will go through the merry go round of doing a sys_check etc.

Robert.