product-server style installation

I'm currently working through some issues with product-server style installs. The idea being that you install the Sun Studio compilers and tools on a big machine with lots of disk and network bandwidth, and then multiple machines can NFS mount the installation directory instead of having to install the product. I've had some feedback to the effect that what people really want is to run the installers for each architecture directly on the server and just tell each installer to use a different directory (which would then be shared). Currently, we don't support this. We only support running the installer on the same architecture as the product it installs. One way people have of trying to make this work better for them is to use the -R (alternate root dir) flag to force every modification of the system to be under some directory. That way, you can NFS mount the server on an appropriate architecture client with the right root-access flags, and do the install without worrying about modifying the client system. I have a hard time recommending this though. For one thing, it makes it hard to patch the product. So in the current release, there really isn't a nice solution.

For the next release, I've already done something to ameliorate the problem with -R and patching. It turns out that patchadd really only wants to see a certain single file before it will "believe" that a directory is a valid root filesystem and apply patches. So I've made the installer startup script fake up that single file in the -R case. Although this is not a formal Solaris interface with an assigned stability level, I've been told by the engineering group concerned that it is unlikely to "ever" change.

The next thing I did was look at what, if anything, prevented the packages from the two Solaris architectures being installed on the same machine (without alternate root). Solaris says that the tuple {name, version, architecture} must not already have been installed, otherwise this constitutes an attempt to overwrite a package (rather than a fresh install). Also, the package in question must have fewer instances installed than the maximum specified in the package info file. All the packages in the product have a large number for MAXINST, so that shouldn't be a problem. Naturally, the version number will be the same for the same package on the two architectures, if they come from the same build. So we have to hope that the ARCH is unique. It turns out that this is the case for all but two packages in the product, which have ARCH=all on both cpu types. This is clearly wrong for one, and arguable for the other, so I've made the change so that all the packages have distinct ARCH on the two different CPUs.

Next the question is what do you have to do to get the Install SDK code to allow you to install on an architecture different from that specified in the package. This seems to be very easy. There is an internal install property that you can set, but if the installer itself doesn't set it, it comes from the Java system property os.arch. So you can just run the installer with -Dos.arch="sparc" and install your SPARC product on an AMD64 server. There is one problem with this, which is that there is a native-code executable which forms part of each installer. One of the things it seems to be used for is to find out how much disk space is available. So when you trick the installer into cross-installing, it does warn about insufficient disk space. I have not yet researched whether it is possible to provide multiple versions of this executable.

Anyway, progress is being made, and if anyone has any product-server use cases they'd like supported, please feel free to leave a comment or email me.

Tag:

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

terryh

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today