GaSiD.org.uk

When using cyrus imap generally a new mailbox is added to the system using the following commands:

$ cyradm -u cyrus localhost
Password:
localhost> cm user.someusername

Generally, this would create the directory: /var/spool/imap/user/s/someuser, containing the various cyrus files.

It turns out that you can also do the following too:

localhost> cm someusername
localhost> cm someuser.name

When you list users you would see:

localhost> lm
someuser.name (\HasNoChildren)
someusername (\HasNoChildren)
user.someusername (\HasNoChildren)

I came across a (RHEL4) cyrus server like this today, it seems that someone had created some mailboxes like this accidentally and then not been able to remove them.

When I tried I received the following messages:

localhost> dm someusername
deletemailbox: Permission denied
localhost> sam someusername cyrus c
setaclmailbox: cyrus: c: System I/O error

Based on what I said above, I would have expected both /var/spool/imap/someusername and /var/spool/imap/someuser/n/name (or /var/spool/imap/someuser/name) to exist and to contain the various cyrus files, but they don’t. I can only assume that this is why I see the errors above.

Anyhow, the fix was fairly simple:

$ cd /var/spool/imap
$ mkdir someusername
$ reconstruct someusername
$ cyradm -u cyrus localhost
localhost> sam someusername cyrus c
localhost> dm someusername

The same applies forsomeuser.name, however rather than creating an extravagent directory structure, it appears that you can just create the directory someuser.name and then reconstruct someuser.name, if that fails then i’d suggest try creating someuser/name and resconstructing someuser.name or failing that, try creating someuser/n/name and reconstructing someuser.name.

This looks as though it may have been a bug in an older build of cyrus imapd. As I tried some similar steps on a test cyrus setup on a Gentoo system and I can create/delete these mailboxes fine without the above steps.

All very odd.

Whilst repurposing a machine that’s now a couple of years old, I came across a problem that the system couldn’t ’see’ a 1TB SATA hard disk, but other smaller disks seemed to work fine. I noticed a BIOS update for this board was available, but I hate floppies, so I had a little think and this is what I came up with…

Download a FreeDOS floppy disk image (fdboot.img)

Mount the disk image and copy the required files to it:

$ mount -t vfat -o loop fdboot.img /mnt/floppy
$ cp viaflash.exe /mnt/floppy
$ cp I1000107.BIN /mnt/floppy
$ umount /mnt/floppy

At this point my BIOS flashing floppy disk is technically ready to go, but how do I boot it without writing it to a floppy? So lets have a look at PXE boot… Now I already have a DHCP server configured to boot pxelinux from the syslinux project, I won’t go into too much detail here, but some vague additions to a simple dhcpd.conf for this appear to be:

# Specify the TFTP server to be used
next-server 10.3.0.254;

# Declare a vendor-specific option buffer for PXE clients:
# Code 1: Multicast IP address of boot file server
# Code 2: UDP port that client should monitor for MTFTP responses
# Code 3: UDP port that MTFTP servers are using to listen for MTFTP requests
# Code 4: Number of seconds a client must listen for activity before trying
#         to start a new MTFTP transfer
# Code 5: Number of seconds a client must listen before trying to restart
#         a MTFTP transfer

option space PXE;
option PXE.mtftp-ip               code 1 = ip-address;
option PXE.mtftp-cport            code 2 = unsigned integer 16;
option PXE.mtftp-sport            code 3 = unsigned integer 16;
option PXE.mtftp-tmout            code 4 = unsigned integer 8;
option PXE.mtftp-delay            code 5 = unsigned integer 8;
option PXE.discovery-control      code 6 = unsigned integer 8;
option PXE.discovery-mcast-addr   code 7 = ip-address;

subnet 10.3.0.0 netmask 255.255.255.0 {
8< SNIP ALL THE USUAL OPTIONS >8

# Provide PXE clients with appropriate information
class "pxeclient" {
 match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
 vendor-option-space PXE;

 # At least one of the vendor-specific PXE options must be set in
 # order for the client boot ROMs to realize that we are a PXE-compliant
 # server.  We set the MCAST IP address to 0.0.0.0 to tell the boot ROM
 # that we can't provide multicast TFTP.

 option PXE.mtftp-ip 0.0.0.0;

 # This is the name of the file the boot ROMs should download.
 filename "pxelinux.0";
 }
}

If we tried to boot the machine now, once its network boot kicks in and gets an IP address from the DHCP server, it will (using tftp) looks for the file pxelinux.0 on the IP address specified in next-server, so obviously we need a tftp server configured on the machine specified in next-server…

I have atftp installed on this server, it defaults to sharing /tftproot for its contents… so in here I have the pxelinux.0 file, booting the system now, it runs pxelinux and because of no configuration I eventually get dumped out in a boot> prompt.

A little further reading suggests that to boot a floppy image I need to use memdisk, yet another part of the syslinux package. I copied this file and my fdboot.img file to /tftproot on the dhcp server.

At the boot> prompt on the machine, I then:

boot> memdisk initrd=fdboot.img

Lo and behold… I end up at a pxe booted FreeDOS prompt.

Unfortuantely the viaflash.exe seems to hang as soon as I try to flash the BIOS. So perhaps that’s an issue with FreeDOS rather than /real/ DOS.

Further investigation needed, but hopefully i’ll never need a real floppy again!