on the server running the wiki open a terminal and paste the following into the file backup-wiki.sh

#!/bin/bash
rm -rfd /tmp/wiki_backup
BACKUP=/tmp/wiki_backup
mkdir $BACKUP
pg_dumpall --username=_postgres > $BACKUP/postgres_lion_db.sql
cp -ap /Library/Server/Wiki $BACKUP
tar -cvzf wiki-backup.tar.gz $BACKUP


Save and exit the file, then do the following


chmod +x backup-wiki.sh
sudo ./backup-wiki.sh


This will create the file wiki-backup.tar.gz in your CWD

Prep the migration file

Copy this file to the new server, untar it.

edit the postgres_lion_db.sql file and add the following in the appropriate place, near the top of the file, just look you’ll figure it out. (Put it before the CREATE DATABASE statements)


DROP DATABASE IF EXISTS collab;


Save and exit the file

Then follow this procedure.
1. Open server.app and turn on wiki
2. Open terminal and find pgsql process (ps aux | grep pgsql) , copy it to clipboard
3. Stop wiki server
4. open terminal and enter sudo -u _postgres (paste in clipboard)
5. open terminal and enter

sudo su
cd /tmp
psql --username=collab < /path/to/postgres_lion_db.sql

6. a bunch of shit will fly by, forget about it.
7. Nuke that psql process running in the terminal
8. copy the Wiki folder from our backup into /Library/Server
9. Repair permissions
10. Turn on wiki, pray

In this how-to we’re going to install CentOS 5.5 and prep it to become a virtual machine server. Before proceeding PLEASE read our Xen software page so you understand how the VM and network topology works. This how-to was built combining various methods publicly already available. If you find some copy and pasted text just remember: a good sysadmin is a lazy sysadmin.

Prerequisites

LACP bonded 802.1q trunk with necessary VLAN’s assigned

Installation

Install CentOS 5.5, during the package selection screen make sure to enable the Virtualization option.

Configuration

First let’s make sure that xen is running properly. Log into the GUI of the server, if you do not have a GUI then log into an ssh session as root with X forwarding on. Run virt-manager from the console. You should see “dom0″ running, if you double click on it you’ll be able to see the statistics for this domain and how much resources it is consuming. If you cannot see this or if virt-manager does not find a dom0 to connect to you have done something wrong. I cannot help you.

1. Physical Networking Devices
What we first need to do is setup our networking devices.
Edit some files in /etc/sysconfig/network-scripts. Remember that bond0 is the physical interface that the trunk is connected to therefore it does not need an IP address.
# ifcfg-bond0
DEVICE=bond0
BOOTPROTO=none
ONBOOT=yes
USERCTL=no
TYPE=BOND
BONDING_OPTS="mode=4"


#ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no
TYPE=Ethernet
HWADDR:(MAC-ADDRESS OF ETH0)

#ifcfg-eth1
DEVICE=eth1
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no
TYPE=Ethernet
HWADDR:(MAC-ADDRESS OF ETH1F)

Then for every VLAN that you are passing in your trunk create a file as follows. Please replace the ‘N’ with the VLAN ID number

[root@xentest jeunson]# more /etc/sysconfig/network-scripts/ifcfg-bond0.N
DEVICE=bond0.N
BOOTPROTO=none
#IPADDR=192.168.100.51
#NETMASK=255.255.255.0
ONBOOT=yes
VLAN=yes
TYPE=BOND


Note how the IP address is commented out on this VLAN interface. You can assign an IP address to the VLAN interface that will be the management interface for the hardware.

Finally don’t forget to add the following line to /etc/modprobe.conf

alias bond0 bonding


Now that you’ve created the VLANs and assigned a management interface we edit the file /etc/sysconfig/network

[root@xentest jeunson]# more /etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=xentest.example.com
GATEWAY=192.168.101.254
GATEWAYDEV=bond0.101


Now restart the networking with /etc/init.d/network restart It should restart with out any errors

