uname on imported HP-UX Containers

[Michael Streifel]

I have found ways to change the uname -i output (machine id) for HP 9000 containers and HPVMs but I can't find any way to change the uname -i output of a HP-UX container that is exported from one server and imported to another.  I have two rx2800 servers that I have a product licensed on and multiple containers on each server.  In case of a disaster I want to be able to move the containers from one server to the other. 

The problem is that the software is installed in the /opt directory and when I import the container on the other server it fails because the license key is pointing to the previous servers uname output.  In order to change the license key to the new uname output on the different server, I must reinstall the software with the key for that server.  When I reinstall, it wipes out all the configuration information and I need to totally reconfige the product again.

Is there a way to change what the machine ID is with regular HP-UX system/shared containers?

Or is there a way to point a container to the /opt directory of the global view so that when I import the container it would not copy the software and license key from the exported container on the other server?

Thank you.

[Patrick Wallek]

You can control what is displayed with the 'uname -i' command in a container by modifying the /.ariesrc and /.aries64rc files.  The parameter in the files that controls the 'uname -i' output in the container is the "-machine_id" container.  This files can be set on a container-by-container basis.

If you have the "HP9000 Containers A.03.01 on HP Integrity Server Administrator Guide" this is discussed on page 30-31 (Section 4.8.3 Configuring machine-specific parameters).

Examples below:

Before modifying /.ariesrc and /.aries64rc

11.23 root / # uname -i
2815418294

After modifying /.ariesrc and /.aries64rc

11.23 root / # uname -i
abc123

11.23 root / # cat /.ariesrc
/ -pa_os_cpu
/ -pa_os_ver B.11.23
/ -compat_legacy
/ -machine_id abc123

11.23 root / # cat /.aries64rc
/ -pa_os_cpu
/ -pa_os_ver B.11.23
/ -machine_id abc123

[Michael Streifel]

This is not an HP 9000 container.  It is just a normal HP-UX container.  Thus the .ariesrc files don't exist and aren't used for these type of containers.

[Patrick Wallek]

I'm not sure what you mean by a "normal HP-UX container".  The container options I am aware of are "HP9000 system containers" and "HP9000 classic containers".  The .ariesrc and .aries64rc files are available on both.

[Michael Streifel]

Well there are non HP 9000 containers.

From the HP-UX container release notes.

HP-UX Containers overview

HP-UX Containers, formerly HP-UX Secure Resource Partitions (SRP), provides an environment for
consolidating multiple workload environments within a single image of the HP-UX 11i operating system. HPUX
Containers is a component of the Virtualization Continuum for HP-UX and offers high efficiency in
resource utilization and performance, while reducing the number of operating systems to manage. HP-UX
Containers enhances the capabilities and ease of deployment for high availability environments, including
Serviceguard.

HP 9000 Containers product

HP 9000 Containers provide a binary emulation environment for HP-UX PA-RISC workloads. The HP 9000
Containers product is installed separately from the HP-UX Containers (SRP) product. Once the HP-UX
Containers (SRP) and HP 9000 Containers products are both installed, you can use the srp(1M) command
to create and manage HP 9000 containers. For produce version requirements, and details on how to
configure and manage an HP 9000 container, see HP 9000 Containers documentation at https://
support.hpe.com/hpesc/public/home/documentHome?sp4ts.oid=5118547.

[Duncan Edmonstone]

So are you saying the software you are running is *not* HP9000/PA-RISC binaries and just actual native IA64 binaries? In that case no playing around with .ariesrc is going to make any difference - if you want to do this in a supported way, you might consider using HPVMs instead - see this post: https://community.hpe.com/t5/virtualization/quot-uname-i-quot-on-hpvm-guest/m-p/4595616#M1994

If the software *is* HP9000/PA-RISC then the functions of .ariesrc are not linked just to containers - take a look at the aries man page for more details.

ANother approach of course if you're up for it is you can always "hack" a solution - how you do that will depend on how the application gathers the data from uname. If it calls the uname command then a simple shell wrapper replacing the uname command should work with a bit of trial and error. If it calls the uname system call, then you have a bigger challenge to find a way to put a wrapper around the libC library and intercept calls to uname and deal with them differently - it is I expect do-able but probably not for the faint- hearted - this approach seems to have worked for older versions of HP-UX: http://okmij.org/ftp/syscall-interpose.html

[Michael Streifel · Accepted solution]

I have decided to go with a shared filesystem on the global view that is mounted as read only by all the containers.  I then installed all the software that requires a license on the shared mount point.  So now when I export and import a container from another system, the licensed software isn't part of the container build. It uses the software of the global mount point which has the correct license key for the uname output.