For the good of all of us

Building a multi OS USB boot stick, Part 1 (Windows)

nospam@example.com (Ralf Ertzinger) — 2010-03-21T17:23:49Z

Among the things I carry around is always a collection of USB sticks, for various purposes. One of those is usually dedicated to a Linux rescue system, in order to get somehow broken systems back on their feet.

While it is possible these days to access non Linux systems from a booted Linux system any repair work beyond simple text file editing and file copying usually requires OS specific tools to get the job done. Thus it would be nice not only to have a Linux rescue system at hand, but a Windows one as well. And Solaris, while we’re at it. And possibly some more.

USB sticks are cheap, at least in this part of the world. 10EUR will get you 4GB off the shelf in almost any electronics store, a little more money will get you 8GB ordered online. So space is not really an issue.

Actually installing an operating system in a way that allows it to boot off a removable media requires some specific preparations and tools in each case. This means that a running instance of that specific OS is needed to prepare the installation. This means that to get Windows to boot of an USB stick a running Windows installation is needed. The same goes for Solaris and Linux.

Preparations

The USB stick used for this exercise is a 4G Sandisk. This procedure will delete all data currently on the stick, so either make sure there is nothing of any interest on it, or just get a new one.

The initial plan is to have Windows, Linux and Solaris boot off the stick. Each OS will get it’s own partition, to keep possible clashes between the files of each system to a minimum (and because Solaris wants and UFS partition, but more on that later).

Installing Windows on USB

The standard Windows installer does not allow for installation on USB devices. The standard tool for those tasks is BartPE, a free tool to create so-called Preinstalled Environments. Those are actually a Microsoft supported way to preinstall an operating system on a PC, which is used by system builders to deliver machines with the OS already installed but not registered. The Microsoft tools to create these environments are not easily available, though, and this is where BartPE came in a few years ago. It’s original purpose was to create Live CDs of Windows, but booting from USB was added (experimentally) later.

While BartPE is a very valuable tool there is an even better one for this special purpose: The Ultimate Boot CD for Windows, which is basically a BartPE with a lot of useful tools already tacked to the side, and a completely reworked USB installer.

To use UBCD the following is needed:

The UBCD installer, which weighs in at 255MB and is available from the projects site
A Windows XP install CD (32 bit)
Service Pack 3 for XP, if the Windows CD does not already include it
A license for the Windows version (this is more a legal than a technical problem, but the Windows install on the USB stick needs a separate license to be legal)
Drivers

The last point is especially interesting. UBCD will take all drivers whichare contained in the Windows XP install CD, which, as everyone knows who tried to install XP on a reasonably recent machine, is not exactly much. While the USB installed will boot (hopefully), access to hard disk drives on the machine or access to network interfaces may be severely limited due to missing drivers.

UBCD already comes with a largeish selection of updated drivers for mass storage, LAN and WLAN, so simply building an image with the default settings has a good chance of working on a large number of modern machines (although the WLAN drivers are disabled by default).

Install procedure

Make a copy of the Windows XP CD (that is, just copy all the files on it into a folder on the hard disk drive)
If the CD did not already contain a Windows copy patched to SP3 download the SP3 install package from Microsoft, and slipstream the Service Pack into the copied files
Install UBDC
Start UBCD and enter the path to the copied Windows CD in the first field
Set Media Output to None
Click “Build”

The UBCD main screen

This will start a build process with the default settings, which are reasonable for a first build. UBCD is very customizable, most of the options are available by clicking the “Plugins” button on the main screen. Describing the various things that can be done here is beyond this text, but the UBCD home page has details on this.

After the build has finished plug in the USB stick and start ubusb.exe from the UBCD install folder. To make things easier make sure no other USB mass storage devices are connected. Set the options to match those in the screenshot below. Specifically:

Make sure the right USB device is selected
Set the partition size to 2048MB (or 2GB)
Set the file system to FAT32-LBA
Set the Boot Loader to grub4dos
Select the right BartPE folder (although it should pick up the correct one automatically)
Don’t create a CD image

UBUSB main screen

Clicking “Go” will start the process of repartitioning, formattingand copying of data to the USB stick. This may take a while.

After the process has finished (hopefully successful) the resulting USB stick can immediately be tested, because UBCD comes with a copy of qemu, which can emulate a PC. Just click the “Test USB” button, and a virtual PC will try to boot off the USB stick just created.

USB boot menu

Windows booted off the USB stick in qemu

One down, two to go.

Outgoing TLS verification in exim

nospam@example.com (Ralf Ertzinger) — 2010-03-21T13:37:01Z

Exim is a mail server which suports TLS for encrypted connections. This is supported for incoming connections as well as outgoing connections.

The support for outgoing connections is a bit useless in it’s default setting, though:

If the remote server offers TLS exim will negotiate an encrypted connection, but will not verify the certificate, rendering the encryption somewhat useless
If the remote side does not offer TLS mail will be sent in plain text.

All in all this is pretty useless from a security point of view. Making exim do the right thing requires some additions to the SMTP transport (the following is sufficient for the default exim configuration on CentOS systems):

remote_smtp:
  driver = smtp
  hosts_require_tls = *
  tls_tempfail_tryclear = false
  tls_verify_certificates = /etc/pki/tls/certs

This forces exim to use TLS for every outgoing connection (hosts_require_tls = *), forbids fallback to clear text if TLS does not work, (tls_tempfail_tryclear = false) and points to a directory containing a trusted certificates (tls_verify_certificates = /etc/pki/tls/certs).

The last parameter is the main reason for this article, as it does not exactly do what it says on the tin. The exim in CentOS is built against OpenSSL, and the OpenSSL libraries are built with /etc/pki/tls/certs as the default search path for certificates. The documentation for the parameter says:

The value of this option must be the absolute path to a file containing permitted server certificates, for use when setting up an encrypted connection. Alternatively, if you are using OpenSSL, you can set tls_verify_certificates to the name of a directory containing certificate files. This does not work with GnuTLS; the option must be set to the name of a single file if you are using GnuTLS. The values of $host and $host_address are set to the name and address of the server during the expansion of this option. See chapter 39 for details of TLS.

The part missing from this is that the path set with tls_verify_certificates is searched in addition to the default certificate search path configured for OpenSSL. So if the OpenSSL default search path already contains all the certificates required, tls_verify_certificates must be set to force exim to verify the certificates, but the value it is set to does not matter. For security reasons it ought to be set to the default OpenSSL search path, though, to prevent someone from maliciously adding more trusted certificates.

PS:
Doing this for a general purpose mail server is probably not a good idea, as many mail servers do not offer TLS, and even if they do, their certificate may not be signed by a trusted (by the client) certificate authority. The mail server in question here will only send mail to a single host.

Cisco VPN debugging by crystal ball

nospam@example.com (Ralf Ertzinger) — 2010-01-18T09:37:14Z

In the hope that google picks this up:

The problem space is a Cisco PIX terminating an IPSec VPN tunnel with a Checkpoint firewall on the other end. The tunnel does not work (the phase 2 setup fails). The Cisco logs the following debug messages:

ISAKMP (0): processing SA payload. message ID = 1911693629
ISAKMP : Checking IPSec proposal 1
ISAKMP: transform 1, ESP_3DES
ISAKMP:   attributes in transform:
ISAKMP:      SA life type in seconds
ISAKMP:      SA life duration (VPI) of  0x0 0x0 0xe 0x10
ISAKMP:      authenticator is HMAC-SHA
ISAKMP:      encaps is 1
ISAKMP (0): atts are acceptable.
ISAKMP : Checking IPSec proposal 1
ISAKMP (0): atts not acceptable. Next payload is 0
ISAKMP (0): SA not acceptable!
ISAKMP (0): sending NOTIFY message 14 protocol 0
return status is IKMP_ERR_NO_RETRANS

