Al Hoang

Awhile back I was noticing I was definitely losing emails. As one can might imagine, this is a scary experience since this brings into doubt if the mail system under use is doing something funny to the mail.

My first place to look was in the mail logs for the SMTP server and other associated daemons. However, I saw nothing in the maillogs which was not a very comforting thought.

After more investigation I would notice empty files like this every once in awhile…

~/Maildir)  ls -la new/
total 4
drwx------   2 al  al   512 Jun  8 00:25 .
drwx------  69 al  al  2048 Jun  8 00:25 ..
-rw-------   1 al  al     0 Jun  8 00:22 1244388142.30600_.myserver.net

This gave me more clues on where to look next. So next I looked in my Procmail logs for this particular mail id and noticed the process handling this message was killed by SIGPIPE

procmail: Executing "/usr/local/bin/spamassassin"
[84028] warn: spamassassin: killed by SIGPIPE
procmail: [84026] Tue Apr 14 21:45:26 2009

Googling dug up the following links that explain it all:

 http://www.nabble.com/Zero-exit-code-aft…
 https://issues.apache.org/SpamAssassin/s…

Verdict:
Upgrade Spamassassin

Since I have upgraded Spamassassin, the zero byte email mystery has resolved itself.

Awhile back I installed Ruby 1.9.1 in such a way as to co-exist with my current Ruby installation [1], [2] (I should use rvm [3] these days…)

However, one issue that cropped up during an IRB session was I could not copy and paste Japanese characters into the IRB repl. This is very very painful for my day to day use with Ruby (Imagine not being able to use the ‘|’ character while writing UNIX pipelines).

Below is an example of me trying to enter the character あ into IRB and watching it fail.

