Is Bigger HP-UX Better HP-UX?

Just the other day, I saw a laptop advertised with a 19-inch LCD. I decided I didn'tneed it, because my lap is not that large. It's also becoming increasingly difficult tofind a disk smaller than 2GB, making it hard to service older machines.

Operating systems are getting "bigger" too. For starters, overall size is wayup, with most taking up hundreds of MBs. They're getting "wider" also, by goingto 64-bit, so 128-bit hardware and operating systems can't be that far behind. The problemwith all this is that the majority of systems don't need it. At least, not yet.

Starting in 1996 with 10.20, HP-UX began allowing larger users than in the past.Actually, it's the users Unique Identifier (UID) that got larger by supporting 32-bit UserID's instead of the previously supported 16-bit. For the binary impaired, that means wewent from 64,000 to two billion possible UIDs.

For non-systems administrators, every login name on a system has a number assigned toit. This number, or UID, is stored with every file owned by the person using that loginname. It's also used to identify which processes that user is running. Executing the idcommand will show the UID number assigned to your login as well as the group ID.

For a very few systems out there, this is a good thing. But in reality, how many peoplehave over 64,000 users in the password file? At first glance, this appears to be yetanother useless improvement.

Take a closer look and you start to realize that UID numbers need not be consecutive.Prior to HP-UX 10.20, and currently at most sites, the UID number was assigned somewhatarbitrarily. The typical method was to find the next available number or possibly thelowest number available (unused). This made the UID purely for use by the operatingsystem, since it had no real-world meaning.

FREE RANGE CHECKING

Some administrators assigned ranges of UID numbers to be used by different groups ofusers or buildings. That was somewhat handy, because an administrator could determine sometype of information about the user by looking at the UID. The command ypmatch tedd passwd(or grep tedd /etc/passwd on non-NIS systems) returns a colon delimited line of text, ofwhich the third field is the UID.

There are some very large systems, with hundreds of thousands of users for whom the32-bit UID is obviously useful. For the rest of us, the advantages are only apparent if westart using it. Here's an example that one of my customers has started using (after alittle push).

This company, like many, assigns employee numbers that happen to be six digits long.Starting a few months ago, new users added use their employee number as the UID (you caneven fit a social security number in a 32-bit UID). This makes for easy mapping of username to number, but it also allows many programs to automatically determine the employeenumber.

This particular company now has an expense reporting program that looks at the usersUID. If it's six digits long, it automatically fills in name/address/organizationinformation by looking up the user in a database. If it's five digits or less, it promptsfor the employee number.

It's possible to re-assign UIDs for existing users by making the change then doing somerecursive chown commands on all the disks, but they haven't approached that issue yet.

Another interesting technique presented by HP engineer John Fenwick at Interworks '99'sHP-UX System Administration Conference, was to use a person's phone number as the UID. I'msure there are other mappings that make more sense in your environment.

CONVERSION AVERSION

There are several things you must be aware of before running off and assigning UIDsbeyond 65,534 in your network. The first is that all filesystems that will contain filesowned by users with large UIDs must be converted to understand large UIDs. This is a minorissue when using High Performance File Systems (HFS) because they'll be convertedautomatically when any large UID owned file is created.

Here's an example of an HP-UX 10.20 system converting an HFS filesystem on the fly:

$ fsadm /dev/vg00/lvol3 | grep large
file system supports : nolargefiles, longfilenames
$ touch /tmp/big
$ chown 9913044 /tmp/big
$ fsadm /dev/vg00/lvol3 | grep large
file system supports : nolargefiles, largeuids, longfilenames

Take note that the conversion was automatic. Also note that if you don't have patchesinstalled, on the second fsadm you might have gotten the error "The primary andalternate super blocks do not match." If you were to delete any large UID files, thenext fsck will clear the largeuids flag, though it doesn't change the disk UID structures.

If you're using the Veritas File System (VxFS) instead of HFS, it must be version 3.0,which was shipped in HP-UX 10.20. If you have older filesystems mounted, you cannot havefiles owned by large UID users on those filesystems.

The second issue is that applications must be recompiled to understand large UIDs.HP-UX system commands (as of 10.20) have all been recompiled so they can translate largeUIDs to usernames. If you have other applications or programs that try to convert a UID toa username, they'll have problems if they're not recompiled.

Another feature of magnitude that came about in 10.20 is support for larger file sizes.Release 10.10 could handle a filesystem of up to 128GB. In 10.20 you can amass a singlefile that large. This might seem like overkill until you realize that there are many RAIDproducts that can be mounted as one very large filesystem. A scary thought is that thetheoretical limit is a terabyte, but HP has only tested up to 128GB.

Large files are supported by the operating system, but remember that if you haveapplications that need direct access to large files, they must be recompiled (with theoptions of -D FILE_OFFSET_BITS=64 or -D LARGEFILE64_SOURCE depending on how the code iswritten).

The filesystems where these larger files are stored must also be specifically created,or changed for largefile support. The newfs command now has a -o largefiles option forboth HFS and VxFS.

An existing filesystem can be changed to large file size support with the fsadm option-o largefiles. These large filesystems should be mounted with the -o largefiles option ofthe mount command.

In release 10.20, large files are only supported locally, not through NFS. HP-UX 10.3,a support release, shipped with NFS Pv3. That version of NFS is required to access theselarge files over the network.

There are many more big things to discuss, especially with HP-UX 11. Let me know whatinterests you.

Must Read Articles