The log message above was created by an incoming proposal (the remote end proposed a connection to the Cisco PIX). This is useless and confusing at the same time. An IPSec proposal contains a list of parameters, sent by one end of the connection, specifying the parameters it is willing to use to establish a secure connection. This proposal specifies 3DES as the encryption algorithm, SHA as a hash function, and a lifetime for the connection of 3600 seconds (after which the connection has to be renegotiated).

As can be seen, the PIX accepts this proposal (as it should), since these parameters match those configured on the PIX for this connection. It then goes on to check the same proposal again, just to reject it this time.

The completely non-obvious solution to this is to disable compression (which the PIX does not support) on the Checkpoint. Why the PIX is unable to even give me a hexdump of the offending parameter in the proposal I’ll probably never know.

Adding new dynamic library dependencies to an existing object

nospam@example.com (Ralf Ertzinger) — 2009-12-30T14:34:59Z

Due to some developing I needed a lighttpd with mod_magnet enabled. mod_magnet is a module which allows inserting of lua code into the request processing stream. This is a cool feature, and I was pleased to see that

lighttpd is on the standard Solaris install DVD
mod_magnet is provided

Of course there is this small problem:

2009-12-29 23:29:31: (plugin.c.165) dlopen() failed for: /usr/lighttpd/1.4/lib/mod_magnet.soi
ld.so.1: lighttpd: fatal: relocation error: file /usr/lighttpd/1.4/lib/mod_magnet.so:
symbol luaL_checklstring: referenced symbol not found

What this means is that there are unresolved symbols remaining in the code after the dymanic loader has done it’s work, which should not happen. Let’s look a the dynamic deps of the module.

$ ldd /usr/lighttpd/1.4/lib/mod_magnet.so
        libsendfile.so.1 =>      /lib/libsendfile.so.1
        libm.so.2 =>     /lib/libm.so.2
        libresolv.so.2 =>        /lib/libresolv.so.2
        libnsl.so.1 =>   /lib/libnsl.so.1
        libsocket.so.1 =>        /lib/libsocket.so.1
        libc.so.1 =>     /lib/libc.so.1
        libmd.so.1 =>    /lib/libmd.so.1
        libmp.so.2 =>    /lib/libmp.so.2
        libscf.so.1 =>   /lib/libscf.so.1
        libuutil.so.1 =>         /lib/libuutil.so.1
        libgen.so.1 =>   /lib/libgen.so.1
        libsmbios.so.1 =>        /usr/lib/libsmbios.so.1

Judging from the name of the missing symbol luaL_checklstring it ought to come from some kind of lua library. But the listing above does not show any missing libraries, lest of all a lua one.

So what happened?

Somehow (and I have no idea how) Sun managed to build a mod_magnet without linking it to the lua libraries at the end. Simply speaking, this is broken.

Fortunately there is a way to fix this. Sun provides a utility called elfedit(1) which allows the editing of ELF file headers (like shared libraries). The lua library which provides the missing symbols is called liblua.so (no version information). The type of record in an ELF header which denotes the dynamic libraries needed is called DT_NEEDED. elfedit(1) takes two parameters: the file to edit, and the file into which to write the modified version.

First show the existing DT_NEEDED records.

$ elfedit mod_magnet.so mod_magnet2.so
> dyn:value DT_NEEDED
     index  tag                value
       [0]  NEEDED            0x5f9               libsendfile.so.1
       [1]  NEEDED            0x60a               libm.so.2
       [2]  NEEDED            0x614               libresolv.so.2
       [3]  NEEDED            0x623               libnsl.so.1
       [4]  NEEDED            0x62f               libsocket.so.1
       [5]  NEEDED            0x5d3               libc.so.1

This is basically the same list as above, with liblua.so notably lacking. Now add a new entry:

> dyn:value -add -s DT_NEEDED liblua.so
     index  tag                value
      [34]  NEEDED            0x63e               liblua.so

Now look at the new table, and save it.

> dyn:value DT_NEEDED
     index  tag                value
       [0]  NEEDED            0x5f9               libsendfile.so.1
       [1]  NEEDED            0x60a               libm.so.2
       [2]  NEEDED            0x614               libresolv.so.2
       [3]  NEEDED            0x623               libnsl.so.1
       [4]  NEEDED            0x62f               libsocket.so.1
       [5]  NEEDED            0x5d3               libc.so.1
      [34]  NEEDED            0x63e               liblua.so
> :write
> :quit

Looking at the ldd(1) output, just to be sure.

$ ldd ./mod_magnet2.so
        libsendfile.so.1 =>      /lib/libsendfile.so.1
        libm.so.2 =>     /lib/libm.so.2
        libresolv.so.2 =>        /lib/libresolv.so.2
        libnsl.so.1 =>   /lib/libnsl.so.1
        libsocket.so.1 =>        /lib/libsocket.so.1
        libc.so.1 =>     /lib/libc.so.1
        liblua.so =>     /usr/lib/liblua.so
        libmd.so.1 =>    /lib/libmd.so.1
        libmp.so.2 =>    /lib/libmp.so.2
        libscf.so.1 =>   /lib/libscf.so.1
        libdl.so.1 =>    /lib/libdl.so.1
        libuutil.so.1 =>         /lib/libuutil.so.1
        libgen.so.1 =>   /lib/libgen.so.1
        libsmbios.so.1 =>        /usr/lib/libsmbios.so.1

Now the linker picks up the lua libraries. If the modified mod_magnet.so is now put back into /usr/lighttpd/1.4/lib, lighttpd will start and mod_magnet will work.

Now, this wasn’t so hard, was it?

Changing the rpool disk in Solaris

nospam@example.com (Ralf Ertzinger) — 2009-12-25T15:01:53Z

Ever since my storage system was built there was one thing that annoyed me. The 2.5” hard disk drive that houses the operating system itself was lifted from an old notebook and had the annoying property of parking it’s heads after five seconds of inactivity. Since ZFS writes to the disk quite often and regularily this led to a constant cycle of parking and unparking. This was certainly not helping the disks life span, it made an annoying noise and it caused small system hangs whenever the disk had to unpark it’s heads to read some data.

Under Linux one could use hdparm to instruct the disk to not park it’s heads, but unfortunately a program mimicking this functionality seems to be absent under Solaris. Thus the plan to replace the disk with a different one which had a more sensible apporoach to head parking.

This turned out to be an interesting endeavour.

The general problem of replacing the disk holding the rpool is common enough that the excellent ZFS troubleshooting guide has a section on doing this. The general plan of action is as follows:

Insert the replacement disk into an available slot
Create a partition spanning the whole disk
Create boot and data slices
Attach the new disk as a mirror to the rpool
Wait for the resilver to finish
Install grub on the new disk
Try to boot from the new disk
Detach the old disk from the rpool
Remove the old disk

This is all very sensible, and it all works as advertised. In my case there is, however, a last step not on the list above:

Put the new disk on the controller the old disk was attached to

The reason for that is that the case I used only has one internal 2.5” hard disk drive slot. The new disk was prepared using an external USB-IDE converter module. This worked just fine, the BIOS is even able to boot from the USB disk. As long as the new disk remained attached to the USB converter everything was fine, even after the old (internal) disk was removed from the rpool. But putting the new disk into the case caused Solaris to roll over and die early in the boot process due to not finding it’s rpool disk. The error message indicated that it was trying to read the pool from the external USB device (which no longer existed at this point).

Investigation (and much swearing) turned up that this information was passed by GRUB to the Solaris kernel.

Solaris uses a patched GRUB version which understands ZFS and has some string replacement magic built in. Every (non failsafe) boot entry contains a line similar to this:

kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS

$ZFS-BOOTFS is replaced by GRUB with the following information:

The name of the root pool (usually rpool) and the number of the dataset that contains the root file system (there may be several BEs)
The device path of the disk this GRUB instance was read from

The actual command line that is executed by GRUB thus looks something like this:

kernel /platform/i86pc/kernel/$ISADIR/unix -B zfs-bootfs=rpool/328 \
bootpath="/pci@0,0/pci8086,2942@1c,1/pci-ide@0/ide@0/cmdk@0,0:a"

The interesting part here is the bootpath parameter. This is the device that Solaris will try to mount the rpool from. Even if the rpool consists of several mirror devices, only one is used in the initial boot process. Where does GRUB get the device path from? It’s read from the rpool header, from the disk GRUB was loaded from. Every ZFS pool disk contains the device path it was last found under. This usually does not matter much, a RAIDZ will still mount if you swap the disks around when the machine is off, but the boot process relies on the rpool disks not wandering around. My new disk still had the USB device path embedded, which GRUB read and passed to the kernel, which then failed to find the disk.

Fixing this turns out to be easy: boot into failsafe mode with the new disk on it’s final connector. This will search for rpools and BEs on the system and offer to mount one of them. Pick the right one, reboot. This is enough to get the current (and correct) device path embedded into the rpool. The next (non failsafe) boot will thus pick up the correct device path and allow the boot to continue.

The morale of an afternoon thus spent in the innards of the Solaris boot process is thus: do not swap your rpool disk around.

Creating a write only directory with SAMBA and ZFS

nospam@example.com (Ralf Ertzinger) — 2009-12-12T17:57:28Z

One of the intended uses of my OpenSolaris storage server was to serve as a SAMBA accessible data store. Part of that role was the wish to have an incoming directory modeled after similar directories found on many FTP servers. In detail this meant a share with the following properties:

Readable for everyone (including unauthenticated users, i.e. guests)
Everyone can create new files and directories on the share
Only certain users can delete files and directories from the share

So everyone can add files to the share, but removing them requires special privileges.

It turns out that this is impossible to do with normal UNIX file system permissions, as for UNIX creating a file (which is a write operation on a directory) is much the same as deleting one (which is a write operation on a directory).

Fortunately OpenSolaris supports a much more powerful file operation permission language in the form of NFSv4 permissions.

It has been said that the NFSv4 permission system has been modeled after a smudged copy of the Windows NTFS permission system, and there is certainly merit to that claim, which is not a bad thing. The NTFS permission system is much more expressive than the standard UNIX system, as it has more actions (besides writing, reading and executing it also knows about deleting, for example), can support a large number of principals with different permissions and can actively deny an action (which is different from “not allowing”).

NFSv4 permissions

The NFSv4 system knows about the following actions:

Action	Description for files	Description for directories
read data	Read file contents	List directory contents
write data	Write file contents (anywhere in the file)	Create new files
execute	Execute file	Change into directory
append	Append data to file	Create new directories
delete	Delete the file	–
delete child	–	Delete a file in the directory
read/write attributes	Read/write basic attributes	(same as file)
read/write xattrs	Read/write extended attributes	(same as file)
read/write ACL	Read/write ACLs	(same as file)
change owner	Change the owner	(same as file)
sync	Use syncronous file access	–

NFSv4 also contains a mechanism to specify actions that apply to a file or directory, and actions that are inherited to child objects of a directory (i.e. files or subdirectories). This allows very fine grained control of file system access.

Of special interest here are the bits about writing, appending and deleting files and folders.

The ACLs are maintained in a list of entries, each entry mapping a username/action pair to a verdict (allow/deny). Each access is matched against each entry in
turn, and the verdict is taken from the first entry to match. So the order of entries is important.

Solaris’ ls has two extensions to list those ACLs: -v for a verbose listing and -V for a concise listing. The format used by -V can be passed to chmod to change ACLs.

The permissions corresponding to the list of requirements stated above are as follows (/tank/share/incoming is the directory associated with the incoming share in smb.conf):

# ls -lVd /tank/share/incoming
drwxrwxrwx+  5 root     root           6 Dec 12 16:49 /tank/share/incoming
               user:sun:-w--dD--------:fdi----:allow
               user:sun:-w--dD--------:-------:allow
              everyone@:-w--dD--------:f-i----:deny
              everyone@:----dD--------:-di----:deny
              everyone@:----dD--------:-------:deny
              everyone@:rwxp--a-R-c--s:-di----:allow
              everyone@:r-xp--a-R-c--s:f-i----:allow
              everyone@:rwxp--a-R-c--s:-------:allow
#

There are two kinds of entries in this list. Those with an i in the second part of the action list and those without. The entries with an i are so called “inherit only” entries. They do not apply to the file or directory they are associated with, but are only inherited to new child entries. The other entries apply to the file/directory they are associated with.

This list can be read in three blocks:

The first block consists of the first two lines. The first line specifies that the right to delete files (d), delete child entries (D) and create new files/write file content (w) for the user named sun is inherited to new files and directories (fdi). This makes sure that this user can always remove files and directories, and overwrite existing file content in newly created files. The second line applies the same rights to the incoming directory itself.

The second block consists of lines 3 to 5 and contains only deny statements. They apply to everyone@, which means exactly what it says on the box. Lines 3 and 4 again deal with rights that are to be inherited to child objects, but the rights inherited to files and directories are different this time. Files inherit a deny to write anywhere in the file (w) and file deletion (dD). Directories just inherit the deletion part, otherwise new files could not be created in subdirectories (which needs the w right). The incoming directory itself gets the “no deletion” treatment as well.

The third block consists of the last three lines and restores some rights to non privileged users. Directories inherit the right to be read (r), changed though (x</code), new files and subdirectories can be created (<code>rp</code), and attributes of all sorts can be read (<code>aRc). We also allow synchronous file access (s). Files are much the same, except that the write anywhere right is missing. Not that it would matter much if that were allowed here, since it has been explicitly denied earlier. Note that the right to append to a file (p) is explicity allowed. The rights for the incoming directory itself (last line) again match those inherited to subdirectories.

Let’s see if that works out.

$ id
uid=60003(smbnobody) gid=60003(smbnobody)
$ touch /tank/share/incoming/foo
$ ls -V /tank/share/incoming/foo
-r-xr-xr-x+  1 smbnobody   smbnobody         0 Dec 12 18:33 /tank/share/incoming/foo
               user:sun:-w--dD--------:------I:allow
              everyone@:-w--dD--------:------I:deny
              everyone@:r-xp--a-R-c--s:------I:allow

The unprivileged user smbnobody (SMB guest access is mapped to this uid) can create a new file in the incoming directory, and the file inherits the rights mentioned above (I signifies an inherited right).

$ cat /etc/passwd > /tank/share/incoming/foo
bash: /tank/share/incoming/foo: Permission denied
$ cat /etc/passwd >> /tank/share/incoming/foo
$

The user cannot overwrite the file (even though it is empty), but he can append to it.

$ rm /tank/share/incoming/foo
rm: /tank/share/incoming/foo: override protection 555 (yes/no)? y
rm: /tank/share/incoming/foo not removed: Permission denied
$

Deletion is also denied. Good.

$ id
uid=500(sun) gid=100(users)
$ cat /etc/passwd > /tank/share/incoming/foo
$ rm /tank/share/incoming/foo
$

However, the privileged user sun can overwrite and delete the file.

Samba configuration

Samba also needs configuration to recognize and use the extended parmission system. The following is an excerpt from smb.conf, describing the incoming share:

