pitter patter on the keyboard

I like to start my Xen networking by creating two (or more) bridges, one connected to the physical interface on the dom0 and another which is only connected to by virtual machines. This lets me set up an internal private network for cross-VM interaction and administration which is insulated from the DC’s network. If you put a router VM on both bridges which occupies your public IP addresses you can use 1-1 NAT to stack services from different VMs behind one IP and firewall the virtual machines. This is particularly handy where your address space is small but your VMs are many.

Unfortunately, the Debian interfaces configuration scheme doesn’t like setting up bridges with no bridge_ports directive so we have to give it a little boost. You will end up with a configuration file that looks something like this:

auto lo
iface lo inet loopback

iface eth0 inet manual

auto extbr0
iface extbr0 inet static
        bridge_ports eth0
        address x.x.x.x
        netmask 255.255.255.0
        network x.x.x.0
        broadcast x.x.x.255
        gateway x.x.x.1

auto intbr0
iface intbr0 inet manual
        pre-up    brctl addbr $IFACE
        post-down brctl delbr $IFACE
        up        ifconfig    $IFACE up y.y.y.y
        down      ifconfig    $IFACE down

Where y.y.y.y is an internal IP you can use to access the dom0. For example you might prefer not to expose SSH on your dom0 to the wild, you would make sshd listen on this IP and shell in over a VPN.

GRUB2 is highly customizable and feature-rich, however it is a bit of a nightmare if you configure bootloaders regularly. Unfortunately GRUB 0.97 doesn’t support ext4 and – if you were an idiot like me – you might have set up your new dedicated with an ext4 /boot. Now, you have neither the time nor patience to re-install and need to make Xen go.

First, copy your Dom0 .config and kernel to /boot/. /etc/grub.d/20_linux_xen picks up on the CONFIG_XEN_PRIVILEGED_GUEST=y variable.

# cp /usr/src/linux/arch/x86_64/boot/bzImage /boot/kernel-dom0
# cp /usr/src/linux/.config /boot/config-dom0

Next, remove the executable flag from /etc/grub.d/10_linux or you will end up with three or four entries that boot straight to the Dom0 kernel without the hypervisor.

# chmod -x /etc/grub.d/10_linux

To add kernel boot parameters to your grub.cfg (as generated with grub2-mkconfig and 20_linux_xen) add these lines to your /etc/default/grub file:

GRUB_CMDLINE_LINUX_XEN_REPLACE="max_loop=128"
GRUB_CMDLINE_XEN="dom0_mem=512"

The former will place your boot options on the Dom0 kernel’s module line. The latter will place boot options on the xen.gz hypervisor’s kernel line.

Now, generate your new configuration:

# grub2-mkconfig -o /boot/grub2/grub.cfg

Once the config file has been written, determine the position of the Xen hypervisor entry and update GRUB_DEFAULT in /etc/default/grub.

Install GRUB2 to your MBR(s) as necessary:

# grub2-install /dev/sda 

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.