Within Reason

OpenSolaris Test Farm

Ceri Davies — Fri, 31 Oct 2008 20:10:00 +0000

I decided long ago that I didn’t want to run machines at home 24x7 and I didn’t want to spend money chasing performance. In fact, my main machine at home has an 800MHz VIA C3 CPU and just 512MB of RAM, and every other machine that I could be running OpenSolaris on is just as bad. I have access to much better hardware at work but it’s work hardware and not for that job.

Watching my attempts to build ONNV fail after 7 hours has always been slightly disheartening, especially when I’ve had to LiveUpgrade to a recent build first. Needless to say, the lack of good hardware with up-to-date tools has been somewhat of a barrier to my involvement. However, as of earlier this month, Sun has been providing the OpenSolaris project with a hosted farm of test machines that contributors can use to build and test software. There are two kinds of accounts, one for building software and the other for testing it.

The first, a Build Server account, gives you 15GB of disk space on a variety of machines of different processor types, which you can then use for compilation. These machines run builds of Nevada and the compilers that are recent enough to be able to build ONNV and they do it quickly; building ONNV on a 16-core x4600 in the Test Farm takes under one hour^[1], which is massive boon to me if nobody else. Setting up an account is a simple matter of clicking “Add Account” on the test farm interface and waiting a few minutes.

The second kind of account reserves you an entire machine with console and SP access to splat your software over so that you can see if the machine still boots. There’s a bit more of a queue for one of these systems as obviously they can’t be used in parallel by more than one user but, again, all you need to do is click the relevant button in the interface and wait for a mail telling you that your server is ready.

If you have signed the Sun Contributor Agreement for OpenSolaris then you’re already set up on the Test Farm so go and grab an account now!

[1] And would probably take a lot less time if I could set DMAKE_MAX_JOBS higher than 4 :)

Converting SVR4 packages to datastream format and back

Ceri Davies — Thu, 30 Oct 2008 20:54:00 +0000

OK, so SVR4 packages on Solaris are not the future, but for those of us with existing Solaris installations, we’ll be using pkgadd for some time.

While vendors seem to vary in their preference for datastream format (i.e. a single file) packages and what the Solaris documentation calls “file system format” packages (a directory), it’s pretty certain that a download of a package from the Internet will come in datastream format.

The datastream format is useful for distribution, but it’s slightly annoying for scripting and I personally hate not knowing what’s in a datastream package before I “run” it (preinstall scripts could do anything to your system, while the package itself could overwrite anything too). Therefore, I like to explode them to file system format and check them out first. This can be done easily with the pkgtrans tool.

To convert a datastream package to a file system package:

pkgtrans package-0.4.2.pkg /tmp all

The command above will explode all packages contained in the package-0.4.2.pkg file to directories in /tmp.

To convert a directory of file system format packages to datastream format, assemble them in the same directory, say /tmp, and run:

pkgtrans -s /tmp /tmp/foo.pkg all

This will create a single file, foo.pkg, containing all of the packages available in /tmp.

Invocations of the form pkgtrans -s Solaris_11/Product /tmp/nv97_sparc.pkg all are a slightly tidier way of keeping installation archives around.

Book Review: Network Administration with FreeBSD 7

Ceri Davies — Mon, 22 Sep 2008 20:31:00 +0000

I was approached some time ago by Packt Publishing with a request to review Network Administration with FreeBSD 7, a new book by Babak Farrokhi who is a FreeBSD committer among other things.

Right from the Preface it seemed clear that neither the author nor any of the editorial staff were native English speakers which, being the way that I am, made it very difficult to get into. Somewhere around chapter three, this improved drastically however, and I could finally manage to concentrate on the content. Which is good news, because the content is excellent.

Network administrators at any scale, from LAN to WAN, will find something useful. Routing protocols such as OSPF and BGP are covered, and there’s a good chapter on IPsec (and non-IPsec) tunnels which was directly useful to me personally while I was reading. Also welcome was information on IPv6 and a chapter on kernel tuning.

With multi-core systems such as Sun’s X4450 behemoth and the fine-grained locking in the network stack that FreeBSD enjoys now that GIANT is pretty much a distant memory, using FreeBSD on an off-the-shelf system to run hardcore bits of the network is practical, and this book works really well as a way to find out what the system is capable of and how to get started. Short chapters on getting familiar with FreeBSD and basic administration are also included, so there’s really no excuse not to take a look!

Moved

Ceri Davies — Thu, 26 Jun 2008 18:43:00 +0000

Since it was set up, this machine has lived on my gateway FreeBSD machine in what has since become the boy’s bedroom. It moved from there to my own bedroom, and I recently started turning it off at night to try to save power (and sleep better!).

This led to a number of people emailing me about outages - which was quite flattering; didn’t realise anyone would care about my crappy blog that much - because they were in a timezone disparate to be trying to get to it during the hours I had it turned off.

