HP SMH RPM's Hardcoded GID and prefix

[asv]

When attempting to install the rpm hpsmh-2.1.7-168.linux.i386.rpm, it fails because it is trying to hardcode hpsmh group to GID 79, which is already taken by another application in NIS.

strace -f -o smh2.txt rpm -i hpsmh-2.1.7-168.linux.i386.rpm

10749 execve("/usr/sbin/groupadd", ["/usr/sbin/groupadd", "-g", "79", "hpsmh"],

Is there anyway to get the rpm to bind to another gid? Why is this hardcoded in the RPM in the first place?

The second part of this question deals with install prefix. Is there anyway to modify where this rpm installs so I can avoid any files being installed to /usr/local/?

/usr/local/hp/hpSMHSetup.pl
/usr/local/hp/hpbacl.sh
/usr/local/hp/hpfdtn.sh
/usr/local/hp/hpwebsetup
/usr/local/hp/namazu-2.0.16.tar.gz
/usr/local/hp/shmchk

Thanks in advance

[Rich Purvis · Accepted solution]

It's a long story and if it is possible to move the other app's GID off of 79, then it would be the easiest thing you can do for right now.

If not, then when the Linux PSP version 7.80 comes out there should be a quick manual way to change the GID it uses.

What you will need to do is place a file called "/usr/local/hp/ugover.cnf" with USERNUM=N line (like USERNUM=1024) prior to installing the RPM. Then it will use that number and not 79.

The unfortunate part is that it requires you to place yet another file in the directory structure you do not want to use. And I know of no way to change the directory structure from /usr/local.

That functionality has been in SMH for quite sometime. However, for reasons I cannot explain, the HPASM code would go out and delete the user and recreate it back at 79. That has been (or should have been) changed for Linux PSP 7.80 (which is not available yet, so no guarantees) so that is why it should start working with that PSP.

Some time after the 7.80 PSP there should be a version of Linunx SMH that does not require the ugover.cnf file but automatically looks for an unused ID. That is my uderstanding, but I cannot guarantee that as things can change prior to a release.

Good Luck,

-Rich

[asv]

Thats for the quick reponse. I guess we will have to work on a workaround for the /usr/local issue.