New operating system releases!

This is just amazing: did everybody coordinate this? Within the last three weeks or so, we’ve seen these releases come out:

Several of these were released on the same day, November 1.

What next? Am I really supposed to choose just one? Sigh. And I just installed OpenBSD 4.1 and Fedora 7, too – not to mention installing FreeBSD 6.2 not too long ago.

From all the talk, I’ll have to try Kubuntu again. So many systems, so little time.

I have been using OpenSUSE 10.3 (with KDE). I just love it – and I love the new menu format, too.

Update: Sigh. I should have known. Microsoft Windows Vista celebrated its 1st Anniversary on Nov. 8.

Locking out root!

This is not as far fetched as it sounds; every Macintosh OS X system comes configured in this way: it is impossible to log in as root.

How does one do things as root then? I shall reveal the secret…

First of all, one needs to make sure that the program sudo is available and correctly configured. It must be configured to allow you (or the system owner) to switch to root. Best to test this directly before doing anything to the root account.

Once you have verified that you can switch to root using sudo, then it is time to actually lock the root account. Before doing so, open a root shell using sudo or a direct log in as root. Then execute:

# passwd -l root

There! Now no one can log in as root – don’t you feel much better? Well…. you can become root (by using sudo) but logging in directly as root is impossible.

If passwd does not recognize the -l option, then just put an asterisk (*) into the password field, wherever it is. HP-UX, Linux, and Solaris all recognize the -l option; FreeBSD uses the -l option for a different purpose.

For FreeBSD (and quite probably, OpenBSD and NetBSD as well), use the vipw command to lock out not only the root account, but the toor account as well. The toor account is identical to the root account (including userid) but allows user customization.

When combined with the wheel group, this will lock down your root account quite effectively. Just don’t stop there: remember to use multiple defenses. However, that’s a topic for another day.

Update: This is most useful in situations where a normal user will always have access (workstations come to mind).  If your normal users are authenticated via NIS, or Active Directory, or LDAP, don’t do this! If root logins are locked out, and none of the users can log in…….. then what?  Uh oh….

Researching the Dynamic Loader on Any System

In finding information about the dynamic loader and shared libraries in general, there are several places to look. The obvious Internet location is Google; however, the system itself has a lot of information about shared libraries if one only knows where to look.

The first place is the information on the dynamic loader’s man page. Unfortunately, most loaders have names that are unique among their UNIX peers (Linux is almost universal). You can start by looking at the /lib directory for a program containing the string “ld” (or perhaps, “dl”). On Linux, this produces:

# ls -d *ld*

The proper Linux loader is

On HP-UX, this produces:

# ls -d *ld** libdld.2* libldap_send.1*
libdld.1* libnss_ldap.1*

Here, the proper loader is

Looking at the man pages for or or whatever was found gives a vast amount of information directly related to the dynamic loader and how it loads shared libraries, as well as debugging tools to report on how the libraries are found and loaded.

This man page will also mention utilities that will help you manipulate shared libraries. For example, the Linux man page for mentions ldconfig(8); the HP-UX man page for mentions the utilities fastbind(8) and chatr(8).

There are other utilities that remain fairly generic and which can help, though these tend to be specific to machines that are configured for development. If the development tools are not loaded, these tools may be missing. These utilities may include:

  • ldd – list libraries used by a binary
  • nm – list symbols from program binaries and/or libraries
  • objdump – display information from binaries and/or libraries
  • readelf – display information from ELF-formatted binaries

Always look at the SEE ALSO section in order find more information.

A “new” file pager: view

I, like most people I know, adore the file pager less. However, for whatever inconceivable reason, new UNIX systems (Linux doesn’t count here!) virtually never come with less. So… what to do when less is missing?

HP-UX, for one, comes with more and pg. Everything comes with more – but once you’ve used less you’ll never want to use a standard more again. The pager pg really isn’t any better.

Is there a solution? Yes – view.

What is view? The program view is a file pager which is included on virtually all UNIX and Linux systems. The view program is available, for example, in Solaris 9, HP-UX 11i v2, FreeBSD 6.2, Red Hat Linux 9, and more.

If you know vi, then you’ll know view. Why? Because view is actually vi in disguise, acting as a file pager with read-only access to the file.

The biggest drawback to view is that it does not handle stdin; that is, using view as the destination of a pipe gets very messy very fast (i.e., don’t do that!).

Apparently, vim handles this situation much better. Perhaps much better: there are ways to specify the use of vim with less keymappings, and to use view (i.e., vim) for general pager use! There are directions on how to make vim work as a man page viewer complete with syntax highlighting. Here is the quick and dirty instructions (for ksh):

export MANPAGER="col -b | view -c 'set ft=man nomod nolist' -"

For less key bindings, use (for ksh again):

export MANPAGER="col -b | /usr/share/vim/vim61/macros/ -c 'set ft=man nomod nolist' -"

Be sure to use the right macro location for your version of vim. If you check out the original directions, be sure to read all of the comments: there are directions on how to properly configure the environment so reading man pages inside vim will work properly, and so that non-English locales can be handled properly, and more.

Next time you find yourself suffering without less – stop suffering through more and use view instead. You’ll be glad you did.

Large LVM volumes on HP-UX

When creating a large LVM volume group (over roughly 100G in size) under HP-UX, the process may fail mysteriously or hang. Working through the SAM administration GUI creates more mysterious errors

The solution and cause to this problem was explained nicely by Jim Marsden clear back in 2004. The problem comes up because when the LVM software was created, 9G and 18G volumes were the most common. Now with 100G+ volumes, the numeric limitations of LVM are becoming known.

Another limitation is that the volume group overhead data is becoming so large that it can no longer fit into a single physical extent (PE). This reserved area is called the Volume Group Reserved Area (VGRA). The VGRA is only one of several reserved areas, but is the only one we’ll discuss here.

To get around these limitations, you will have to create the volume group with a PE size large enough to contain the full VGRA, as well as a PE size that will accommodate the entire disk. If the volume group is already created with the default PE size of 4M, then it will have to be recreated with a new PE size. PE sizes are typically 4M, 8M, 16M, 32M, 64M, 128M, and 256M. Pick the smallest size that will work.

After the PE size is set, another limit must be set: the maximum number of physical extents per physical volume. This limit can be found by dividing the size of the largest disk by the PE size (mind those units!). For the current gigabyte-sized drives, this formula is:

MaxPEperPV = (gigabytes * 1024) / PEsize

For example, a 200G drive with 16M PEs translates into a MaxPEperPV of 12800.

Given these two pieces of information, the volume group can be created using the standard LVM utility vgcreate at the command line thusly:

vgcreate -s PEsize -e MaxPEperPV NewVG Disk1 Disk2 ...

For example, using our current values, you might do:

vgcreate -s 16 -e 12800 /dev/vg00 /dev/dsk/c1t0d0

This problem might be present in some form in the Linux LVM implementation, but I rather doubt it – at least not until terabytes become common (uhoh….).