[incoming]
        path = /tank/share/incoming
        writable = yes
        guest ok = yes
        browseable = yes
        public = yes
        acl check permissions = False
        ea support = yes
        store dos attributes = no
        map readonly = no
        map archive = no
        map system = no
        map hidden = no
        vfs objects = zfsacl
        nfs4: mode = simple
        nfs4: acedup = dontcare

This configures Samba to use extended ACLs using the ZFS (NFSv4) permission system.

Access problems with Apache server-status

nospam@example.com (Ralf Ertzinger) — 2009-12-02T13:17:15Z

Since I have twice now spent considerable time on debugging this:

If you have configured an Apache server-status handler, but retrieving the URL bound to this handler results in access denied even though there are no access restrictions configured on the container (bad idea, by the way), or the connecting IP is allowed access, make sure that the webserver can access it’s document root.

This may seem obvious, but if the Apache is configured as a reverse proxy there may not be any files in the document root, because all content is created by the backend servers (or virtual handlers, like server-status). Nonetheless the Apache server must be able to change into the document root, or the virtual handlers will fail (reverse proxy access will work, however).

Resetting SATA devices under Linux

nospam@example.com (Ralf Ertzinger) — 2009-11-18T12:36:49Z

Note: this was tested only on SATA attached optical drives, not on hard disks. Removing a hard disk with mounted partitions on it (directly or indirectly) is probably not a very smart idea.

A device name of /dev/sr0 is assumed.

Find out which controller the device is attached to (we’ll need this later):

# readlink /sys/block/sr0
../devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0

The interesting part if the answer is host1, which identifies the controller.

Disconnect the device

# echo 1 > /sys/block/sr0/device/delete

This will remove the device from the bus (logically). Look in dmesg for confirmation.

Rescan the controller

# echo "- - -" > /sys/class/scsi_host/host1/scan

host1 is the identifier from step one. Again, dmesg should show the device being rediscovered.

Manual IMAP

nospam@example.com (Ralf Ertzinger) — 2009-11-05T19:45:25Z

From time to time I am in the unfortunate situation of having to manually communicate with an IMAP server (in other words: reading mail via telnet).

Due to the nature of IMAP this is not remotely as simple as reading mail via telnet using the POP3 protocol, however, as IMAP is a very rich and powerful protocol with a quirky syntax.

As I tend to forget the commands for the most important tasks it might be a good idea to write them down.

Some definitions:

IMAP handles messages. Messages live in folders, which can have subfolders. Folders are separated by separators. Multiple groups of folders can exist, those groups are called namespaces. At least one namespace always exists. Within every folder each message has two identifiers (both are positive integers). The first (the sequence number) is valid only as long as the current folder is selected (or open, in other words), and ranges from 1 to N, N being the number of messages in the folder. The second (the UID) does not change from one selection to the next, and usually not between connects. Ideally, the UID for a message never changes once it has been assigned. The IMAP server is free to assign a new UID to a message, but it must tell the client if it does so.

Each request from a client starts with a tag, which is a group of characters consisting of letters, numbers and the dot (”.”). The server reply consists of at least one line, but may consist of several. In the latter case, each line starts with an asterisk (*), except for the last, which starts with the tag chosen by the client. This signals the completion of the command. If the server reply is one lined, only the line starting with the client tag is sent. The client may reuse tags if it wishes. The protocol is not synchronous, the client can send several requests without waiting for the server to complete the preceding command.

Unless the client or the server indicate otherwise the default character set for IMAP is UTF7 (which, as long as you keep to the first 128 characters of the ASCII character set, is exactly the same as ASCII or UTF8).

Requests and replies consist of a space separated list of keywords and strings. Strings can be written in two forms, quoted and literal. Quoted strings can consist of any 7-bit-characters, except CR and LF, enclosed by ". If the quoted string contains the character " itself it
must be quoted as \".

Literal strings start with the number of characters in the string, enclosed by curly braces, and a CRLF. The string characters then follow.

That ought to be enough to make sense of the following:

Login

Assuming the server supports plain text logins (indicated by AUTH=LOGIN in the server greeting:

$ telnet mailserver 143
[...]
* OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID AUTH=LOGIN AUTH=PLAIN AUTH=CRAM-MD5 SASL-IR]
mailserver Cyrus IMAP4 v2.3.7-Invoca-RPM-2.3.7-7.el5_4.3 server ready
foo login user password
foo OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID LOGINDISABLED ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS
NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ
THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE IDLE LISTEXT
LIST-SUBSCRIBED X-NETSCAPE URLAUTH] User logged in

In this example the login user name was user and the password was password. The tag chosen by the client (i.e. the person using telnet) was foo, which was echoed by the server in the login response. From now on the tag used will be the dot (”.”), unless specified otherwise.

Namespaces

Several groups of folders can exists, these groups are called namespaces. One use is the implementation of shared folders such that the private folders of a user live in one namespace, and the shared folders in another. To list the available namespaces:

. NAMESPACE
* NAMESPACE (("INBOX." ".")) (("user." ".")) (("" "."))
. OK Completed

This user has access to three namespaces: INBOX, user and a namespace without a name. The latter is the default name space. The dot (”.”) after the name is the separator used in this namespace.

Listing folders

Listing folders within a namespace requires the namespace to be listed, and a pattern describing the required names. The pattern supports wildcards, especially “*” (list subfolders, recursively) and “%” (list subfolders, not recursively).

. LIST "" "INBOX.%"
* LIST (\HasNoChildren) "." "INBOX.Folder1"
* LIST (\HasNoChildren) "." "INBOX.Folder2"
* LIST (\HasChildren) "." "INBOX.Folder3"
. OK Completed

This INBOX folder has three subfolders: Folder1 and Folder2, both of which have no subfolders, as indicated by the \HasNoChildren flag, and one (Folder3) which has. Because of the “%” wildcard the subfolders of Folder3 are not shown in this listing.

In general, it is usually not a good idea to list folders using “*”. This may return a list containing potentially thousands of folders (think of systems redistributing Usenet news via IMAP). Instead use “%” to descend the folders considered interesting.

Selecting folders

In order to read messages the folder containing those must be activated first. This requires the full folder name as returned by LIST.

. SELECT "INBOX"
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen NonJunk Junk $NotJunk $Junk $Forwarded)
* OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen NonJunk Junk $NotJunk $Junk $Forwarded \*)]  
* 5966 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1136990532]
* OK [UIDNEXT 12498]
* OK [NOMODSEQ] Sorry, modsequences have not been enabled on this mailbox
. OK [READ-WRITE] Completed

This folder contains 5966 messages (5966 EXISTS), zero of which are unread (0 RECENT). The UIDVALIDITY parameter is an integer describing the validity of the UID numbers assigned to the messages. As long as this number does not change the mapping from message to UID has not changed.

Finding messages

Unlike POP3 IMAP servers actually try to parse the messages stored in the folders in order to extract some information from the headers, such as sender address, recipient address, messageid and general message structure (such as attachments). The reason and upshot of this is that the server can search for messages having certain properties (for example, all messages by a certain sender) without having the client download all messages and doing the search itself. There are two search commands (SEARCH and UID SEARCH) which differ in the results they return. The first command returns sequence numbers, the second returns message UIDs.

Multiple search conditions can be used in one search request, those are ANDed (i.e., all have to be satisfied).

A small table of possible search conditions:

Query	Looking for	Example
`FROM "<mailaddress>"`	Mail from that sender	`FROM "user@example.org"`
`TO "<mailaddress>"`	Mail to that recipient	`TO "user@example.org"`
`SINCE <date>`	Mail received after this date	`SINCE 1-Nov-2009`
`BEFORE <date>`	Mail received before this date	`BEFORE 1-Nov-2009`
`DELETED`	Mails marked as deleted	`DELETED`
`SUBJECT <string>`	Mails containing string in the subject	`SUBJECT "Proposal"`
`BODY <string>`	Mails containing string in the body	`BODY "Hello Greg"`
`NOT <key>`	Mails which do not match the key	`NOT FROM "user@example.org"`
`OR <key1> <key2>`	Mails which match either of key1 or key2	`OR FROM "user@example.org" FROM "user2@example.org"`

