Operating Systems

There are 56 posts filed in Operating Systems (this is page 4 of 6).

setting up Solaris zones

I promised to follow up on the last article about Solaris Logical Volume Manager with one about setting up Solaris zones, so here it is.

For those of you not in the know, Solaris zones (or containers; the terms are used interchangeably) is Sun’s virtualization technology, similar to Microsoft Virtual Server or VMWare‘s products. However, the “guests” (or “non-global zones” in Solaris-speak) must also be Solaris, and effectively run the identical base system as the “host” (or “global zone”). This is quite similar to the way FreeBSD’s jails work.

Sun is pushing the zone technology very hard these days, due to virtualization technology being the hot topic in IT at the moment. Solaris Zones do have some interesting advantages over even FreeBSD jails, namely:

  • patches applied in global zone are automatically applied to the non-global zones (for the most part), easing maintenance;
  • ability to share the pkgdb from the global zone to the non-global zones;
  • ability to easily loopback-mount global zone filesystems from within non-global zones;
  • ability to do some resource control (CPU shares only) upon the non-global zones

I predict that Sun engineers are working very hard on adding more knobs to the last item, so that you’ll eventually be able to control how much swap, RAM, etc. that the non-global zones are using.

Continue reading →

oops, we didn’t QA patching on zone-enabled systems

(I’m still writing my article on setting up zones under Solaris 10. Bear with me while I assemble all the relevant details)

I just got hit by this bug:

Transition patching (-t option) is not supported in a zones environment.

Basically, you can’t patch a system with non-global zones installed without manually hacking an rc script! As the last comment in the thread says, “Hmm, the thing that most concerns me is that a bug that obvious should have been found in even the most cursory testing.”

FreeBSD and Linksys WAP54G – solved

I finally got my FreeBSD laptop to authenticate to the company’s WAP 54G wireless access point. It turns out that the problem was with the Linksys firmware! I spent two days futzing with FreeBSD and trying to figure out why the iwi card wouldn’t associate with the access point, and finally in frustration I flashed the WAP54G’s firmware to version 3.04 (from version 2.08), even though the release notes said nothing about fixing WPA association. And it worked!

I guess this is what happens when you buy consumer-grade devices.

bad ideas in usability

At my new company I unfortunately have to deal with Active Directory. I understand that AD is supposed to be the authoritative source for any information about users, groups, computers, and so on, but does the interface have to be so crammed with junk?

This has got to be the worst interface I’ve ever seen (Lotus Notes aside, but I’ve never had to administer Notes). It’s not clear where to find anything! Not only is the interface kludgy (multiple rows of tabs?) but the tab labels are totally non-intuitive. Why are there at least four tabs pertaining to e-mail (Microsoft Exchange)? What the heck is the Member Of tab for, and how does that differ from what I might find under Account?

I can’t imagine trying to administer hundreds of users with this kludgy tool. Thank God our company is only < 50 people.

The Design and Implementation of the NetBSD rc.d System

This is a moderately old paper, but I think it’s worth reading if you want to understand the rationale behind the NetBSD rc.d startup system. I think this is what is referred to on FreeBSD (which has adopted a similar mechanism) as rcNG.

The Design and Implementation of the NetBSD rc.d system

There are many things to like in this design, which is far better than the organic (to put it politely) way in which the system startup sequence of a given Linux box has evolved. For one, it has the following advantages (outlined in the paper, but I’ll detail them here if you don’t want to read it):

  • Independence from lexicographical ordering of filenames (no S90foo running before S91foo), which always struck me as having a sort of BASIC-style limitation (i.e. back in the day having to number your code lines in multiples of ten in case you wanted to insert code in between)
  • Use of dynamic dependency ordering (via a special header and the rcorder script)
  • No reliance upon a special platform-specific "function" library, as is the case in many Linuxes
  • Centralized system configuration via /etc/rc.conf — no bloated /etc/sysconfig nonsense as on many Linuxes (but this is a topic for another day)
  • Avoidance of mandatory runlevels, which I can never remember on a given Linux or Solaris machine. ("What is runlevel 5 again?")

I could go on, but I urge you to read the paper instead, where Luke demonstrates a solid design methodology and rationale and then executes on the same. This is more than can be said for Linux.

operating systems that hold your hand too much…

I’m all in favour of making an operating system like Linux easy-to-use. Linux’s popularity means that for many users it is the only exposure to a UNIX-like operating system that they are likely to see, and that’s why it’s important to give them the best first impression of UNIX so that they’re not turned off by it. This includes being standards-compliant and introducing as few distribution-specific hacks as possible.

I bring this up in the context of shell aliases. Today I was alarmed to see the following set by default for all users on a a SUSE Linux Enterprise Server 9 system:


alias +='pushd .'
alias -='popd'
alias ..='cd ..'
alias ...='cd ../..'
alias beep='echo -en "07"'
alias dir='ls -l'
alias l='ls -alF'
alias la='ls -la'
alias ll='ls -l'
alias ls='/bin/ls $LS_OPTIONS'
alias ls-l='ls -l'
alias md='mkdir -p'
alias o='less'
alias rd='rmdir'
alias rehash='hash -r'
alias unmount='echo "Error: Try the command: umount" 1>&2; false'
alias which='type -p'
alias you='yast2 online_update'

I get very alarmed when I see default behaviour set like this. There are a number of issues with this:

  1. It misleads new users by making them believe the behaviour of “ls” and other commands is different than what the actual default behaviour is.
  2. It introduces a set of commands to the user (e.g. “rehash”) that don’t really exist in the shell, leading to confusion if the user goes to use another UNIX machine without these aliases.
  3. It misleads users into believing that some DOS commands also exist in the Bash shell (e.g. “rd” or “md”). Rather than encouraging them to learn the correct commands, these aliases provide a crutch to the user that they are unlikely to discard. They may then use this incorrect information when describing procedures to other users. This would particularly be disastrous in an interview type situation (e.g. “Q: What is the correct command to make a directory under UNIX?”)

All of these aliases are unnecessary and imply that the personal shell alias preferences of SUSE developers are being imposed upon all users.

I would like this to serve as a call to all distribution vendors, SUSE particularly, to not ship Linux with unnecessary customizations that only serve to confuse users and introduce disparity between Linux distributions where none originally existed.