pitter patter on the keyboard

qemu-img convert -O raw diskimage.qcow diskimage.raw

After doing a host name change on a Zimbra appliance the domain was locked. Error messages included:

Webmail:

This account is currently in maintenance mode

Admin FE

The domain is temporarily locked by the server. You will not be able to make any changes to the domain until the internal lock is removed.

zmprov

ERROR: service.PERM_DENIED (permission denied: can not access domain, domain is in shutdown status)

Unfotunately, it’s not possible to change the status in the Admin FE. You’re going to have to either use ldapmodify, or if you’re ldap-squeamish like me phpldapadmin.

I went through maybe two dozen bellyaching forum threads complaining about this problem and how no one has come up with a solution until I found this article at http://www.zoobey.com/index.php/resources/all-articles-list/430-zimbra-rename-domain-fix:

You may have to run this multiple times for every 1000 users because of a java/zimbra bug. After it you are left with both domains in shutdown mode and having a rename status. These are store in openldap. Below is method to fix it. This is for zimbra 6.0+ – I did it on 7.1.3. BE REALLY CAREFUL AND BACKUP AS YOU CAN MESS STUFF UP Easily.

First, backup your entire /opt/zimbra is recommended and at least your ldap

openldap backup

su – zimbra
/opt/zimbra/libexec/zmslapcat /tmp/backup

download phpldapadmin (you can do this using ldapmodify as well or any other ldap tool)

phpldapadmin config.php

<?php
$config->custom->appearance['friendly_attrs'] = array(
‘facsimileTelephoneNumber’ => ‘Fax’,
‘gid’ => ‘Group’,
‘mail’ => ‘Email’,
‘telephoneNumber’ => ‘Telephone’,
‘uid’ => ‘User Name’,
‘userPassword’ => ‘Password’
);

$servers = new Datastore();
$servers->newServer(‘ldap_pla’);
$servers->setValue(‘server’,'name’,'My LDAP Server’);
$servers->setValue(‘server’,'host’,'YOUR HOST IP’);
$servers->setValue(‘server’,'port’,389);
$servers->setValue(‘server’,'base’,array(”));
$servers->setValue(‘login’,'bind_id’,'uid=zimbra,cn=admins,cn=zimbra’);
$servers->setValue(‘login’,'bind_pass’,'YOUR_PASSWORD’);
?>

Using PHPLDAPADMIN do the following
Search Base DN

DC=yourdomainname, DC=com

Click on domain, make changes searching for
zimbradomainstatus
zimbraDomainRenameInfo – set to “active” no quotes
zimbradomainrenameinfo
zimbraDomainStatus – delete all text from box

zimbraMailStatus – enabled
zmprov md YOUR_DOMAIN_NAME zimbraMailStatus enabled

update verify it updated as it sometimes will prompt you “Click Update Object” button at bottom of object

as zimbra user
zmmailboxdctl restart

zmprov md YOUR_NEWLY_RENAMED_DOMAIN_NAME zimbraMailStatus enabled

If you want to remove old domain
zmprov dd THE_OLD_DOMAIN

You can obtain your LDAP password by running:

$ zmlocalconfig -s | grep zimbra_ldap_password
zimbra_ldap_password = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

I found the config.php part uneccecary since the default installation of phpldapadmin supplies a form for directly logging in.

Full-disk images – that is to say a file containing an MBR, partition table and one or more partitions – are a pain in the arse to scale. Conventional wisdom tells us we should be able to do this with losetup and parted, or less gracefully with (c)fdisk but I’ve never had anything but trouble. In the end, it tends to be much easier to move the contents of the image to a file-system-only image and externalize the kernel since we’ll no longer have the benefit of a bootloader.

Let’s create and mount our new image to start off:

# dd if=/dev/zero of=newimage.img bs=1M count=4000
# mke2fs -j newimage.img
# mkdir /mnt/rawroot
# mount -o loop newimage.img /mnt/rawroot

Now we’re going to mount our old full disk image’s partition. Use kpartx -l to determine what node the partition will be mapped to:

# kpartx -l oldimage.hdd
loop34p1 : 0 4190208 /dev/loop34 2048

This tells us the full disk will be on /dev/loop34 and the partition itself will be on /dev/mapper/loop34p1.

# kpartx -a oldimage.hdd
# mkdir /mnt/rawroot2
# mount /dev/mapper/loop34p1 /mnt/rawroot2

Alternatively, we can let lomount do the work for us:

# lomount -diskimage oldimage.hdd -partition 1 /mnt/rawroot2

Now we’ll copy the files in the old file system to the new image exactly as they stand:

# cd /mnt/
# cp -ax rawroot2/* rawroot/

It’s important that we use the -a flag or we may end up breaking file system links and will almost certainly fill up the new image when we hit device nodes like /dev/zero, /dev/urandom and so on.

Edit the /etc/fstab in the new image and ensure it reflects the new configuration; / will probably come from /dev/xvda1. Old references by LABEL or UUID will no longer be valid.

Since we’ll be forgoing a bootloader it is necessary to externalize the kernel and initrd images:

# cp rawroot2/boot/vmlinuz-3.2.0-29-generic /xen/myvm/
# cp rawroot2/boot/initrd.img-3.2.0-29-generic /xen/myvm/

Now we can unmount both images:

# umount rawroot
# umount rawroot2

If you used kpartx instead of lomount you should remove the old image from the loop device:

# kpartx -d oldimage.hdd

Now alter the Xen configuration file to reference the externalized kernel and initrd:

kernel = "/xen/myvm/vmlinuz-3.2.0-29-generic"
initrd = "/xen/myvm/initrd.img-3.2.0-29-generic"

Remove or comment your reference to pygrub and boot the machine. If everything went well you will be looking at a login prompt shortly.

Please see my article on resizing file system images for details on how to grow the new image.