There are quite a bit more of these, RfC 2060 lists all possible options. But the ones above are probably the most commonly used.

Please be aware that the full text searches (TEXT and BODY) can be probibitively expensive if the server does not keep a full text search database of the messages. Getting an answer to such a query may take a very long time.

. SEARCH FROM "user@example.org" BEFORE 1-Nov-2009
* SEARCH 5 10 456
. OK Completed

Fetching messages

Now that SEARCH has turned up some messages it might be a good idea to take a look at the contents. The FETCH command takes a list of sequence numbers or UIDs (as with SEARCH there are two variants, FETCH and UID FETCH) and a list of the information we are interested in. The most commonly used parts are:

Part name	Part description
`BODY[TEXT]`	Just the mail body, without the headers
`BODY[HEADER]`	The mail headers
`BODY[HEADER.FIELDS (<list>)]`	Just the header fields indicated in list
`BODY[]`	The entire mail text, header and body
`BODY.PEEK`	Works as `BODY` does, but does not mark the mail as seen
`FLAGS`	Flags set for the message
`UID`	The UID of the message

As above, RfC 2060 has all the gory details.

. FETCH 5 (FLAGS BODY[HEADER.FIELDS (To)])
* 5 FETCH (FLAGS (\Seen) BODY[HEADER.FIELDS (To)] {24}
To: user@example.com
)
. OK Completed

Deleting messages

Deleting messages in IMAP is a bit tricky, as there is no explicit delete command. Instead, a flag is set on the message marking it as deleted. This, by itself, does nothing to get the message removed. Just when a special command is called all messages in the current folder marked as to be deleted are removed¹.

. UID SEARCH ALL
* 1 EXISTS
* 1 RECENT
* SEARCH 1814
. OK Completed
. UID STORE 1814 +FLAGS (\Deleted)
* 1 FETCH (FLAGS (\Recent \Deleted \Seen) UID 1814)
. OK Completed
. EXPUNGE
* 1 EXPUNGE
* 0 EXISTS
* 0 RECENT
. OK Completed
. UID SEARCH ALL
* SEARCH
. OK Completed

The above is executed in a folder containing just a single message (see the result of the UID SEARCH ALL). The flag \Deleted is then added to flag list of the message (UID STORE 1814 +FLAGS (\Deleted)). The STORE command returns the new flag list. The EXPUNGE command then removes the message.

Leaving IMAP

When finished with the session the last thing to do is to leave:

. logout
Connection closed by foreign host
$

¹ The manual page for the rather excellent perl module Mail::IMAPClient had the following to say about this:

In case you’re curious, expunging a folder deletes the messages that you thought were already deleted via “delete_message” but really weren’t, which means you have to use a method that doesn’t exist to delete messages that you thought didn’t exist. (Seriously, I’m not making any of this stuff up.)

Unfortunately this gem has disappeared from newer versions of the manual page.

SSL cipher settings

nospam@example.com (Ralf Ertzinger) — 2009-09-13T14:45:35Z

The Problem

Securing network services with SSL is, in general, a good idea, if you can spare the CPU cycles. Especially personal data should always be protected while in transit via the network. But it may not be enough to simply enable SSL in the service (be it Apache, Lighttpd, Cyrus IMAPD or something else) to get a reasonably secure connection.

SSL is a cover phrase for a wide collection of protocols and crypto algorithms. There are at least three protocol suites in use (SSLv2, SSLv3 and TLSv1), which between them support tens of different crypto algorithms with different strengths. Not all of those are still suitable for serious use today.

A list of the ciphers supported by the popular OpenSSL library, which is used by many projects to handle SSL, can be obtained with the following command:

$ openssl ciphers -v 'ALL:COMPLEMENTOFALL'
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
...
$

On my notebook (running Fedora 11) this produces a list of 62 ciphers. The number of ciphers supported changes with the version of OpenSSL, so other
systems may display a different list.

During an SSL handshake between a client and a server the cipher to use is negotiated between the two machines. In practical terms this means that the client send list of ciphers it is able and willing to use to the server, the server compares this list with it’s own list of supported ciphers and, if a cipher supported by both sides is found returns it’s choice to the client.

Defaults

Unless something else is configured, a server using OpenSSL uses the “DEFAULT” group of ciphers. The content of this group can also change between versions of OpenSSL. The value for the installed version can be queried:

$ openssl ciphers -v 'DEFAULT'
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
...
$

This list is shorter than the list of all ciphers above, containing 44 ciphers on my notebook. This list is not entirely nonsensical. It does not contain ciphers without encryption (yes, that is a valid mode of operation for SSL), it does not contain ciphers without authentication (which would allow for Man-in-the-middle attacks). It does, however, contain ciphers whose strength in this day and age must be questioned. These include the so called “export” ciphers.

These ciphers stem from a time when it was illegal to export software from the United States which supported strong encryption. So software supporting encryption (for example web browsers, like the venerable Netscape Nagivator) destined for export only supported watered down versions of the strong encryption variants, mostly by supporting shorter keys. Fortunately it is no longer illegal to export strong crypto from the United States, and hasn’t been for years, but for compatibility reasons OpenSSL is still willing to negotiate these weak ciphers with a client.

Another weak candidate is the DES algorithm. It was made a standard in 1976 (which is an eternity ago in IT terms). Although it was never cryptographically broken, it’s key length of 56 bits made it increasingly more vulnerable to brute force attacks as faster CPUs became available. Since the Electronic Frontier Foundation demonstrated a custom-built DES cracker in 1998, built for $250.000 and able to brute-force a DES key in under two days, DES has been effectively dead. But, for compatibility reasons, OpenSSL is, by default, willing to negotiate DES as a cipher.

OpenSSL can be told which ciphers to offer in an SSL negotiation, and thankfully most programs using OpenSSL offer configuration statements so the admin can change the default settings.

Selections

Which ciphers should be used then? Let’s start with all the ciphers supported by the SSLv3/TLSv1 cipher suite (which every program offering SSL should support, the use of SSLv2 is strongly discouraged due to vulnerabilities). And we only want ciphers which offer high security (which in OpenSSL terms means more than 128 bits key length, plus some ciphers with 128 bit keys). To be on the safe side we also explicitly disable SSLv2 ciphers, so they cannot be reintroduced later:

$ openssl ciphers -v 'TLSv1+HIGH:!SSLv2'
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
...
$

25 ciphers match this list, but it also contains ciphers without authentication. These have to go, along with all ciphers without encryption (there should not be any, but better save than sorry):

$ openssl ciphers -v 'TLSv1+HIGH:!SSLv2:!aNULL:!eNULL'
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
...
$

20 remain. It’s my personal preference to disable ciphers based on triple-DES (3DES), so these are removed, too. There is no technical reason for this, 3DES is still considered secure.

Finally, the remaining ciphers are sorted by strength, the most secure first, which will make OpenSSL prefer those.

$ openssl ciphers -v 'TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!3DES:@STRENGTH'
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
...

On my notebook 14 ciphers remain. For comparison, on my web server (running CentOS 5) this selection only produces 6 ciphers, due to an older version of OpenSSL.

There is, however, two problem with this list. First, it does no longer contain the export or simple DES ciphers (which was kind of the point). This means that SSL services secured with this selection are no longer available to SSL client which only support export grade ciphers. This is a good thing, as these clients are insecure and need to be replaced with something more recent. Depending on the details of the service this option may not be available, though. Please check if these old ciphers must be supprted further before turning them off.