$ irb
irb(main):001:0> ab = "?"    <---- Tried entering the character あ
SyntaxError: (irb):1: invalid multibyte char (UTF-8)
(irb):1: unterminated string meets end of file
from /usr/local/bin/irb19:12:in `'

After a lot of head scritching I was able to narrow it down to something with readline:

$ irb --noreadline
irb(main):002:0> ab = "あ"
=> "あ"
irb(main):003:0>

After some more digging into the issue. The root cause seems to be the lack of GNU readline. By default, Ruby will link in the system installed readline library on OS X which is called editline [4]. Unfortunately, editline does not support UTF8 or multi-byte character sets which makes this a no-go for daily usage.

Most of the other references suggest downloading readline from source and installing into /usr/local however I believe this defeats the purpose of using something like MacPorts. After a bit of finagling I found that this is the invocation to get things working.

wget ftp://ftp.ruby-lang.org/pub/ruby/1.9/rub...
tar xvzf ruby-1.9.1-p243.tar.gz
cd ruby-1.9.1-p243
# Don't trust MacPorts version of autoconf because it somehow nuked the
# --with-readline-dir option
/usr/bin/autoconf
./configure --with-readline-dir=/opt/local --enable-shared --program-suffix=19 --enable-pthread
make
sudo make install

I have it wrapped up in a script which you can see here.

References

[1] http://wonko.com/post/how-to-compile-rub…
[2] http://frozenplague.net/2009/01/ruby-191…
[3] http://rvm.beginrescueend.com/
[4] http://thrysoee.dk/editline/

I have a love-hate affair with Capistrano. It is a great tool if you are a Ruby person and need to do something NOW on a bunch of machines. But the docs are in a constant state of suck from my point of view.

The Capify.org website helps for remembering the ’simple’ details on what Capistrano can do. But where I waste a lot of my time is asking questions like, “How do I set the Capistano SSH gateway to a non-standard port?”. Luckily, Capistrano is written in Ruby so it is easy enough to glance through the code and finally find out where it is but this is why good tech docs exist. To give enough context to answer those questions.

To answer my own question, below is a snippet you can add to your capfile to use a non-standard port if you need to deploy through a SSH gateway that lives on a non-standard port

# Add this to your Capfile
# This sets the SSH gateway to a machine called mysshgateway.com on port 22222
set :gateway, ‘mysshgateway.com:22222′

On small LAN networks that do not have an internal DNS server. There is a nice technology called ZeroConf that uses multicast to enable name lookup resolution. It has been baked into OS X for quite some time now. Linux and other UNIX flavors have been picking this up as well. OpenSolaris also includes this but enabling it is not on by default (At least with 2008.11). Here is a quick howto.

Edit the file /etc/nsswitch.conf and make sure that the line that begins with

hosts:

contains the following

hosts: files dns mdns

Then you should be able to ping any machine that uses Bonjour. For example, if you have a Mac that is named mycoolmac then you should be able to ping mycoolmac.local

References

• Heads-up Multicast DNS and discovery

I had a need for inserting the name of the current file into a bunch of files I was editing. I was pretty sure there was a function to do this in vim and after some searching I was right.

To insert the current filename. In Insert Mode, type CTRL-r % and it will insert the current filename.

Thanks to blog post for the tip!

After having dain bramaged myself for years with Linux usage. I had gotten spoiled into believing an OS should make it simple to do the following:

1. Shutdown computer
2. Swap around hardware components
3. Restart
4. Life is good

However any techie should tell you this is a pipe dream on Windows. Mac users probably have no clue since they never change hardware components and just buy new Macs to solve their problems. Which leaves the lucky OSS *nix variants to try stunts like this.

Being the stubborn person I am, I attempted this with OpenSolaris by swapping out my motherboard. I wanted to do this in order to take advantage of the E7400 Core 2 Duo that I bought awhile back. Things almost worked however on reboot I was given the dreaded console login screen with a useless keyboard. The following as far as I know don´t work…

1. CTRL-ALT-BACKSPACE
2. CTRL-ALT-Fn
3. CTRL-ALT-DEL

Your best bet is to ssh somehow and try to look for clues. Here is what I did…

1. Swap motherboard and stare at dark screen
2. Find out how to boot into single user mode and make sure the kernel isn’t PO-ed or something and find my IP address
3. Move away the X11 configuration that I configured (dual-display) and try rebooting
4. Reboot and find out it isn’t working
5. ssh in and realize it still isn’t working. Move the old dual display X11 config back to /etc/X11/xorg.conf
6. Try restarting gdm with svcadm restart gdm and watch it fail
7. Scritch head some more
8. Try starting X from the SSH session and whoah it works
9. Restart gdm (svcadm restart gdm) and now I get a login screen
10. Realize that I disconnected the left monitor (VGA) to help debug and want it back
11. Logout and log back in. I now have dual screens and a working Solaris install again!

References

• How to boot into Single User Mode for OpenSolaris
• Finding device faults with Fault Manager
• Debugging problems with nvidia driver on bootup

According to the Fedora FAQ one should be able to update with just this

sudo yum --enablerepo=updates-testing groupupdate "KDE (K Desktop Environment)"

However when I did, I ran into some icons from packages kdepim-3.5.9 and kdegraphics-4.1.0 conflicting with packages crystalsvg-icon-theme and libkipi. Here is a log…

  file /usr/share/icons/crystalsvg/48x48/apps/kpalmdoc.png from install of kdepim-3.5.9-10.fc9.i386 conflicts with file from package crystalsvg-icon-theme-4.0.4-1.fc9.i386
  file /usr/share/icons/crystalsvg/64x64/actions/kontact_contacts.png from install of kdepim-3.5.9-10.fc9.i386 conflicts with file from package crystalsvg-icon-theme-4.0.4-1.fc9.i386
  file /usr/share/icons/crystalsvg/64x64/actions/kontact_date.png from install of kdepim-3.5.9-10.fc9.i386 conflicts with file from package crystalsvg-icon-theme-4.0.4-1.fc9.i386
  file /usr/share/icons/crystalsvg/64x64/actions/kontact_journal.png from install of kdepim-3.5.9-10.fc9.i386 conflicts with file from package crystalsvg-icon-theme-4.0.4-1.fc9.i386
  file /usr/share/icons/crystalsvg/64x64/actions/kontact_mail.png from install of kdepim-3.5.9-10.fc9.i386 conflicts with file from package crystalsvg-icon-theme-4.0.4-1.fc9.i386
  file /usr/share/icons/crystalsvg/64x64/actions/kontact_news.png from install of kdepim-3.5.9-10.fc9.i386 conflicts with file from package crystalsvg-icon-theme-4.0.4-1.fc9.i386
  file /usr/share/icons/crystalsvg/64x64/actions/kontact_notes.png from install of kdepim-3.5.9-10.fc9.i386 conflicts with file from package crystalsvg-icon-theme-4.0.4-1.fc9.i386
  file /usr/share/icons/crystalsvg/64x64/actions/kontact_summary.png from install of kdepim-3.5.9-10.fc9.i386 conflicts with file from package crystalsvg-icon-theme-4.0.4-1.fc9.i386
  file /usr/share/icons/crystalsvg/64x64/actions/kontact_summary_green.png from install of kdepim-3.5.9-10.fc9.i386 conflicts with file from package crystalsvg-icon-theme-4.0.4-1.fc9.i386
  file /usr/share/icons/crystalsvg/64x64/actions/kontact_todo.png from install of kdepim-3.5.9-10.fc9.i386 conflicts with file from package crystalsvg-icon-theme-4.0.4-1.fc9.i386
  file /usr/share/icons/crystalsvg/64x64/actions/rss_tag.png from install of kdepim-3.5.9-10.fc9.i386 conflicts with file from package crystalsvg-icon-theme-4.0.4-1.fc9.i386
  file /usr/share/icons/hicolor/16x16/apps/kipi.png from install of kdegraphics-4.1.0-3.fc9.i386 conflicts with file from package libkipi-0.1.5-4.fc9.i386
  file /usr/share/icons/hicolor/22x22/apps/kipi.png from install of kdegraphics-4.1.0-3.fc9.i386 conflicts with file from package libkipi-0.1.5-4.fc9.i386
  file /usr/share/icons/hicolor/32x32/apps/kipi.png from install of kdegraphics-4.1.0-3.fc9.i386 conflicts with file from package libkipi-0.1.5-4.fc9.i386
  file /usr/share/icons/hicolor/48x48/apps/kipi.png from install of kdegraphics-4.1.0-3.fc9.i386 conflicts with file from package libkipi-0.1.5-4.fc9.i386

Error Summary
-------------

I tried deleting these packages manually but that led into an even deeper’s rats nest of dependency hell. So one thing I tried was

$ sudo yum groupremove "KDE (K Desktop Environment)"
$ sudo yum --enablerepo=updates-testing groupinstall  "KDE (K Desktop Environment)"

However I still got conflcts so ran

$ sudo yum remove libkipi
$ sudo yum remove crystalsvg-icon-theme
$ sudo yum --enablerepo=updates-testing groupupdate  "KDE (K Desktop Environment)"

And finally I have got KDE 4.1.0 to install in way too many steps.

So recently I saw this when doing a svn checkout of a project and ran into the following:

$ svn co http://svn.somewhere.com/svn/projects
svn: Unrecognized format for the relative external URL ”.

Wonderful. This indicated to me there was a problem with the svn externals somewhere. After noodling a little I decided to Google around and found this. Basically, duplicate listings in your svn:externals is a bad thing.

Read more

There are many multiple file rename utilities that you can dig up.

One that I am used to on Debian/Ubuntu-based distros is called rename which is one that is derived from the Perl Cookbook. However, note that this rename script does not seem to exist on other UNIX variants in a packaged format. It definitely does not seem to exist on a Fedora Core 9 box I use nor does it exist on a FreeBSD machine.

While it would not be too hard to swipe the perl script and copy it in place onto a system. I hate having to remember moving that script around and around with me from place to place so I looked around for other equivalents and found one called mmv. One nice thing is that there are packages for at least FreeBSD, FC9, and Debian/Ubuntu variants so it should be quite lazy to install compared to rename.

Below I give an example of using it to do a multiple renaming where I want to append the value 1 to the end of a bunch of filenames.

$ ls
cat_100  cat_15  cat_200  cat_50  cat_500

$ mmv cat"*" cat#1_1
$ ls
cat_100_1  cat_15_1  cat_200_1  cat_500_1  cat_50_1

Doug Hellman’s svnbackup script tool is a really handy tool for setting up automated backups for a subversion repository.

However, the non-fun time comes when one wants to restore a subversion repository that has way too many dumpfiles parts. The instructions for restoration are basically ‘roll your own’ if you want to try to automate the restore procedure. What would be nicer is if there was the converse tool that made it easier to not have to figure out how to re-order the backup files in the proper manner in order to perform the restore.

I spent a few minutes thinking about it and wrote a small Ruby script to help with this that I call svnbackup-restore.rb. Here is the (hastily written) source code. (Download here)

#!/usr/bin/ruby
# Program Name: Restore the restore
# Purpose:      Take all the svn dumpfiles generated from svnbackup
#               sort them and try loading them via svnadmin
# Usage:        1. Create the new repo path with svnadmin create
#               2. Set repo_name to the repo backup file names
#               3. Set restore_path to the new path to restore to
#               4. Run it ./svnbackup-restore.rb
# Assumptions:  svnrestore-backup.rb is in the same dir as the svn dump files

# CHANGE PARAMETERS HERE
repo_name = 'myrepo'
restore_path = '/path/to/myrepo'

# Print out debugging?
DEBUG = true

# DON'T CHANGE BELOW

# Filename format is 'dumpfile---.bzip2'
svn_dumpfiles = Dir["dumpfile-#{repo_name}*.bzip2"]
sorted_files = svn_dumpfiles.sort do |a, b|
  left_rev = a.split('-')[2].to_i
  right_rev = b.split('-')[2].to_i
  left_rev  right_rev
end
sorted_files.each do |dump_part|
  results = `bzcat #{dump_part} | svnadmin load #{restore_path}; echo $?`
  puts results if DEBUG
  res = results.split.last.to_i
  if res != 0
    puts "Error on trying to load up #{dump_part}!"
    exit 1
  end