Therefore, and with the realisation that I could get a hosted solution for $12/month (US), I have moved this blog to a Solaris^[1] zone hosted at Gangus Internet. Service (technically and customer-servicely) so far has been absolutely impeccable.

If you are reading this, I guess the move went OK.

[1] Which is not a reflection on FreeBSD in any way. Questions such as were asked after this commit are unnecessary :)

New release of tcpdrop for Solaris

Ceri Davies — Fri, 16 May 2008 21:09:00 +0000

Some years ago I ported tcpdrop to Solaris from the FreeBSD version. I did it very quickly as a proof of concept and never got round to quite getting the error handling right or worrying about Solaris 10 privileges.

After spending the required 14 seconds looking at the privileges stuff, it became pretty clear that the required privilege for using tcpdrop was PRIV_SYS_IP_CONFIG. This cannot be asserted in a non-global zone, so if you are one of the many people who have emailed me asking if it can work in a non-global zone, the answer is “no, it can’t”. Not only that, but there’s nothing I can do about it.

Also in this release, I fixed up the error messages so that they are at least correct :)

The next release will feature a manpage in man format, rather than the current mdoc one which can’t actually be formatted on Solaris. Anyone who knows an automated method to convert from mdoc to man, please shout.

Anyway, the new release is available for download, knock yourselves out.

Check your T5220!

Ceri Davies — Fri, 15 Feb 2008 21:44:00 +0000

We took delivery of a pair of T5220s last week for implementing a new cluster.

All in all they’re nice systems, but the components such as the disk fillers and the DVD drive seem a little on the too plastic side; since the front USB ports are integrated on the DVD drive panel, there’s even a note in the hardware manual warning you to be careful not to unseat the DVD drive when removing USB devices! The PCI risers seems a little wobbly too.

We were a little surprised by how much heavier they seem to be when compared to the T2000; racking a T2000 can be done on your own but I wouldn’t want to do a T5220 alone. The T5220 is about 4 inches longer though which may account for the extra weight.

Since we’re a little nerdy, the first thing we did with the system was take the service panel off to check out the innards. It turned out to be a good job that we had, as the air duct had completely come away from its correct position during transit, and this would have made the system very unhappy. Particularly so, since the fan modules were a little loose too.

Profile support for zsh

Ceri Davies — Wed, 12 Dec 2007 21:47:00 +0000

I’ve been using zsh for ages now, and the lack of a pfzsh implementation has been a minor annoyance for some of that time.

I happened to be looking at the csh source code and noticed how trivial the pfcsh implementation was and so, using the SFW code as a base, I threw pfzsh together yesterday afternoon.

Now, it turns out that the OpenSolaris FGAP project will be solving this in a different way, so a putback to SFW is unlikely. However, I’m going to find this useful in the meantime, so if you will too, download either the patch or an x86 package if they are useful to you.

OpenSolaris as SCSI target

Ceri Davies — Mon, 19 Nov 2007 21:53:00 +0000

The OpenSolaris COMSTAR project released their first set of bits at the end of last week.

The code drop, SUNWsmft, comprises support for using an OpenSolaris system as a SCSI target, which means that OpenSolaris now supports native CIFS, iSCSI, SCSI and NFS with a transactional COW filesystem, runnable on a system that costs less than £20k (half that in certain industries) for 24TB, explaining why NetApp are very scared indeed.

I had to try it out as soon as possible. Luckily the code drop works on Solaris 10 as well as OpenSolaris, and I had Solaris 10 systems and HBAs available for testing. In order to isolate this from our real SANs, I just ran a fibre channel cable between the HBAs, so was somewhat wary that I had no idea how to get a HBA to do arbitrated loop. Turns out that isn’t a problem, and here’s all I had to do to get this working.

Install SUNWsmft

Grab the package and install it.

 # fetch http://opensolaris.org/os/project/comstar/files/SUNWstmf.sparc.tar.gz
 # gzip -dc SUNWstmf.sparc.tar.gz | tar xf -
 # yes | pkgadd -d . SUNWstmf

Choose target ports

The postinstall script loads the kernel modules straight away, so now you just have to choose a HBA port to put in target mode using the qlt driver. My test target system has two dual port HBAs and I couldn’t remember which one had the cable connected, so I just did them all and rebooted:

# update_drv -d -i '"pciex1077,2432"' qlc
# update_drv -a -i '"pciex1077,2432"' qlt
# init 6

When the machine comes back up, qlt attaches and the HBAs automatically negotiate an arbitrated loop. Great.

Create LU backing

I’m going to use ZFS zvols because I don’t want to wait for mkfile to finish (I have to use a zpool with a funny name since I’m doing this in a rush and this is what I have):

# zfs create archive/stmf
# zfs create archive/stmf/lun
# for i in `jot 10 0`; do zfs create -V 1g archive/stmf/lun/000$i; done

Register LUs

Now you have to tell the COMSTAR bits about the LUs you created.

