Posts Tagged ‘tips’

Netscaler VPX: DHCP support

February 4, 2015

This is a quick recipe for enabling DHCP for your Netscaler VPX on KVM:

  1. Boot the KVM VPX instance per the instructions on the citrix site.
  2. Create /nsconfig/

  3. #!/bin/sh

    mkdir /var/db # to store lease files
    mkdir /var/empty
    /sbin/dhclient -l /var/db/dhclient.leases.1 0/1

  4. Create /nsconfig/

  5. #!/bin/sh

    ADDR=`grep fixed-address /var/db/dhclient.leases.1 | awk '{print $NF}' | sed -e 's/;//' | uniq | tail -1`
    SUBNET=`grep subnet-mask /var/db/dhclient.leases.1 | awk '{print $NF}' | sed -e 's/;//' | uniq | tail -1`
    GATEWAY=`grep routers /var/db/dhclient.leases.1 | awk '{print $NF}' | sed -e 's/;//' | uniq | tail -1`

    grep "$ADDR" /nsconfig/ns.conf
    if [ $? != 0 ]; then
    nscli -U :nsroot:nsroot "set ns config -IPAddress $ADDR -netmask $SUBNET"
    nscli -U :nsroot:nsroot "savec"
    sleep 5
    yes | nscli -U :nsroot:nsroot "reboot"

    grep "$GATEWAY" /nsconfig/ns.conf

    if [ $? != 0 ]; then
    nscli -U :nsroot:nsroot "add route $GATEWAY"
    nscli -U :nsroot:nsroot "savec"

  6. Power off your Netscaler VPX and save the disk image as a DHCP-enabled template.

Netscaler 10.x, XenServer 6.2 and Cloudstack

November 1, 2013

Quick tech note. After my Cloudstack testbed upgrade my Netscaler VMs no longer booted. The issue was similar to the one described in CTX135226 but affected both Netscaler 9.3 and 10.1 VMs.

After wasting a few good hours it turns out that this is caused by the presence of a DVD drive in the VM. The mere presence of a DVD drive, even if no ISO is loaded, somehow messes up with the Netscaler boot process under XenServer 6.2. The workaround is trivial:

  1. 1. Spot the DVD drive (hdd) using the vbd-list command

  2. # xe vbd-list vm-name-label=NetScaler\ Virtual\ Appliance
    uuid ( RO) : 5e218b95-68e9-37b2-860f-8b97678e2c02
    vm-uuid ( RO): ab229b8f-2b18-4931-b80b-30ab8265b843
    vm-name-label ( RO): NetScaler Virtual Appliance
    vdi-uuid ( RO): 5bcf6d76-1d2f-411a-9dd7-469aad0f86ae
    empty ( RO): false
    device ( RO): hdd

    uuid ( RO) : 9d6ff62c-93fa-3af5-b4b5-c5c66a0556e4
    vm-uuid ( RO): ab229b8f-2b18-4931-b80b-30ab8265b843
    vm-name-label ( RO): NetScaler Virtual Appliance
    vdi-uuid ( RO): 7b1fa1ff-7388-4e5a-8c67-00e4d943a470
    empty ( RO): false
    device ( RO): hda

  3. Destroy it

  4. # xe vbd-destroy uuid=5e218b95-68e9-37b2-860f-8b97678e2c02

  5. 3. Power on the Netscaler VM again; this time it should work like a charm

This is good enough if you have access to the XenServer running the VM. Not as good of a workaround for a Cloudstack environment which requires you to jump a few extra hoops. Specifically, if you are using XenServer you can update the StartAnswer method to selectively invoke the createVbd function in if the guest OS type evaluate the guest OS type matches “Other install media” and the disk type is ISO skip VBD creation. Here is the relevant sample code snippet:

public StartAnswer execute(StartCommand cmd) {
String guestOsTypeName = getGuestOsType(vmSpec.getOs(), vmSpec.getBootloader() == BootloaderType.CD);
for (DiskTO disk : vmSpec.getDisks()) {
if (type == Volume.Type.ISO && gguestOsTypeName.toLowerCase().contains("other install media")) {
s_logger.debug("mperedim: skipping VBD creation");
} else {
createVbd(conn, disk, vmName, vm, vmSpec.getBootloader());

One can improve this workaround by mapping Netscaler VPXs to a dedicated OS template, so that DVD drives are still created for other VMs that get mapped to the “Other install media” XS template.

vpnc & windows 7: sleep a little bit

February 18, 2011

For quite some time I’ve been using vpnc within Cygwin to connect to the aging Cisco VPN 3000 Series Concentrator at dayjob (thank you Cisco for not supporting 64-bit users as Ilias points out in the comments Cisco has finally added partial support for Windows 7 64-bit). However, I’ve been running into the erratic problem where my split tunnels were created eratically and didn’t work. Specifically, once a VPN connection got created route print indicated routes similar to the following:

#route print
Network Destination        Netmask          Gateway       Interface  Metric     31

instead of the proper one:

Network Destination        Netmask          Gateway       Interface  Metric         On-link     31

I’ve conveniently ignored the problem for some time, using a custom script to tear down and re-create the problematic routing entries, till today. Some well placed “echos” in /etc/vpnc/vpnc-script-win.js indicated that vpnc properly constructed the required route add commands, yet the routing table entries were still wrong. Clickety-click:

$ diff /etc/vpnc/vpnc-script-win.js /etc/vpnc/vpnc-script-win-BEDC.js
$ diff -U 1 /etc/vpnc/vpnc-script-win.js /etc/vpnc/vpnc-script-win-BEDC.js
--- /etc/vpnc/vpnc-script-win.js        2010-09-18 13:13:25.778339100 +0300
+++ /etc/vpnc/vpnc-script-win-BEDC.js   2011-02-18 21:35:53.279264500 +0200
@@ -80,2 +80,4 @@
         if (env("CISCO_SPLIT_INC")) {
+               echo("sleeping a little bit; don't ask why but this is needed");
+               run("sleep 5");
                for (var i = 0 ; i < parseInt(env("CISCO_SPLIT_INC")); i++) {

Seems that a timing issue of some sort causes these route add commands to run prematurely, before the TAP tunnel interface is properly configured, resulting in a problematic configuration. Holding them back for just 5 seconds consistently does the trick for me.

Update: if generally interested in configuring VPNC with Windows, check out Alessio Molteni’s detailed post.
Update 2: Corrected status of the official Cisco VPN client.

Solaris: passing parameters from GRUB to the O/S

October 13, 2010

The problem with ramdisks is that each system ends up identical to each other. Hence you need a way to distinctly identify and pre-customize each system rather early in the boot process.

A clever way to do this is the MAC-address of the 1st network interface. This works nicely with Linux where the 1st network interface is always eth0. It doesn’t work as well in Solaris though for a couple of reasons:

  1. the network interface name depends on the NIC, i.e. e1000g0 for Intel NICs, bnx0 for Broadcom 1GbE, bnxe0 for Broadcom 10GbE ones etc.
  2. with Solaris the network interface and hence its MAC address is not visible with ifconfig until it is “plumbed”. And you can’t really expect the interface to be plumbed early in the boot process

Hence I considered a different approach. “With GRUB it is very easy to specify kernel and boot options in the boot menu“, so let’s go ahead, define a custom option in our menu.lst (which is centrally controlled by the DHCP/TFTPboot server) … :

# cat /tftpboot/menu.lst.01000C29A6B8E8
min_mem64 1024
title Solaris_10 Ramdisk
kernel$ /I86PC.Solaris_10-7/multiboot kernel/$ISADIR/unix -B hostname='random-hostname'
module$ /I86PC.Solaris_10-7/$ISADIR/ramdisk.img

… and read this option once the O/S boots. Easy enough. Only an hour or so later I couldn’t find any documentation on how to read my custom boot parameter.

[… clickety click …]

Turns out that the custom parameter is available using the prtconf command.

# prtconf -v /devices | sed -n '/hostname/{;n;p;}' |cut -f 2 -d \'

Easy to implement, hard to find out and remember.

Solaris diskless ramdisk boot

October 10, 2010

Working on a diskless architecture for dayjob I ran into the need to implement a diskless boot architecture. The options for the root filesystem were briefly the following:

  1. Ramdisk
  2. iSCSI
  3. NFS

Option 2 is nice but it does come with a “single point of failure” gotcha, namely the iSCSI server. Sure you can have a second one but I don’t really want to know what would happen if the SAN with the root filesystem goes offline. 3 is also nice but for me it was a slightly convoluted mess. Hence I opted for the ramdisk approach.

Thankfully, another kind soul has done something similar already. Here are some extra notes that I’ve found of use:

  1. Make a local copy of the root_archive command and adjust the UFS overhead to 50% instead of 10%. This will allow for some empty disk space in your root filesystem
  2. Remove the miniroot ramdisks that get installed with Solaris (/boot/x86.miniroot-safe and /boot/amd64/x86.miniroot-safe); you are building a ramdisk on your own, you don’t need to bundle two more within it
  3. Remove the boot_archive under /platform/i86pc

The above allow to cram a Solaris Core installation with a few extras (SSH, bash) in just 122 (compressed) MBytes.

# du -sh /var/tmp/ramdisk.img
122M /var/tmp/ramdisk.img

This is it. Copy the ramdisk to your TFTP boot server, configure GRUB accordingly:

# cat /tftpboot/menu.lst.01000C29A6B8E8
min_mem64 1024
title Solaris_10 Ramdisk
kernel$ /I86PC.Solaris_10-7/multiboot kernel/$ISADIR/unix
module$ /I86PC.Solaris_10-7/$ISADIR/ramdisk.img

configure your DHCP server appropriately for a network boot and … profit 🙂

Which still leaves open the issue of DHCP server high availability, however this should be easy to tackle.

Tip of the day: pax and removal of leading slashes

March 24, 2010

This came up at dayjob a couple of weeks ago and again today.

A nice feature of GNU tar is the removal of leading slashes in an archive. For instance if an archive foobar.tar contains files /foo and /bar the following command in a GNU Linux system:

cp foobar.tar /test
cd /test
tar xvf foobar.tar

Will generate /test/foo and /test/bar. Not so with a Solaris 10 system, where the files will be placed in the root directory.

Thanksfully there is a trivial workaround to remove the leading slash:

pax -rv -s ',^/,,' -f foobar.tar

A workaround now documented in a convenient place, rather than me having to search for it in either the bash history of a random system or an interesting but rather lengthy manpage.