Megamon Tech Blog

IT issues resolved

Jquery is awesome.

I stumbled across a bug when dealing with checkboxes and the change event with Internet Explorer.

I wanted my interface to trigger a javascript function when a checkbox was – you guessed it, checked.

Ditto if it the checkbox later was un-checked.

The following works in Firefox:

$(“#mapsearch”).change(function() { updateresults(1); return false; });

The problem in IE is that the above doesn’t work until you click somewhere else on the page ( anywhere ) … something to do with the event handler not firing because the checkbox has focus. Whatever.

I was searching the net for a fix, some people had come up with some elaborate solutions, additional functions, alternative check boxes through jquery extensions …

I wanted the simple answer, here it is one extra line:

$(“#yourdiv”).change(function() { myfunction(1); return false; });
$(“#yourdiv”).click(function() { this.blur(); });

After the checkbox looses its focus the event fires as it should and all checkboxes were once again behaving as they should.

I recently had a requirement for wireless access to function from approx 100 metres away inside a cement house. The the laptop’s wireless cards were not making the distance without significant packet loss.

I needed to deploy my WRT as a WPA wireless client and have PC’s attached to the WRT via the local switchport.

After running early versions of white russian for years back in the day without a drama, it was time for the new version of Kamikaze to be tested out.

I no longer had a web interface on the WRT so it had to be done via command line.

The broadcomm wireless card on the WRT does not work with the latest version of Kamikaze so there is a 2.4 kernel available for download which supplies the required kernel driver:

http://downloads.openwrt.org/kamikaze/8.09.1/brcm-2.4/

After uploading these to the device via SCP you flash the device as follows:

mtd -r write openwrt-brcm-2.4-squashfs.trx linux

The web GUI then makes the configuration of client mode a snap, after specifying the SSID and channel.

I was able to make out the ADSL link from 100 meters away with the WRT under a desk.

I recently installed Zimbra.

Very impressed with the system having migrated my postfix+courier+spamassasin+clamav solution to it.

However I have found that out of the box it lets a lot of spam through.

I had been forwarding spam emails to my spam training account for a week but the X-Spam-Status headers didn’t show the BAYES_xx numbers incrementing, it seemed to be stuck on BAYES_00.

Whilst trying to debug the spamassasin config – I found the “sa-learn –dump” command was erroring out.

A quick fix, a permissions issue, I had to manually create the /opt/zimbra/.spamassasin directory and chown zimbra:zimbra it. Re-ran the dump and it succeded.

After another week of fowarding spam emails to my spam training account, I gradually saw my spam increase in score and by the end of the week all mail was hitting BAYES_99.

The problem is that BAYES_99 on its own does score high enough (3.5) to get the email marked as spam by Spamassasin.

Next problem I found that out of the box Zimbra didn’t enforce all the obvious MTA restrictions.

Why not? Well, the documentation gives you a 4 line command to run, but the quotes don’t paste properly, much like my own example below:

zmprov mcf zimbraMtaRestriction reject_invalid_hostname zimbraMtaRestriction reject_non_fqdn_hostname zimbraMtaRestriction reject_non_fqdn_sender zimbraMtaRestriction “reject_rbl_client dnsbl.njabl.org” zimbraMtaRestriction “reject_rbl_client cbl.abuseat.org” zimbraMtaRestriction “reject_rbl_client bl.spamcop.net” zimbraMtaRestriction “reject_rbl_client dnsbl.sorbs.net” zimbraMtaRestriction “reject_rbl_client sbl.spamhaus.org” zimbraMtaRestriction “reject_rbl_client relays.mail-abuse.org”

Is it just me or is it too much to expect an ‘enterprise’ product to come out of the box to block ACAI diets? and Viagra?

With the RBL’s in place, my spam was reduced further, but many were still getting through.

Found this article:

http://www.zimbra.com/forums/administrators/4933-improving-spam-filtering.html

Installing Razor and DCC seems to be the answer, haven’t installed Pyzor yet.

Good bye spam.

Now, before you say “but VMware has tools to do this for you! haven’t you heard of platespin converter or VM converter?”

Well yes. But I wanted to see if it was possible. The answer is yes it is possible and would have worked flawlessly the first time around if I had also –excluded the /boot partition.

I ended up killing my VM for a while and using a rescue disk to recover.

To save you the same trouble, there are a few files on the target host you most definitely don’t want to overwrite.

Your /boot/grub/grub.conf would be one of them. Another is /etc/fstab.

Take backups of these files before executing the rsync.

On the freshly installed VM target host execute the following, where 192.168.1.1 is the src host:

rsync -av -e ssh root@192.168.1.1:/ / –exclude /proc –exclude /dev –exclude /sys –exclude /boot

Watch the magic. Restore the  backups of the files mentioned above, and have a think about any other changes that might be required before rebooting.

In my case I modified the ethernet configuration to give the machine a different IP address than the src host so that both could co-exist happily for a while.

I recently setup a few virtual machines under ESX 4 and found that the Centos hosts were running in  between 300 and 400 mhZ where as the Windows 2k3 and even the Ubuntu hosts were running at approx 70-100 mHz idle.

I learnt that it’s got to do with the frequency of the interupts changing from 100Hz to 1kHz in the 2.6 kernels.

The kernel that comes with Centos has been compiled with the 1000 Hz option as below:

grep ^CONFIG_HZ /boot/config-2.6.18-128.4.1.el5

CONFIG_HZ_1000=y
CONFIG_HZ=1000

By appending the options in bold below to the /boot/conf/grub.conf kernel= entries, the issue of high CPU is resolved:

kernel /vmlinuz-2.6.18-128.4.1.el5 ro root=/dev/VolGroup00/LogVol00 divider=10 clocksource=acpi_pm

Detail from vmware is here:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427

That's because the default frequency of interrupts
changed from 100Hz to 1kHz (and that is per CPU) in 2.6 kernels.
Placing much more stress on vmware and causing all bunch of problems
with it.  It's configurable compile time option (you'd need to recompile
kernel to change it to the old default)