# for i in `jot 10 0`; do sbdadm lu-create -r /dev/zvol/dsk/archive/stmf/lun/000$i; done
# sbdadm lu-list

Found 10 LU(s)

              GUID                  DATA SIZE     SOURCE
--------------------------------  -------------  ----------------
6000ae4000144f86b97e4741f80e000a     1073676288  /dev/zvol/dsk/archive/stmf/lun/0009
6000ae4000144f86b97e4741f80d0009     1073676288  /dev/zvol/dsk/archive/stmf/lun/0008
6000ae4000144f86b97e4741f80c0008     1073676288  /dev/zvol/dsk/archive/stmf/lun/0007
6000ae4000144f86b97e4741f80a0007     1073676288  /dev/zvol/dsk/archive/stmf/lun/0006
6000ae4000144f86b97e4741f8070006     1073676288  /dev/zvol/dsk/archive/stmf/lun/0005
6000ae4000144f86b97e4741f8060005     1073676288  /dev/zvol/dsk/archive/stmf/lun/0004
6000ae4000144f86b97e4741f8060004     1073676288  /dev/zvol/dsk/archive/stmf/lun/0003
6000ae4000144f86b97e4741f8050003     1073676288  /dev/zvol/dsk/archive/stmf/lun/0002
6000ae4000144f86b97e4741f8040002     1073676288  /dev/zvol/dsk/archive/stmf/lun/0001
6000ae4000144f86b97e4741f8030001     1073676288  /dev/zvol/dsk/archive/stmf/lun/0000

Create views

Now I have to create a view to allow the initiators access to the LUs I’ve created. Since I don’t know what I’m doing at this point, I just open them all; in production we’ll use host groups (“stmfadm create-view”) but I’m just throwing it open here:

# stmfadm add-view 6000AE4000144F86B97E4741F8030001
# stmfadm list-view -l 6000AE4000144F86B97E4741F8030001
View Entry: 0
    Host group   : All
    Target group : All
    LUN          : 0

Reinitialize the link on the initiator

In order to get the initiator to see the new LU, I have to do the following (one or other of these three commands always works, but no single one ever works 100%):

# luxadm -e forcelip /devices/pci@1d,700000/QLGC,qlc@2/fp@0,0:devctl
# cfgadm -al
# devfsadm -C -v
#  format
Searching for disks...done

c3t210000E08B945E9Fd0: configured with capacity of 1023.88MB


AVAILABLE DISK SELECTIONS:
       0. c1t0d0 <SUN72G cyl 14087 alt 2 hd 24 sec 424>
          /pci@1f,700000/scsi@2/sd@0,0
       1. c1t1d0 <SUN72G cyl 14087 alt 2 hd 24 sec 424>
          /pci@1f,700000/scsi@2/sd@1,0
       2. c1t2d0 <SEAGATE-ST373207LSUN72G-045A-68.37GB>
          /pci@1f,700000/scsi@2/sd@2,0
       3. c1t3d0 <SEAGATE-ST373207LSUN72G-045A-68.37GB>
          /pci@1f,700000/scsi@2/sd@3,0
       4. c3t210000E08B945E9Fd0 <SUN-COMSTAR-1.0 cyl 32764 alt 2 hd 2 sec 32>
          /pci@1d,700000/QLGC,qlc@2/fp@0,0/ssd@w210000e08b945e9f,0
Specify disk (enter its number):

yay!

On interfaces

Ceri Davies — Mon, 19 Nov 2007 20:27:00 +0000

On our way to work, there is a crossroads.

The crossroads has traffic lights on each spur, and Stef has discovered that if you press the button at one crossing, it has the effect of causing all the crossings to be activated. Therefore, on the way past the first crossing she hits the button so that by the time she arrives at the crossing that she does want to take, it has made the lights go green.

I pulled her up on this as an abuse of the interface, warning her that there were no guarantees that this functionality would be present in a future version of the lights and that it was users like her who caused headaches for developers trying to refactor and improve older software.

She just shook her head.

hagui on Mac OS X

Ceri Davies — Wed, 29 Aug 2007 22:16:00 +0000

VCS’ hagui is basically pointless, but I do like a live diagram of what’s going on when I’m creating new service groups. I also like my Mac, so here’s the quick how-to on getting it working on the Mac.

Extract the VRTScscm package from the install media, and copy it somewhere permanent. I’m using my home directory.

   $ gzip -dc VRTScscm.tar.gz | (cd /tmp; tar xf -)
   $ mv /tmp/VRTScscm/reloc/opt ${HOME}

Fix the VCS_HOME and JAVA_HOME variables in the hagui script.

   VCS_HOME="${HOME}/opt/VRTSvcs"
   JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home

I create a symlink for convenience.

   $ ln -s ../opt/VRTSvcs/bin/hagui ${HOME}/bin

Job’s done. While you’re here, this is the best video on YouTube, JFYI.