topic Re: Upgrading hardware in Operating System - HP-UX

Upgrading hardware

Seth Clarke — Wed, 22 Feb 2006 11:56:22 GMT

I'm in the process of replacing a RP7400 with a RP7420

The OS is 11.11 and I started with the install: My goal now is to copy everything I need onto the 7420, do a vgexport and vgimport for the SAN disk, change the IP and test.

Although it has SAN disk, there's still applications that are in the /opt filesystem. So I decided to copy that over and test them. What else should I be checking?

I made sure that I copied the /etc/rc.config.d/ and the /sbin/init.d/ files but do I need to copy the /sbin/rc*.d/* Startup and Kill files or will those links get created when the system reads the /etc/rc.confid.d/ files at boot time?

Re: Upgrading hardware

Senthil Kumar .A_1 — Wed, 22 Feb 2006 12:04:14 GMT

Hi Clarke,

If I understand right, what you are doing is a manual copy of applications. But, in HPUX a repository called IPD is maintained (like registry in windows) for all the software installed, which can be manupulated only by SW commands (SD-UX).

The IPD keeps track of the patches to be istalled/its rollback and software upgrades etc,etc...

If I were you, I would install the apps required using swinstall, and use the app data files, which are usually ideally left out of Install directories (opt).

I reckon there are very few apps in HPUX that does not require swinstall.

Regards,
Senthil

Re: Upgrading hardware

Seth Clarke — Wed, 22 Feb 2006 12:16:33 GMT

The software that is being copied is non-hp osftware, for example COBOL, which doesn't show up on the original 7400

swlist -l product | grep -i cobol
...

So I have to copy the /opt/cobol directory and also the startup scripts the processes that run at boot

Re: Upgrading hardware

A. Clay Stephenson — Wed, 22 Feb 2006 12:17:09 GMT

By bypassing the normal swinstall process, you are destroying the software database in /var/adm/sw. You will wind up with a system that is essentially unpatchable. The better answer is to use swlist on your old box to list all the installed software and patches and then follow that list to swinstall the applications and patches on the new box. Any other approach is going to lead to chaos.

This is really a job for Ignite. It does make possible cloning systems and keeping the installed software database sane but you can also do it with a cold install and carefully matching the installed software on the old box with the new via swlist/swinstall.

Re: Upgrading hardware

A. Clay Stephenson — Wed, 22 Feb 2006 12:22:12 GMT

The COBOL that I have installed (although it's been about 4 years since I've done it; did I mention that I hate COBOL?) was installed and patched via swinstall. It's possible that your COBOL was copied from a still earlier box or that your COBOL version does not use swinstall. In any event, you can copy /opt/cobol but understand that it now can't be patched using HP swxxx tools.

Re: Upgrading hardware

Senthil Kumar .A_1 — Wed, 22 Feb 2006 12:29:23 GMT

Hi Seth,

I agree to a point that "COBOL" is a non-hp software. There are many non-hp softwares that get still installed using swinstall. ex: sudo

What u could do is double confirm from the old box,

swlist | grep -i cobol

If the output was nil, you may consider that it wasn't installed using swinstall.

In that case, you could copy the cobol app from opt directory and files in init.d and rc.config.d .

you may even want to copy the rc*.d files pertaining to only that app, because it will not be created automatically.

I would suggest you to anyway ask your predecessor, who installed cobol in the first machine, so that you could repeat the same process now on the new machine, instead of raw copy. because, do so manually, could leave certain directories and files of the app uncopied causing minor issue's in future.

The raw copy can be simply termed as trial and error method to perfection.

regards,
Senthil

Re: Upgrading hardware

Seth Clarke — Wed, 22 Feb 2006 12:32:37 GMT

the original 7400 has Cobol that was installed by running a binary file - but I do recall that many configuration file changes were made after the install on files that resided in many subdirectories in Cobol, that's why I'm doing a straigt copy.

About the /sbin/rc*.d/ Startup and Kill links, will they need to be created? or how does the system know what levels to kill or start them?

Re: Upgrading hardware

Senthil Kumar .A_1 — Wed, 22 Feb 2006 12:45:39 GMT

Hi Seth,

Basically these links in the directory rc*.d would be created for you by swinstall, beacause they are also included in them when the product is bundled.

Since you are going to copy app manually, you need to specifically create those links in the new box if a app has one. By the way i'm not too sure, cobol has any daemons to be started at system start up. pardon me I havent worked on cobol.

If i were to have my S* file in rc3.d directory, my init program when it does run level start up it starts , when the system is been pushed into run level 2, similarly a K* script in one level below, in this case rc1.d, the app is kill when a transition is made from runlevel run level 1 to 2.

By the way , sorry, its not copy, its "create". you don't require to copy the link, Just create a link in the rc*.d directory were appropiate for the new machine. u need to do it manually, it would not be done automatically, as ur query suggested.

Regards,
Senthil

Re: Upgrading hardware

Senthil Kumar .A_1 — Wed, 22 Feb 2006 12:46:54 GMT

sorry in my previous example it is rc2.d and not rc3.d

;)
Senthil

Re: Upgrading hardware

Senthil Kumar .A_1 — Wed, 22 Feb 2006 12:49:57 GMT

again , in my previous example its "run level 2 to 1" and not "run level 1 to 2"..

extremely sorry .. i did not go through the info before submission, I will be careful the next time..

:(

Senthil

Re: Upgrading hardware

Seth Clarke — Wed, 22 Feb 2006 12:58:32 GMT

Ok, I'll create the links and test. Hopefully I'm not forgetting anything but similar to cobol there are a few more apps that run at system time that are not installed by swinstall

Some may have been compiled with the configure, make and make install. Those are being copied over as well, I'm just hoping the since the architecture is the same, that it will work