PXE booting of Webconverger

Webconverger is a great web kiosk tool.  This post briefly explains how to customize it and have it boot over a network (PXE boot).  These instructions apply to Ubuntu servers, but concept is adaptable.

First, download the webconverger ISO - I used version 8.0 since I already had it kicking around.

You need a DHCP server, a TFTP server and an NFS server.  Of course, the workstation has to support PXE booting, and be on the same network as these 3 servers.

You can use one physical machine for all three services, but in my scenario I have two machines, one acts as DHCP server, and the other is both the TFTP and NFS server.

DHCP

Using dhcp3-server.. entry in /etc/dhcp3/dhcpd.conf:

        host temp {
                hardware ethernet 00:14:c2:c4:5f:38;
                fixed-address temp.abc.com;
                option host-name "temp";
                option root-path "192.168.202.4:/tftpboot/webc/";
                if substring (option vendor-class-identifier, 0, 9) = "PXEClient" {
                next-server 192.168.202.4;
                filename "webc/pxelinux.0"; }
        }

 Note:  Here the "next-server" is required to redirect to the TFTP server.. obviously change the MAC and ip addresses according to your workstation and servers.  Be sure to restart your DHCP server.

Ok - thats the easy part..  now you have to prep for the TFTP/NFS server setup:


For PXE booting, you need syslinux, nfs-kernel-server, and tftpd-hpa.

TFTP

First, make root tftpboot directory for webconverger, then mount the ISO and copy files into the root dir:

mkdir -p /var/lib/tftpboot/webc/webconverger/8.0
mount -o loop webc8.iso /mnt
cp -a /mnt/* /var/lib/tftpboot/webc/webconverger/8.0
umount /mnt
cp /usr/lib/syslinux/pxelinux.0 /var/lib/tftpboot/webc
cp /usr/lib/syslinux/vesamenu.c32 /var/lib/tftpboot/webc
mkdir /var/lib/tftpboot/webc/pxelinux.cfg

In /var/lib/tftpboot/webc/pxelinux.cfg create a file called "default" with the following contents:

DEFAULT vesamenu.c32
TIMEOUT 10
ONTIMEOUT wc
PROMPT 0
NOESCAPE 1
MENU BEGIN Webconverger
MENU TITLE Webconverger
        MENU INCLUDE webconverger/webconverger.menu
MENU END

NOTE:  The TIMEOUT 10 is basically allowing no time to show menu.. I just want it booting "wc" entry (ONTIMEOUT wc) - adjust accordingly.

Last thing needed is the file /var/lib/tftpboot/webc/webconverger/webconverger.menu:

# nfsroot ip is pxe server's address

LABEL wc
        MENU LABEL Webconverger 8
        KERNEL /webconverger/8.0/live/vmlinuz
APPEND initrd=/webconverger/8.0/live/initrd.img boot=live config homepage=http://www.google.com hostname=webconverger nonetworking nopersistent quickreboot nomodeset noroot splash username=webc vga=current quiet netboot=nfs nfsroot=192.168.202.4:/var/lib/tftpboot/webc/webconverger/8.0
        TEXT HELP
        Boot Webconverger 8.0
ENDTEXT

NFS

Essentially you just need one entry /etc/exports:

/var/lib/tftpboot/webc *(ro,sync,no_subtree_check)

Then do:  exportfs -a

Workstation

Enter BIOS and configure station to boot from network.

You can customize by workstation, by creating additional entries in pxelinux.cfg..    a file called "01-00-14-c2-c4-5f-38" for example, will be used for workstation with MAC of 00:14:c2:c4:5f:38.  Essentially you just copy the "default" file and adjust the ONTIMEOUT to point to a LABEL in webconverger.menu.

 

MarkLogic xdmp:email with binary attachments need wrapping

According to RFC 2045, MIME base64 encoded attachments need to be wrapped at 76 characters.

Most email clients can handle attachments that are not wrapped (meaning the base64 encoding is not wrapped at 76 charaters), but some, specifically MS Outlook (at least some versions) cannot, and report that the attachment is corrupt.

When sending binary attachments from MarkLogic via xdmp:email
, this wrapping does not occur - causing some recipients to report documents are corrupt.

In order to fix this, we created a function which wraps the base64 encoding prior to sending.

(: Function used for wrapping email attachments :)
declare function local:wrap($wrapped, $unwrapped, $max){
        let $remaining := string-length($unwrapped)

        return if ($remaining <= $max) then concat($wrapped, "&#13;&#10;", substring($unwrapped, 1, $max))
        else local:wrap(concat($wrapped, "&#13;&#10;", substring($unwrapped, 1, $max)), substring($unwrapped, $max+1, $remaining), $max)
};

And it used when building the parameter list:

        let $attachment1 := local:wrap("", xs:string(xs:base64Binary(doc("/some/doc/path/doc.pdf"))), 76)

See documentation on xdmp:email for complete example with attachments.

Linux memory tweaks for improved responsiveness

Memory management techniques in the linux kernel has changed over the years.  Sometimes a kernel upgrade, or a hardware upgrade, where you expect better performance, can lead to disappointment.

For a while now, I've been struggling with our ubuntu 10.04 application server (managing 35 desktop sessions) where we experience "morning sluggishness" with the system.  Between 6am and noonish, the system was just not as responsive as it could be, but in the afternoons it became quite zippy.  I've been explaining this away with things like "everyone is just logging in morning, system is seeing a heavy load early in the day".. or "everyone does more work in the morning, and take it easy after lunch".

I decided to analyze memory usage patterns combined with I/O wait times.  Between 8am and noon, there was an average I/O wait time of between 2% - 3%, and between noon and 4pm an average of < 1%.  When I graphed out memory usage patterns, I noticed that our nightly backups were consuming a huge amount of buffered memory (understandably).. and that this buffer was slowly reclaimed overtime and around noonish every day it got close to cache size.  This couldn't be coincidence.. performance steadily increased as the buffers from previous nights backup were free'd up.  Makes total sense.. but question was.. how do I modify this behaviour?

Googling around, I came across this link

I already knew about vm.swappiness - already have this set to 10.

But vm.vfs_cache_pressure and vm.drop_caches were new to me.  So I thought, if we can drop the caches right after the backup, and give a little more priority to the inode/dentry caches - this should reduce our I/O wait.

So, I set vm.vfs_cache_pressure to 50 ( sysctl -w vm.vfs_cache_pressure=50 ), and in my backup script, added "echo 3 > /proc/sys/vm/drop_caches" to the end.  The results are quite dramatic.  So far this morning, I have an average I/O wait of  0.19%, down from 2-3%!! (and system is very zippy.)  This graph gives a good visual on the memory usage...

Notice: Everyday at 00:00.. this is backup kicking in.. Tues/Wed shows the slow reclaiming of buffers.  Thurs is where I drop the caches right after backup.. now caches reach previous days peak by 8am!!

Could this be the end of my users complaining about a slow system??   Doubt it... They never notice when its fast.. but always and only notice when its slow.

Update:  After two days now.. amazing.. average daytime I/O wait is now < 0.10%