Shutting down interface bond0.100: Removed VLAN -:bond0.100:-
[ OK ]
Shutting down interface bond0.101: Removed VLAN -:bond.101:-
[ OK ]
Shutting down interface bond: [ OK ]
Shutting down loopback interface: [ OK ]
Disabling IPv4 packet forwarding: net.ipv4.ip_forward = 0 [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface bond0.100: Added VLAN with VID == 100 to IF -:bond0:-
[ OK ]
Bringing up interface bond0.101: Added VLAN with VID == 101 to IF -:bond0:-
[ OK ]


2. Xen Networking Scripts
First modify /etc/xen/xend-config.asp and change the netdev device from eth0 to bond0. You’ll probably have to reboot the computer.

A.Modify the network-bridge script

Now that we’re done that we need to configure Xen to tell it what networking interfaces to use. First make a backup of the xen network-bridge script and edit as follows.
cp /etc/xen/scripts/network-bridge /etc/xen/scripts/network-bridge.orig
Change around line 78 from
[ -f "/sys/class/net/$1/bonding/slaves" ]
to
[ -f "/sys/class/net/$1/bonding/slaves" ] || [ -f /proc/net/vlan/$1 ]

B. Modfiy xend-config.sxp
The second change involves modifying the xend configuration file to use a new network initialization script.
[root@xentest scripts]# cd /etc/xen
[root@xentest scripts]# cp -p xend-config.sxp xend-config.sxp-dist
Change the network-script configuration directive to the new script name – such as network-multi-bridge. After the modification:
[root@xentest xen]# diff xend-config.sxp-dist xend-config.sxp
91c91
< (network-script network-bridge) --- > (network-script network-multi-bridge)
C. Create network-multi-bridge script
This script uses the two VLAN interfaces previously defined.

[root@xentest scripts]# cd /etc/xen/scripts
[root@xentest scripts]# more network-multi-bridge
#!/bin/sh
dir=$(dirname "$0")
"$dir/network-bridge" "$@" vifnum=0 netdev=bond0 bridge="xbr_trunk"

/sbin/ifup eth0.100
"$dir/network-bridge" "$@" vifnum=1 bridge="xbr_v100" netdev="bond0.100"
/sbin/ifup eth0.101
"$dir/network-bridge" "$@" vifnum=2 bridge="xbr_v101" netdev="bond0.101"


At this point you should reboot your server to make sure that everything comes up cleanly. Use the logs to debug problems and look out for which type of bond your computer connects to the switch as.

1. On the secondary server, run this command. (use whatever zone you want to transfer in place of lan.example.com
rndc -p 54 retransfer lan.example.com IN com.apple.ServerAdmin.DNS.public

2. Reload configuration
rndc -p 54 reload

3. Forcing client cache flush
dscacheutil -flushcache

The reason I think this is better in my opinion is it gets rid of the potential “oops” of deleting critical files in /var/named.

Packet Fragmentation Example

MTU 101

Maximum Transmission Unit refers to how much data in bytes the data layer can send forward. For ethernet the size is 1500 bytes, which coincides with how much data can fit in an ethernet frame. Within the MTU is another size called MSS (Maximum Segment Size) which refers to how much TCP data can be transmitted. This is also known as the payload and is usually 1460 bytes. The 40 bytes difference between the MTU and MSS sizes are for TCP/IP headers. But this can create a problem when GRE is introduced.

Enter the Tunnel

The big problem with GRE is that it doesn’t fit into the 7 layer dip of the OSI model. It acts as a separator between the network and transport layers. GRE adds a header to all the packets that will traverse the GRE tunnel, thus consume some of the 1500 bytes of the ethernet frame. The MTU then needs to be decreased to allow the packet to fit within the frame. This can result in packet fragmentation or packet loss as some packets will have a “don’t fragment” bit set.

Determine MTU

To optimize your network performance it would be best practice to determine the MTU through the tunnel. This size my vary depending upon encapsulation, encryption, and routing. To determine the MTU size we will conduct some tests with “don’t fragment” ping packets from a host on one side of the tunnel to a host on the other side of the tunnel.

First let’s take a look at how “don’t fragment” pings work. We’re going to send two pings (-c 2) with the don’t fragment (-D) bit set and specify the payload to be 1472 bytes (-s 1472)

homer:~ jordan$ ping -D -c 2 -s 1472 4.2.2.2
PING 4.2.2.2 (4.2.2.2): 1472 data bytes
1480 bytes from 4.2.2.2: icmp_seq=0 ttl=54 time=37.163 ms
1480 bytes from 4.2.2.2: icmp_seq=1 ttl=54 time=34.799 ms


This shows us that the MTU between us and 4.2.2.2 which is a public root DNS server is 1500. The difference between the MTU size (1500) and ping payload size (1472) is the ICMP headers of 28 bytes. This is important to note, as ping payloads used to test the MTU must be 28 bytes lower than the MTU value you are testing.

If we add one byte to this test it will cause the ping to be lost.

homer:~ jordan$ ping -D -c 2 -s 1473 4.2.2.2
PING 4.2.2.2 (4.2.2.2): 1473 data bytes
ping: sendto: Message too long
ping: sendto: Message too long


So let’s try and determine the MTU for this sample network. We have a host on each side with a default MTU of 1500 and tunnel in between the two of them. To determine the MTU we issue the command listed above

homer:~ jordan$ ping -D -c 2 -s 1472 172.16.10.10
PING 172.16.10.10 (172.16.10.10): 1472 data bytes
ping: sendto: Message too long
ping: sendto: Message too long


Clearly this shows us the payload is too large and thus the MTU is lower than 1500. So let’s lower the payload by 10 bytes and round it down, if it fails decrement the payload by 10 bytes again and again while testing until you have a successful test. Then increment by 1 byte until it stops working. The last test payload size, plus 28 bytes is your MTU.

Example:

homer:~ jordan$ ping -D -c 2 -s 1460 172.16.10.10
PING 172.16.10.10 (172.16.10.10): 1460 data bytes
ping: sendto: Message too long
ping: sendto: Message too long
homer:~ jordan$ ping -D -c 2 -s 1450 172.16.10.10
PING 172.16.10.10 (172.16.10.10): 1450 data bytes
ping: sendto: Message too long
ping: sendto: Message too long
homer:~ jordan$ ping -D -c 2 -s 1440 172.16.10.10
PING 172.16.10.10 (172.16.10.10): 1440 data bytes
1448 bytes from 172.16.10.10: icmp_seq=0 ttl=254 time=72.199 ms
1448 bytes from 172.16.10.10: icmp_seq=1 ttl=254 time=78.266 ms
homer:~ jordan$ ping -D -c 2 -s 1441 172.16.10.10
PING 172.16.10.10 (172.16.10.10): 1441 data bytes
ping: sendto: Message too long
ping: sendto: Message too long

Tada, the last payload that worked was 1440, therefore our MTU is 1468. Ping payload size of 1440 bytes + ICMP header of 28 bytes = MTU of 1468 bytes

I hope you enjoyed yourself as much as I have, please feel free to leave questions in the comments here.

Example 1-1: Calculate the network mask from CIDR Notation /16

1. First subtract the CIDR notation from the total number of bits available in CIDR notation. This is the number of bits occupied in the mask.

2. Next, place no more than 8 bits into each octet starting with the one the on the right.

3. Move the bits into an exponent of two and calculate

4. Subtract one from each octet and you now have your reverse mask

5. Inverse the reverse mask to finally find out your network mask

The network mask for CIDR notation /16 is 255.255.0.0

Example 2-1: Calculate the CIDR notation from network mask 255.255.0.0

This is exactly the procedure above but just reversed

1. Inverse the network mask to find out your reverse mask

2. Add one to each populated octet

3. Find the exponent value of 2 for each octet (PROTIP: double 2 in your head until you hit the number, that is the number of bits ie {2 4 8 16} = 4…)

4. Add up all the exponent values and subtract from 32

Example 1-2: Calculate the network mask from CIDR Notation /13

1. First subtract the CIDR notation from the total number of bits available in CIDR notation. This is the number of bits occupied in the mask.

2. Next, place no more than 8 bits into each octet starting with the one the on the right.

3. Move the bits into an exponent of two and calculate

4. Subtract one from each octet and you now have your reverse mask

5. Inverse the reverse mask to finally find out your network mask (PROTIP, for the second octet just subtract 7 from 255)

Example 2-2: Calculate the CIDR notation from network mask 255.248.0.0

This is exactly the procedure above but just reversed

1. Inverse the network mask to find out your reverse mask

2. Add one to each populated octet

3. Find the exponent value of 2 for each octet (PROTIP: double 2 in your head as many bits as you have 2 4 8 16…)

4. Add up all the exponent values and subtract from 32