end

I’ve been trying out Firefox 3 and one strategy I do is to copy my Mozilla Firefox folder with me to whatever machine I go to so I don’t have to reinstall plugins, re-enter all my passwords, and configure everything about Firefox until I’m happy.

However, it seems due to some reason or another I lost the ability to install extensions. After Googling around I dug up a nice hint on Ubuntu’s Launchpad site.

Basically delete the file named extensions.rdf in your Mozilla directory

• Windows: C:\Documents And Settings\[Username]\Application Data\Mozilla Firefox\
• Linux (Fedora 9 and Ubuntu 7.10): $HOME/.mozilla/firefox/profile/MY_PROFILE/

Read the Ubuntu fix

Had a case where I had some rails app that was using files for its session store and had been running like that for months. While it was a careless (and dumb) thing to run it that way, we had to do something about it since it was eating up close to 85% of the system partition. The dumb way to try to do this is below:

nice find /tmp/ -name 'ruby_sess.*' | xargs -n 100 rm -fv

However, the problem is that this causes insanity on IO which is NOT good for a running service. (Luckily this service was merely important instead of critical) So, I present to you my quick and dirty script that will clean up all those nefarious ruby sessions files that have run amok for months.

while true; do
    nice find /tmp/ -name 'ruby_sess.*' | head -n 20 | xargs rm -fv; sleep 10