The second problem is Windows. In detail, Windows versions before and including Windows XP. The crypto libraries shipped with these versions do not support newer crypto algorithms (like AES), so there is no overlap between the set of algorithms supported by the server and those supported by the client. These crypto libraries are primarily used by Internet Explorer, Outlook and Outlook Express, so these programs on Windows XP and earlier will not be able to negotiate an SSL connection to a web or mail server. Other web browsers and mail clients (like Firefox and Thunderbird) usually ship with their own crypto libraries which do support modern algorithms, and are not
affected. The system crypto libraries in Windows Vista and Windows 7 are also not affected.

If support for older Windows versions cannot be dropped (likely), the cipher list needs to be extended by some RC4 ciphers (which Windows does support):

$ openssl ciphers -v 'TLSv1+HIGH:!SSLv2:RC4+MEDIUM:!aNULL:!eNULL:!3DES:@STRENGTH'
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
...
$

This brings the number of ciphers up to 19, the new RC4 ciphers are added at the end of the sorted list.

Configuration

Now that the cipher list is complete the various services that use SSL need to be configured to use it. Instructions how to do this can be found in the documentation, examples for some services are below.

Exim

Add the following line to the global (first) configuration section and restart Exim:

tls_require_ciphers = TLSv1+HIGH : !SSLv2 : RC4+MEDIUM : !aNULL : !eNULL : !3DES : @STRENGTH

Lighttpd

Add the following line to the configuration section containing ssl.engine = "enable" and restart Lighttpd:

ssl.cipher-list = "TLSv1+HIGH !SSLv2 RC4+MEDIUM !aNULL !eNULL !3DES @STRENGTH"

Cyrus IMAPD

Add the following line in imapd.conf and restart Cyrus:

tls_cipher_list: TLSv1+HIGH:!SSLv2:RC4+MEDIUM:!aNULL:!eNULL:!3DES:@STRENGTH

Testing

In order to test the new settings, a connection attempt using an excluded cipher can be made (which should fail, of course):

$ openssl s_client -host www.skytale.net -port 443 -cipher 3DES
CONNECTED(00000003)
140209911707464:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:672:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 58 bytes
---
New, (NONE), Cipher is (NONE)
Compression: NONE
Expansion: NONE
---

A successful attempt (letting openssl select the best cipher) negotiates AES with a 256 bit key:

$ openssl s_client -host www.skytale.net -port 443
CONNECTED(00000003)
...
---
SSL handshake has read 1281 bytes and written 309 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol  : TLSv1
Cipher    : AES256-SHA
Session-ID: --removed--
Session-ID-ctx:
Master-Key: --removed--
Key-Arg   : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Compression: 1 (zlib compression)
Start Time: 1252852959
Timeout   : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---

Running RivaTuner without Administrator rights

nospam@example.com (Ralf Ertzinger) — 2009-09-03T19:59:36Z

RivaTuner is a tweaking program for Windows used to change some more obscure parameters of modern GPUs. It’s main uses are overclocking and monitoring, but it’s feature list is truly impressive. I mainly use it to change the fan speed settings on the GTX 260 in my gaming rig (the default profile is not aggressive enough for my taste, letting the GPU temperature run up to 85 degrees before the fan starts to kick in in ernest).

One problem I always had with RivaTuner is that it requires Administrator privileges to run. It needs those to load a device driver that is then used to communicate (and manipulate) the GPU driver and some parts of the graphic card. Since my normal user account does not have administrative privileges I had to use the “Run As” feature to start RivaTuner to allow it to set my fan parameters.

It turns out this is not really necessary, and that there is a way to run the RivaTuner frontend as a normal user. Here’s how.

WARNING

The following instructions involve editing sensitive parts of the Windows registry. Getting this wrong may render your Windows installation unbootable or harm your system in other ways. If you are not comfortable with the registry editor do not attempt to do this.

Instructions

Install RivaTuner (well, duh).
Start RivaTuner at least once (as an Administrator)
Log in as a user with administrative rights
Start the registry editor
Navigate to the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RivaTuner32

Change the key Start to 1
Reboot

What this does is to instruct Windows to load the RivaTuner device driver during system startup, so it is already loaded when a user logs in. Seeing this, RivaTuner will not attempt to load the driver again, but connect to the driver as a normal user (which works).

Advantages

With this change RivaTuner can be run as a normal user

Disadvantages

The RivaTuner device driver will always be loaded, even when RivaTuner will not be used. This may lead to problems with other drivers, and disabling the device driver again requires another go at the registry.

Tracing errors through the code

nospam@example.com (Ralf Ertzinger) — 2009-05-29T14:50:12Z

Open source is a great thing. This becomes especially obvious if one is confronted with a program that refuses to work, and furthermore refuses to yield any kind of helpful error message. Reading the source may be the only way to determine what is actually going on.

Sadly I’ve been doing rather a lot of that lately, This post shall serve as an example how to navigate the Open Solaris source code in search of an answer.

The problem

This specific problem arose during my experiments to create a small Solaris installation for use in an embedded system (small in this context means around 60MB used disk space). More details on this later.

The system has a cfgadm(1M) binary, but it does not work:

# cfgadm
cfgadm: Library error: Device library initialize failed: Facility is not active

As error messages go this only marginally better that “Failed”, but not by much. Telling the user which exact facility is not active would have been helpful.

But at least there are some search friendly strings in there that may help to determine the source code responsible for this message.

The source

One thing the classical UNIX source approach of “all the source in one tree” has going for it is that it makes searching in the source relatively easy. The Open Solaris web site has build a search engine above the source tree which automatically cross-references symbols in the code and has some other nice features. The entry page to the search engine is here.

Searching for “Facility is not active” (note the quotes) yields just a handful of hits. One of those (in /onnv/onnv-gate/usr/src/uts/common/sys/errno.h) hints that there is a system error (and corresponding symbol) called ENOTACTIVE which belongs to this error message.

Running cfgadm under truss(1) confirms this:

# truss cfgadm
execve("/usr/sbin/cfgadm", 0x08047E24, 0x08047E2C)  argc = 1
[...]
sysconfig(_CONFIG_PAGESIZE)                     = 4096
open("/devices/pseudo/devinfo@0:devinfo", O_RDONLY) = 3
ioctl(3, DINFOIDENT, 0x00000000)                = 57311
ioctl(3, 0x10DF00, 0x08047460)                  Err#73 ENOTACTIVE
close(3)                                        = 0
[...]

Things go kind of downhill from there. So some code opens the devinfo device, runs two IOCTLs on in and the second one fails. Furthermore, truss only knows the first IOCTL by name, not the actually failing one.

Searching for the first name turns up /onnv/onnv-gate/usr/src/uts/common/sys/devinfo_impl.h:

#define DINFOIDENT (DIIOC | 0x82) /* identify the driver */

Looking around in this file some more yields two other definitions:

#define  DIIOC       (0xdf<<8)
[...]
#define DINFOCACHE  (DIIOC | 0x100000) /* use cached data  */

So the second IOCTL is actually called DINFOCACHE. Tracing IOCTLs through the code is, unfortunately, a bit tricky, because the routine that handles the IOCTL depends on the passed file descriptor (the first parameter to the IOCTL call). The file associated with the IOCTL in this case belongs to the file /devices/pseudo/devinfo@0:devinfo (see the open call directly above the two IOCTLs).

But since the IOCTL handling code most likely contains the symbol DINFOCACHE as well (that’s what constants are for, after all) searching for the name will turn up the correct file, possibly buried among others.

Armed this knowledge the search results for DINFOCACHE can be narrowed down to one likely candidate: /onnv/onnv-gate/usr/src/uts/common/io/devinfo.c. This file belongs to the kernel code (it lives in usr/src/uts), and the name fits the name of the device opened above.

