- Provide big warning notice that all data will be wiped
- Only perform OS Reload if user types “I AGREE, ERASE MY DATA”
- Only perform OS Reload if user has shut down VPS
- Upon completion, display VPS name, new root password, primary IP address, E-mail

In the future we will add an option to select a different OS and re-send the user a welcome e-mail.

UPDATE: OS Selector done

A new screenshot our our system is also available:

http://www.xenvz.co.uk/images/VPS_control_panel.png

Updates to Reverse DNS on IP addresses are now queued for processing upon the client submitting the PTR record via the control panel.

Currently, the queue is processed every 5 minutes in order to ensure the system works as efficiently as possible.

• Fixed bug where additional IPs would not bind when VPS powered on/restarted by non-admin user

• Add IP address management

• Add Reverse DNS management

We fixed a bug where additional IPs would not bind when VPS were not powered on/restarted by non-admin users.

IP address management has been added for end users. This will allow the user to list their IP addresses and add IPs if their quota allows. When adding IPs, users can select from a list of upto 10 available IP addresses. Justification for IP use it also gathered from the user during this process.

Reverse DNS manager is now in place. This allows the user to list and edit Reverse DNS for their IP addresses. Please note that at this stage only the frontend + database structure is in place: we do not actually set the PTR records. We will have PTR records in sync with our Reverse DNS database very shortly.

Also added by popular demand is the “Power User” flag which users can enable on VPS. This flag will prevent our control panel from mounting your file system and writing network configuration files at VPS boot time. For our less experienced users it is important that our control panel can automatically write these files to allow for provisioning, IP changes and various other updates/changes.

A toggle flag for power user will be available within our control panel shortly. In the mean time, customers may request a member of staff to enable the power user flag via our contact form.

Coming next by popular demand and in no particular order:

• Automated additional IP allocations
• Reverse DNS control
• OS reloads

We are currently working extensively on provisioning/configuration of Xen accounts. We can currently deploy Xen+Debian/Ubuntu VPS directly from our control panel. RAM/IP address additions are now also applied at reboots/power on via our control panel.

OpenVZ provisioning will be coming soon.

Ultimately this will lead to automated or quicker provision times for new customers and instant OS reloads/upgrades for new customers.

We will be changing how users can request more IP addresses. Customers will be able to apply for IP addresses via our control panel out of their existing quota (or purchase more if required) and enter justification for IP use directly into our database.

Updates/Additions:

• Added complete traffic accounting for OpenVZ with history
• Secure communication channels between control panel and host nodes via lightweight, security-tight python scripts. No daemon software installed on host nodes and no ability to run dangerous commands (i.e. “command whitelist with regexp”)
• Various UI changes
• Improvements to HyperVM migration script
• Now fully integrated with our billing system. Purchased an add-on? Have it available instantly! Extra IP? No problem..
• Pending Provision list for manual fraud checking
• …and more!

No screenshot this time, sorry Folks! Check our older posts for previous screenshots.

So far we have implemented

• IP Pool manager with Reverse DNS
• VPS Server manager
• OS Template manager
• VPS Account manager
• Product resources and quotas
• Migration script from HyperVM

For those of you interested in a sneak preview, check out this censored screenshot.

As always, instructions will be brief. If you feel I have missed out some important detail, feel free to comment and I *may* update the article.

First create and mount a 10GB ext3 filesystem for our image:

sudo lvcreate -L 10G -n template.modernadmin.com-disk VolGroup00
sudo mkfs.ext3 /dev/VolGroup00/template.modernadmin.com-disk
sudo mkdir /mnt/tmp
sudo mount /dev/VolGroup00/template.modernadmin.com-disk /mnt/tmp

Next, we install debootstrap. Since version 1.0.10-2.fc11+ has dependency problems on CentOS 5.3, we’ll use an older version I have mirrored here:

wget http://www.modernadmin.com/downloads/ostemplates/debootstrap-1.0.10-1.fc10.noarch.rpm
sudo rpm -Uvh debootstrap-1.0.10-1.fc10.noarch.rpm

Since jaunty specific scripts are not in this release of debootstrap, lets copy from gutsy:

sudo cp /usr/share/debootstrap/scripts/gutsy /usr/share/debootstrap/scripts/jaunty

Now install jaunty into /mnt/tmp using debootstrap:

sudo debootstrap --include=udev,ssh,quota --arch amd64 jaunty /mnt/tmp http://uk.archive.ubuntu.com/ubuntu/

We need to copy modules into the template – these will be specific to your Xen host node(s). In our case we have a few custom sets, but for now we only want the latest version:

sudo cp -dpR /lib/modules/2.6.18-128.1.6.el5xen /mnt/tmp/lib/modules/

Populate the sources.list file for apt-get:

sudo cat <<EOF > /mnt/tmp/etc/apt/sources.list
deb http://gb.archive.ubuntu.com/ubuntu/ jaunty main restricted universe multiverse
deb-src http://gb.archive.ubuntu.com/ubuntu/ jaunty main restricted universe
deb http://gb.archive.ubuntu.com/ubuntu/ jaunty-updates main restricted universe multiverse
deb-src http://gb.archive.ubuntu.com/ubuntu/ jaunty-updates main restricted universe
deb http://security.ubuntu.com/ubuntu jaunty-security main restricted universe
deb-src http://security.ubuntu.com/ubuntu jaunty-security main restricted universe
EOF

Create a temporary interface which will be removed later on. Also populate some other required files:

sudo cat <<EOF > /mnt/tmp/etc/network/interfaces
auto eth0 lo
iface eth0 inet static
address 95.154.208.250
netmask 255.255.255.0
up route add -net 95.154.208.0 netmask 255.255.255.0 dev eth0
up route add default gw 95.154.208.1
iface lo inet loopback
EOF
sudo cat <<EOF > /mnt/tmp/etc/hosts
127.0.0.1 localhost template.modernadmin.com
EOF
sudo cat <<EOF > /mnt/tmp/etc/hostname
template.modernadmin.com
EOF
sudo cat <<EOF > /mnt/tmp/etc/fstab
proc /proc proc defaults 0 0
devpts /dev/pts devpts defaults 0 1
/dev/sda2 none swap sw 0 1
/dev/sda1 / ext3 errors=remount-ro 0 1
EOF
sudo cat <<EOF > /mnt/tmp/etc/event.d/xvc0
start on stopped rc2
start on stopped rc3
start on stopped rc4
start on stopped rc5

stop on runlevel 0
stop on runlevel 1
stop on runlevel 6

respawn
exec /sbin/getty 38400 xvc0
EOF
sudo rm -rf /mnt/tmp/etc/event.d/tty1
sudo echo “alias eth0 xennet” > /mnt/tmp/etc/modprobe.d/xen
#echo “xvc0″ >> /mnt/tmp/etc/securetty
sudo cat /dev/null > /mnt/tmp/etc/udev/rules.d/70-persistent-net.rules

This next section is completely optional. We will install DenyHosts and any other custom packages to further secure the virtual machines by default.

First, chroot to the new template and set a root password:

sudo chroot /mnt/tmp

passwd root

Exit the chroot and unmount the template from the host node:

exit
sudo umount /mnt/tmp

Start the VM:

sudo xm create template.modernadmin.com.cfg -c

Inside the Xen domU you have just started, install denyhosts, configure as required and then shutdown:

apt-get -y update
apt-get -y upgrade
apt-get -y install denyhosts
apt-get -y clean
shutdown -h now

This step is also optional and only applies if you started the VPS as above and is simply a cleanup step:

sudo mount /dev/VolGroup00/template.modernadmin.com-disk /mnt/tmp
sudo rm -f /mnt/tmp/etc/ssh/ssh_host_*
sudo cat << EOF > /mnt/tmp/etc/rc2.d/S15ssh_gen_host_keys
#!/bin/bash
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ”
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ”
rm -f \$0
EOF
sudo chmod a+x /mnt/tmp/etc/rc2.d/S15ssh_gen_host_keys
sudo cat <<EOF > /mnt/tmp/etc/network/interfaces
# loopback interface
auto lo
iface lo inet loopback
EOF

sudo cat /dev/null > /mnt/tmp/var/log/apt/term.log
sudo cat /dev/null > /mnt/tmp/var/log/auth.log
sudo cat /dev/null > /mnt/tmp/var/log/boot
sudo cat /dev/null > /mnt/tmp/var/log/bootstrap.log
sudo cat /dev/null > /mnt/tmp/var/log/btmp
sudo cat /dev/null > /mnt/tmp/var/log/daemon.log
sudo cat /dev/null > /mnt/tmp/var/log/debug
sudo cat /dev/null > /mnt/tmp/var/log/denyhosts
sudo cat /dev/null > /mnt/tmp/var/log/dmesg
sudo rm -rf /mnt/tmp/var/log/dmesg.*
sudo cat /dev/null > /mnt/tmp/var/log/dpkg.log
sudo cat /dev/null > /mnt/tmp/var/log/faillog
sudo rm -rf /mnt/tmp/var/log/fsck/*
sudo cat /dev/null > /mnt/tmp/var/log/kern.log
sudo cat /dev/null > /mnt/tmp/var/log/lastlog
sudo cat /dev/null > /mnt/tmp/var/log/lpr.log
sudo cat /dev/null > /mnt/tmp/var/log/mail.err
sudo cat /dev/null > /mnt/tmp/var/log/mail.info
sudo cat /dev/null > /mnt/tmp/var/log/mail.log
sudo cat /dev/null > /mnt/tmp/var/log/mail.warn
sudo cat /dev/null > /mnt/tmp/var/log/messages
sudo cat /dev/null > /mnt/tmp/var/log/pycentral.log
sudo cat /dev/null > /mnt/tmp/var/log/syslog
sudo cat /dev/null > /mnt/tmp/var/log/udev
sudo cat /dev/null > /mnt/tmp/var/log/user.log
sudo cat /dev/null > /mnt/tmp/var/log/wtmp
sudo cat /dev/null > /mnt/tmp/root/.bash_history
sudo cat /dev/null > /mnt/tmp/etc/udev/rules.d/70-persistent-net.rules

Finally, package the system into a .tar.gz and you are good to go!

cd /mnt/tmp
sudo tar czf /home/hypervm/xen/template/ubuntu-9.04-x86_64-modernadmin.tar.gz .
sudo chmod 755 /home/hypervm/xen/template/ubuntu-9.04-x86_64-modernadmin.tar.gz

Feel free to reproduce this article elsewhere but please give ModernAdmin.com credit where possible. A link back to our site goes a long way and would be greatly appreciated!

Set up multiple IPs by separating them with a space like follows in the domU config:

vif = [ 'ip=78.129.140.250 78.129.140.251' ]

You can also add more IPs to the domU without having to restart it using the following syntax replacing 78.129.140.1 with your gateway and vif101.0 with the interface name associated with the domU in your dom0:

ip route add 78.129.140.251 dev vif101.0 src 78.129.140.1

Your domU should now be able to use the extra IP!

In my case, I was trying to forward the IP to an OpenVZ VE within a domU -- this works perfectly fine with the above and no further configuration is required within the domU (other than obviously adding the IP to the OpenVZ container).