done

After a long time of not updating my trusty old iLamp iMac, I finally updated it to 10.4.11 over the weekend and let it lie. Later on I hear a report that Safari won’t start up.

That’s odd, I’ve never heard of Safari having launch problems before. I check the log and I see something like the following:

Date/Time:      2008-04-14 22:06:45.474 +0900
OS Version:     10.4.11 (Build 8S165)
Report Version: 4

Command: Safari
Path:    /Applications/Safari.app/Contents/MacOS/Safari
Parent:  WindowServer [86]

Version: 3.1 (4525.13)

PID:    20987
Thread: Unknown

Link (dyld) error:

Symbol not found: _WebDatabaseDirectoryDefaultsKey
  Referenced from: /Applications/Safari.app/Contents/MacOS/Safari
  Expected in: /System/Library/Frameworks/WebKit.framework/Versions/A/WebKit

Those type of messages go on and on in Console.app. My first round of Googling brought me to a Macrumors thread that recommended deleting the history.plist and other parts from ~/Library/Safari. I tried removing various files from that directory to no effect and finally just removing the directory altogether. Nada.

Troubleshooting a PC WITHOUT a web browser really sucks. I suggest everyone try it once in awhile to see just how much the nature of debugging IT problems has changed when you are deprived of a very powerful tool. Luckily, this Mac had a very crufty version of IE lurking so the first thing I tried was a download of Firefox. However, the disk image refused to be mounted! Seems this is also tied in with the security update. So basically, I’m left with using IE as my main tool for debugging on this Mac.

After a bit of googling, it seems that the fix is tied requiring the latest OS X security update (Available at the Support Download page). For OS X 10.4.x users you can find a link to the latest Universal here.

However, there is a catch. The security update is only available from that page as a Disk Image. Guess what you can’t open it up under the affected Mac. At this point you’re left with 2 options:

1. Burn the Disk Image to a CD-R/DVD-R and use it that way
2. Transfer the disk image to another Mac and unarchive it then push it back

I decided on the latter option since I hate wasting a CD-R if I don’t have to. After applying the Security Update and rebooting, Safari boots up and things seem chipper again but that was a serious side trip on something I’ve rarely seen Apple ever mess up. Anti-kudos to Apple for making this update on your ‘legacy’ OS really sucky.

Anytime I’ve been running a perl based script on my leopard box I got this really irritating output with whatever else I was expecting:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
     LC_ALL = "En_US",
     LANG = (unset)
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

With a quick Google search I found an answer in this Rubify post. Basically the solution / fix is to make sure the following is set in either your ~/.profile or ~/.bashrc or ~/.cshrc

# This setting is for the new UTF-8 terminal support
export LC_CTYPE=en_US.UTF-8
export LC_ALL=en_US.UTF-8

Read more at Rubify!

I love reading about these smart uses of waste byproducts I bet this might work well in Japan if it wasn’t for those pesky earthquakes.

A new data center in Switzerland is being used to heat a nearby swimming pool. In what appears to be a first, the town pool in Uitikon, Switzerland will be heated by waste heat from a data center

Read more at Datacenter Knowledge