DINFOCACHE appears twice in a function called di_ioctl, which sounds good. Following the code flow through this function (DINFOCACHE is passed in the cmd parameter), the first relevant code part reads as follows:

if ((st->command & DINFOCACHE) && !cache_args_valid(st, &error)) {
        di_freemem(st);
        (void) di_setstate(st, IOC_IDLE);
        return (error);
}

(By the time execution reaches this code the cmd variable has been copied to st->command, more or less). cache_valid_args, among other things, does the following:

if (!modrootloaded || !i_ddi_io_initialized()) {
       CACHE_DEBUG((DI_ERR,
       "cache lookup failure: I/O subsystem not inited"));
       *error = ENOTACTIVE;
       return (0);
}

That looks pretty promising, as it sets the right error code if the condition holds. modrootloadied is a kernel symbol, so mdb(1) can be used to inspect this value in a running kernel.

# mdb -k
Loading modules: [ unix genunix specfs mac cpu.generic uppc pcplusmp scsi_vhci
ufs sockfs ip hook neti sctp arp usba uhci sd lofs logindmux ptm random crypto
zfs ipc ]
> modrootloaded/X
modrootloaded:
modrootloaded:  1

That’s not the culprit. i_ddi_io_initialized() basically returns the value of sysevent_daemon_init, so what about that?

# mdb -k
Loading modules: [ unix genunix specfs mac cpu.generic uppc pcplusmp scsi_vhci
ufs sockfs ip hook neti sctp arp usba uhci sd lofs logindmux ptm random crypto
zfs ipc ]
> modrootloaded/X
modrootloaded:
modrootloaded:  1
> sysevent_daemon_init/X
sysevent_daemon_init:
sysevent_daemon_init:           0

Bingo. From the name of the variable the probable name of the not running facility (remember the original error message?) can be deduced: svc:/system/sysevent:default, which, indeed, is not running on the minimal system. Starting it makes cfgadm work.

That wasn’t so hard, now was it?

Login via serial console

nospam@example.com (Ralf Ertzinger) — 2009-03-28T13:35:04Z

Getting a serial console (for login purposes) on OpenSolaris seems to be a two-sided operation. Either it is insultingly simple, or a convoluted mess. The two options I’ve discovered so far, in order of difficulty.

The easy way

By default Solaris starts a login console on /dev/console, whatever that happens to be at a given moment. Passing -B console=ttya on the kernel command line (via GRUB) will change the primary system console to the first serial port in the system (what Linux calls ttyS0), automagically creating a login prompt there when the system has finished booting.

The hard way

Assuming that for whatever reason /dev/console is not supposed to be on ttya, things move into twilight territory.

Historically a getty was spawned from inittab, and that was it. Sometime in the past Solaris changed this behaviour to a more complicated scheme.

Login processes are handled by the Service Access Controller (sac(1M)), which handles port monitors. Port monitors bind services to ports, for example ttymon(1M), which handles baud rates and spawning the login process. I have to admin that I have not completely understood the architectural design behind all this. As far as I was able to deduce from the manual pages for pmadm(1M), ttyadm(1M) and sacadm(1M) the default setting ought to produce a login prompt on the first two serial ports. Alas, it does not.

It looks like ttymons are no longer handled by SAC, no matter what the documentation says, but are instead spawned directly by SMF, specifically by svc:/system/console-login. This SVC has several instances that handle the login prompts on the virtual consoles for VGA. Adding an instance for ttya makes a login prompt appear on the first serial port. The following creates and activates this instance:

# svccfg -f - <<EOF
select svc:/system/console-login
add ttya
select svc:/system/console-login:ttya
addpg ttymon application
setprop ttymon/device = astring: /dev/term/a
setprop ttymon/label = astring: console
setprop ttymon/modules = astring: ldterm,ttcompat
setprop ttymon/nohangup = boolean: true
setprop ttymon/prompt = astring: "`uname -n` ttya login:"
addpg general framework
setprop general/enabled = boolean: true
EOF
#

Please note that due to the default settings in /etc/security/login root logins are not possible on this terminal.

Now I am waiting for one of two things to happen:

Someone telling me that I’ve got it all wrong and that there’s a better way to do things
Someone telling me that this is the official way to do it and that it is documented somwhere.

I’m not holding my breath on either one.

iSCSI: Opensolaris target, Fedora initiator, with CHAP

nospam@example.com (Ralf Ertzinger) — 2009-03-24T00:16:10Z

For some reason or another finding instructions on how to actually configure iSCSI for a rather simple and common use case (one target on Solaris, one initiator on Fedora, CHAP authentication) seems to be pretty hard.

Either my google-fu is seriously broken today, or everyone except for me considers this to be so easy and obvious that it does not warrant documentation. Which, having done this for the last three hours, I seriously doubt. The Solaris side is actually documented quite well (I primarily used this blog entry by alasdair), the Linux side is lacking. It does not help matters that both sides use identically named tools that work in completely different ways.

So, the deal is as follows:

One OpenSolaris system, acting as iSCSI target (that is the system presenting the storage space).

One Fedora Linux system, acting as iSCSI initiator (that is the system that wants to use the storage space)

Create 100GB storage space on the target and let the initiator connect to this storage space and create a filesystem on in. The connection has to be authenticated one way (the initiator presents credentials to the target).

The Solaris side

The system is running Nevada, the configuration here was done with build snv_110.

First, the iSCSI target software needs to be installed and enabled:

# gkp.pl -d /mnt/Solaris_11/Product SUNWiscsitgtu
# svcadm enable iscsitgt:default
#

The backing store for the iSCSI volumes shall be provided by ZFS:

# zfs create -o canmount=off tank/iscsi
# zfs create -V 100G -o shareiscsi=on tank/iscsi/vol001
# iscsitadm list target -v
Target: tank/iscsi/vol001
    iSCSI Name: iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8
    Alias: tank/iscsi/vol001
[...]
#

The iSCSI Name will be different for each created volume. Per default this target will be available via all interfaces and IPs of the machine. Since this is not what I want in this special case the target is bound to a fixed IP by a construct called a Target Port Group Tag. The TPGT used here has the number 1.

# iscsitadm create tpgt 1
# iscsitadm modify tpgt -i 212.51.12.90 1
# iscsitadm list tpgt -v 1
TPGT: 1
    IP Address: 212.51.12.90
# iscsitadm modify target -p 1 tank/iscsi/vol001
# iscsitadm list target -v
Target: tank/iscsi/vol001
[...]
    TPGT list:
            TPGT: 1
[...]
#

In order to secure access to this volume some more the initiator is required to authenticate itself using CHAP before access is granted. To do this three pieces of information are needed:

The iqn (basically a unique name) of the initiator
A username
A password

The initiator used here has an iqn of iqn.2005-03.com.max:01.cb5c4c (see below for the source of this information). The username is lain and the password is iscsipassword for the purpose of this demonstration. The password has to be between 12 and 16 charcters in length and should definitely be something stronger for production purposes.

# iscsitadm create initiator -n iqn.2005-03.com.max:01.cb5c4c lain
# iscsitadm modify initiator --chap-name lain lain
# iscsitadm modify initiator --chap-secret lain
[...]
# iscsitadm list initiator -v
Initiator: lain
    iSCSI Name: iqn.2005-03.com.max:01.cb5c4c
    CHAP Name: lain
    CHAP Secret: Set
# iscsitadm modify target --acl lain tank/iscsi/vol001
# iscsitadm list target -v
Target: tank/iscsi/vol001
[...]
    ACL list:
            Initiator: lain
[...]
#

This concludes the Solaris side of things.

The Fedora side

The system is running Fedora Rawhide, close to the Fedora 11 Beta release at the time of this writing.

On the Linux side iSCSI is handled by the open-iscsi toolchain, packaged as iscsi-initiator-utils in Fedora. To install it:

# yum install iscsi-initiator-utils
[...]
#

Since the system in question is a notebook, and the iSCSI target may not be available at all times, the iSCSI service must be instructed not to connect to configured devices automatically:

# perl -pi -e 's/node.startup.*/node.startup = manual/' /etc/iscsi/iscsid.conf
#

The initiator name mentioned in the Solaris section above can be configured freely on the system. A random value is created during package installation and saved in /etc/iscsi/initiatorname.iscsi:

# cat /etc/iscsi/initiatorname.iscsi
InitiatorName=iqn.2005-03.com.max:01.cb5c4c
#

Be sure the name configured there matches the name defined in the initiator on the Solaris side. Even though a username/password pair was defined on the target credentials are not needed for target discovery (the process by which an initiator asks a target which iSCSI volumes are available):

# iscsiadm -m discovery -t st -p 212.51.12.90
212.51.12.90:3260,1 iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8
# iscsiadm -m node
212.51.12.90:3260,1 iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8
#

The discovery process has found a single volume exported by the target and added it to the local node list. The iqn matches the value shown above in the Solaris section. Now the CHAP credentials have to be added to the node so the initiator can actually connect to the volume:

# iscsiadm -m node --target 'iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8' \
--name 'node.session.auth.authmethod' -v 'CHAP'
# iscsiadm -m node --target 'iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8' \
--name 'node.session.auth.username' -v 'lain'
# iscsiadm -m node --target 'iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8' \
--name 'node.session.auth.password' -v 'iscsipassword'
# iscsiadm -m node --target 'iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8'
node.name = iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8
node.tpgt = 1
node.startup = manual
[...]
node.session.auth.authmethod = CHAP
node.session.auth.username = lain
node.session.auth.password = ********
[...]
#

Now the volume can finally be accessed:

# iscsiadm -m node --target 'iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8' --login
Logging in to [iface: default, target: iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8,
portal: 212.51.12.90,3260]
Login to [iface: default, target: iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8,
portal: 212.51.12.90,3260]: successful
#

After some seconds a device node for this volume should appear in /dev/disk/by-path:

# ls /dev/disk/by-path/
ip-212.51.12.90:3260-iscsi-iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8-lun-0
[...]
#

The disk is ready to be used.

Using pkgsrc on Opensolaris, Part 3

nospam@example.com (Ralf Ertzinger) — 2009-03-23T01:47:00Z

Initial install

pkgsrc can be obtained in two main ways. The first is via anonymous CVS checkout, the second is via quarterly tarball releases. Since the whole tree is several hundred megabytes (even without sources) and the NetBSD CVS servers are permanently overloaded a tarball is the way to go for the initial install. The tarballs can be found in the NetBSD mirror structure, the main mirror being here. At the time of this writing pkgsrc-2008Q4 is current.

The tarball already contains a pkgsrc directory at the top level, so it has to be unpacked under /usr.

# wget ftp://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc.tar.gz
# gtar -xzf pkgsrc.tar.gz -C /usr
# chown -R builder: /usr/pkgsrc

This will unpack the tarball into the filesystem mounted at /usr/pkgsrc and change the ownership to the build user created earlier.

Patching gcc

Unfortunately the gcc suite as delivered with Solaris has a small flaw, which will cause some packages to be built incorrectly (the most famous example is openssl, which will build but not work afterwards). Fortunately the bug has been tracked down and a bandaid is available here.

This file is a nice little hack in itself as it is a shell script and a C source file at the same time. If executed by a shell this file will be put though gcc three times to produce three object files, which are placed into a directory where the compiler can find them and use them instead of files that were delivered with the compiler.

# bash ./values.c /usr/sfw/bin/gcc
[....]
# ls -l $(dirname $(/usr/sfw/bin/gcc -print-libgcc-file-name))
[...]
-rw-r--r-- 1 root root    763 2009-02-21 17:34 values-Xa.o
-rw-r--r-- 1 root root    763 2009-02-21 17:34 values-Xc.o
-rw-r--r-- 1 root root    763 2009-02-21 17:34 values-Xt.o
#

Bootstrapping

With this particular bug out of the way pkgsrc needs to be bootstrapped. This means that the initial set of programs needed to build further packages (the package management itself and some helper programs) need to be built and installed on the host system. This has to be done as root. In order to find some programs it is necessary to expand the $PATH a bit.

# cd /usr/pkgsrc/bootstrap
# PATH="$PATH:/usr/sfw/bin:/usr/xpg4/bin" ./bootstrap
[....]
#

Bootstrapping will take a while, but it should run though cleanly. Afterwards there should be some files in /usr/pkg and running /usr/pkg/sbin/pkg_info should list a handful of installed packages.

Vulnerabilities and updates

Packages need to be kept up-to-date, for new features as much as for possible vulnerabilites. In the latter department the bootstrap installed two programs to help with identifying such programs.

/usr/pkg/sbin/download-vulnerability-list will fetch a list of vulnerable program versions. Builds of such versions will fail, unless explicitly requested otherwise. For already installed programs there is /usr/sbin/pkg/audit-packages which will identify and list installed vulnerable versions.

Both programs should be used on a regular basis.

Updates of packages (whether due to a vulnerability or not) are best done via CVS. Updates can be done on the whole package tree or on individual subtrees, as needed. Assuming an older installed version the following command will update the whole tree to 2008Q4:

# su - builder
$ cd /usr/pkgsrc
$ cvs up -dPR -rpkgsrc-2008Q4
[...]
$

It’s important to check the output of the CVS command for eventual problems, especially if local modifications to packages have been done.

Host tools

There are a number of tools that are used by a large number of packages during the build process. pkgsrc will build all of these from source if necessary, but most of them can be supplied by the host system instead.

Among these tools are

GNU m4
GNU make
GNU gettext
GNU tar
Perl
GNU patch
unzip
BISON & FLEX

GNU make and GNU tar are already installed, the rest of the packages can be found on the Solaris install media. The rest can easily be installed:

# gkp.pl -d /mnt/Solaris_11/Product SUNWgm4 SUNWgnu-gettext SUNWgpch SUNWunzip \
SUNWbison SUNWflexlex
[...]
#

Now pkgsrc has to be made aware of these tools in order to use them. The main config file is /usr/pkg/etc/mk.conf. Adding the following statements somewhere above the final .endif will make pkgsrc use the host version of the above mentioned tools instead of building it’s own:

# SUNWgm4
TOOLS_PLATFORM.m4=              /usr/bin/gm4
TOOLS_PLATFORM.gm4=             /usr/bin/gm4
# SUNWgmake
TOOLS_PLATFORM.gmake=           /usr/bin/gmake
# SUNWgnu-gettext
TOOLS_PLATFORM.msgfmt=          /usr/bin/gmsgfmt
# SUNWgtar
TOOLS_PLATFORM.tar=             /usr/bin/gtar
TOOLS_PLATFORM.bsdtar=          /usr/bin/gtar
# SUNWgpch
TOOLS_PLATFORM.patch=           /usr/bin/gpatch
TOOLS_PLATFORM.gpatch=          /usr/bin/gpatch
#
TOOLS_PLATFORM.perl=            /usr/bin/perl
# SUNWunzip
TOOLS_PLATFORM.unzip=           /usr/bin/unzip
# SUNWbison
TOOLS_PLATFORM.bison=           /usr/bin/bison
TOOLS_PLATFORM.bison-yacc=      /usr/bin/bison -y
# SUNWflexlex
TOOLS_PLATFORM.lex=             /usr/bin/flex