Having driven in from Raleigh to attend this conference I had a rather high set of expectations.  It’s a considerable investment to leave the office for three or four days and drive three and a half hours.  This conference would not disappoint!  Columbia is a wonderful place to hold a conference of this size.  The hotels are an easy walk from the conference center.  There are a lot of excellent dining establishments all within the same area.  I didn’t have to go far to attend the conference, sleep or eat.  I decided to drive this time but I would have been just as well off had I flown.  I didn’t really need a car once I got here.

The support that this conference has gathered in its four years of existence is simply amazing.  The sponsor list included companies such as Microsoft (yes, they were here), Oracle, Red Hat, Verizon, Linode.com, Google and many others.  The support from the City of Columbia was also very impressive.  Mayor Benjamin welcomed us on the first day and reinforced his excitement and support for the conference.  It’s obvious that Columbia is making a big push to become a technology center.

Since I help produce a few conferences a year I spent some time looking over the visible POSSCON operations.  I am always looking for better ways to put together our show.  Here are a few lessons that I picked up this week:

• Internet access is an issue at other conferences beside ours.  When you bring a few hundred (or a few thousand) people into one place for the day they will take down your connections.  The Internet connections here worked all day although they were a bit spotty at times.  There are just too many smart phones and laptops out there.  Overall I think it worked well.  With some patience I didn’t have any severe trouble with communicating when I needed to.
• QR codes were used to great effect during registration and on our ID badges.  It did slow down registration on the first day but once the main first day registration was over it moved fairly well.  There are clear advantages to using this technology.  The obverse side of the name tag held a QR code with all of my contact information.  I could easily pass off this electronic business card to anyone with a smart phone bar code scanner.  The reverse side of the badge held QR codes with internal ID numbers.  I assume these were used to keep track of my registration and what days I attended the conference.  I did notice that glare from the big windows played around with the bar code scanners a bit.  Once we turned the name tag away from the glare they worked without a hitch.
• We need to do a better job of getting electricity out to the floor of our conferences.  POSSCON had electricity within easy reach in every room.  I found myself having to recharge my laptop and phone multiple times during the week and this was most appreciated.
• Give aways at the end of the day was a nice touch.  It does a good job of keeping people’s attention all the way to the end of the day.  I wonder if there is a way that we could integrate this idea into our conferences?  Alas, I did not win one of the coveted Galaxy tablets but it was nice to mingle and hear the applause for all of the winners.
• One of the conference staff grabbed me at lunch on the second day and asked me to fill out a quick online survey (again tied into my QR codes).  I think this is a great idea and something we should seriously pursue.

At the end of the day I am very excited to have been able to attend this conference.  Unless something similar pops up in Raleigh I will likely add this to my annual list.  Thanks POSSCON for putting on such a great conference!  I am excited to hear about what is in store for next year!

Geocaching Swiss Army Knife

Shortly after I started Geocaching I discovered Geocaching Swiss Army Knife (GSAK).  GSAK is an excellent database application that is geared towards tracking all of your caching activities.  I rely on this one program to load thousands of caches into my GPSr, keep track of what I have found (as well hidden) and all of the recent activity in caches I haven’t yet found.  In my experience it is the best program written for this purpose.  There are other applications that can do parts of what GSAK can do but none offer the same complete package.

Sounds great, right?  The only problem I have with this program is that it is written for Windows.  There is no Linux port!  Since I run Ubuntu on all of my mobile computers (and even my work computers), I can only use it on my Windows computer at home.  This (for me) was limiting.  Of course Windows users don’t have a problem with this.  For us Linux users however, we are simply stuck if we need to reload our GPSr units in the field or do any research while we are out of range of the internet.

Wine Is Not A Windows Emulator

Over the years I have tried numerous Linux based tools trying to replace this functionality.  Each time I eventually gave up and went back to doing it in Windows.  One day recently I decided to give the latest development build of Wine (WINe is Not an Emulator) to see if GSAK would work at all.  In past revisions of Wine GSAK would either not load at all or would crash and burn shortly after loading.  After updating my laptop and giving it a shot I found out that it works!  I was able to finally load GSAK and browse around the program without crashing.  What a relief!

So, how did I get it to work?  My Linux distribution of choice as of this writing is Ubuntu 10.10.  The default version of Wine that is in the Ubuntu software repository is version 1.2.  Don’t try to run GSAK in this version as it will not work.  You can find detailed instructions on how to install Wine 1.3 below (summarized):

Run the following commands on the command line:

sudo add-apt-repository ppa:ubuntu-wine/ppa
sudo apt-get update
sudo apt-get install wine1.3

These commands will install the latest version of Wine automatically.  If you already had Wine installed then the upgrade will remove version 1.2 first.  I had the most success by manually deleting the Wine version 1.2 /home/user/.wine directory.  Opening Wine version 1.3 will create these files again from scratch.

You need Wine version 1.3 or higher to make GSAK work.

After you have installed the latest version of Wine and created the new configuration files, download the latest version of GSAK.  Open the command line and browse to the downloads directory.  Enter the following command to install GSAK:

wine GSAK772B56.exe

Latest version of GSAK

Now that the software is installed you can start it up, enter your licensing information and get started!  Once I had finished the installation and tried out a sample database, I was ready to start putting this to use.  I solved the issue of getting the software to work in the first place.  Now I had to solve the problem of portability.  How can I move my GSAK installation around with me wherever I go?  I have desktops at work and at home, a laptop and a netbook.  That’s a lot of devices!  I could be using any of them at any time so what happens when I have my netbook but GSAK is on my laptop?

Dropbox solves this problem nicely.  I am running this service on all of my computers to synchronize my important files everywhere I go.  With so many computers it is virtually impossible to keep up with where my data is.  Dropbox takes care of this completely.  I went to my Windows computer and copied my existing GSAK settings files to my Dropbox folder.  Once you have copied the settings files over you will need to change the Application Data, Database Folder and Backup Folder paths in Tools – Options – General.  As you move from computer to computer GSAK will open up and pull in the latest database information.  It really is seamless!

It is seamless however, until I try to open GSAK on my one Windows computer.  The Application Data and Database Folder settings survive the transition from Linux to Windows.  The Backup Folder path does not change.  It still looks for the last path used.  If you want to back up the database in Windows you have to manually change the options coming and going from Windows.  I posted a note in the GSAK forum asking that the Backup Folder be turned into a variable instead of a hard coded path.  Hopefully that will change in future versions.

So What Doesn’t Work In Windows?

There are two areas of GSAK that still doesn’t work with Wine:

• Split Screen View – This feature doesn’t work at all.  It loads the first cache when the program loads but never loads another one after that.  Sometimes the program crashes when it tries to load.  I only run this view when I am on my Windows computer and I have to turn it off before I go back to Linux.
• Macros – Most of the macros that I am accustomed to using work well in Linux.  Only the macros that require Windows drive letters won’t work in Linux.  That doesn’t affect me very much so I haven’t spent much time on it.

It really works!

So there you have it, GSAK works in Linux!  There are still a few kinks to be worked out but considering that a few months ago it wouldn’t even load properly this is enormous progress.  I hope more of my fellow Linux users will start running it.  Perhaps we can get the last few glitches worked out at some point and have the same functionality as our Windows brethren.  Happy Caching!

Today I needed to generate 1350 passwords. My favorite tool generates them 50 at a time. What is an IT guy to do? The first thing is to start Googling around. After a brief search I came across a linux utility called makepasswd. After a few command line entries and some brief cleanup in a text editor I was ready to go!

To Install makepasswd (in Ubuntu):

sudo apt-get install makepasswd

To generate the passwords:

makepasswd --chars 8 --count 1350 | cat >> /path/to/file/passwords.txt

The end result is a quick and dirty file of passwords ready to be handed out. These may not be the most secure but they are certainly several orders of magnitude more secure than if I let my folks pick their own. I think I’ll dump the website generator from now on. I have an easy to use and powerful Linux utility right at my fingertips!

Mandriva -> Mageia

Mandriva is becoming Mageia.  My first successful foray into the world of open source software (way back in 2002!) was made using Mandriva (called Mandrake way back then) as the operating system.  At that time I was running the current version (Mandrake 9.2).  I started building linux servers using MandrakeLinux 10.0.  There were some rough spots in the road for those of us hosting servers with this product.  Things had a nasty way of changing on us during upgrades that would bring down mission critical systems until I could figure out where the configuration files had moved to without warning.  Once they changed the name to Mandriva and created a subscription based Club membership I knew that my days were numbered.  I hated the thought of having to pay for the club repository so that I could install the software that I wanted.  I switched to Ubuntu about three years ago and never looked back.

After following Mandriva’s various staffing decisions and financial woes it would appear that a large part of the development team has decided to fork the project.  Many of the management decisions that Mandriva (the company) made over the last several years have been disastrous for the end users of Mandriva (the linux distribution).  I for one am glad to see the community taking back control of this project.  I am watching this project very closely, having signed up for the mailing lists and spending a good bit of time in the IRC chatroom.  If this project gets off the ground I will strongly consider switching back!  You can start following the project at http://mageia.org.

OpenOffice -> LibreOffice

I must admit this announcement caught me a bit by surprise:

On the morning of September 28th, a community of developers and other volunteers announced that they were forming The Document Foundation to fulfil the promise of independence written in the original OpenOffice charter. According to the group, “The Foundation will be the cornerstone of a new ecosystem where individuals and organizations can contribute to and benefit from the availability of a truly free office suite. It will generate increased competition and choice for the benefit of customers and drive innovation in the office suite market. From now on, the OpenOffice.org community will be known as ‘The Document Foundation.’”

After OpenOffice.org was organized by Sun the project got off to a good start but then stagnated.  Now there is not much development and the product is falling further and further behind.  After Sun was purchased by Oracle, it would appear to be falling behind even faster.  All of that changes with this announcement.  I hope that Oracle steps up and does the right thing by donating the name (OpenOffice.org) to the community (The Document Foundation).  This would put the project in a similar arrangement to the one between The Mozilla Foundation and Firefox.  I will be paying close attention to the developments of this project as well.  You can follow along as well at http://www.documentfoundation.org/.

It’s a great day for freedom!

Add the following lines to /etc/postfix/master.cf. You could also copy the smtp line and rename it to something else. I use the term slow in this example.

# Outbound rate limiting
slow unix - - n - 1 smtp
-o syslog_name=postfix-slow

Now add the following line to /etc/postfix/transport. You can rate limit as many individual domains as you wish using the transport file. Don’t forget to postmap transport when you are finished. You should also have transport_maps set in /etc/postfix/main.cf.

domain.com slow:

The last step is to add the following block of code to /etc/postfix/main.cf:

# Outbound rate limiting
slow_destination_rate_delay = 120
slow_destination_concurrency_limit = 5
slow_destination_recipient_limit = 100
slow_connection_cache_time_limit = 0
slow_never_send_ehlo = yes
slow_connect_timeout = 5

This code forces a delay of 120 seconds between connection attempts. It also forces five concurrent connections at any one time. The current postfix default is 10. I’m not sure I would go lower than three for an organization of our size. It also limits recipients to 100 per connection attempt. Don’t forget to restart the postfix daemon after making these changes!

/var/lib/mailman/archives/private/listname

drwxrwsr-x  50 root mailman 4.0K Jul 26 13:17 .
drwxrwx--- 312 root mailman  20K Jul 29 14:04 ..
drwxrwxr-x   2 root mailman 4.0K Jul 29 13:36 2010-April
-rw-rw-r--   1 root mailman  13K Jul 29 13:35 2010-April.txt
drwxrwxr-x   2 root mailman 4.0K Jul 29 13:36 2010-February
-rw-rw-r--   1 root mailman 8.7K Jul 29 13:35 2010-February.txt
drwxrwxr-x   2 root mailman 4.0K Jul 29 13:36 2010-January
-rw-rw-r--   1 root mailman  21K Jul 29 13:35 2010-January.txt
drwxrwxr-x   2 root mailman 4.0K Jul 29 13:36 2010-July
-rw-rw-r--   1 root mailman  34K Jul 29 13:35 2010-July.txt
drwxrwxr-x   2 root mailman 4.0K Jul 29 13:36 2010-June
-rw-rw-r--   1 root mailman  25K Jul 29 13:35 2010-June.txt
drwxrwxr-x   2 root mailman 4.0K Jul 29 13:36 2010-March
-rw-rw-r--   1 root mailman  24K Jul 29 13:35 2010-March.txt
drwxrwxr-x   2 root mailman 4.0K Jul 29 13:36 2010-May
-rw-rw-r--   1 root mailman  22K Jul 29 13:35 2010-May.txt
drwxrwxr-x 569 root mailman  20K Jul 29 13:35 attachments
drwxrwx---   2 root mailman  24K Jul 29 13:36 database
-rw-rw-r--   1 root mailman  38K Jul 29 13:36 index.html
-rw-rw----   1 root mailman 2.7K Jul 29 13:36 pipermail.pck

/var/lib/mailman/archives/private/listname/2010-July/

drwxrwxr-x  2 root mailman 4.0K Jul 29 13:36 .
drwxrwxr-x 94 root mailman  12K Jul 29 13:36 ..
-rw-rw-r--  1 root mailman 2.5K Jul 29 13:36 002505.html
-rw-rw-r--  1 root mailman 2.2K Jul 29 13:36 002506.html
-rw-rw-r--  1 root mailman 2.5K Jul 29 13:36 002507.html
-rw-rw-r--  1 root mailman 4.4K Jul 29 13:36 author.html
-rw-rw-r--  1 root mailman 4.4K Jul 29 13:36 date.html
lrwxrwxrwx  1 root mailman   11 Jul 29 13:35 index.html -> thread.html
-rw-rw-r--  1 root mailman 4.4K Jul 29 13:36 subject.html
-rw-rw-r--  1 root mailman 5.1K Jul 29 13:36 thread.html

/var/lib/mailman/archives/private/listname/database/

drwxrwx---  2 root mailman  24K Jul 29 13:36 .
drwxrwxr-x 94 root mailman  12K Jul 29 13:36 ..
-rw-rw----  1 root mailman  31K Jul 29 13:36 2010-July-article
-rw-rw----  1 root mailman 4.4K Jul 29 13:36 2010-July-author
-rw-rw----  1 root mailman 3.9K Jul 29 13:36 2010-July-date
-rw-rw----  1 root mailman 4.6K Jul 29 13:36 2010-July-subject
-rw-rw----  1 root mailman 3.9K Jul 29 13:36 2010-July-thread

/var/lib/mailman/lists/listname

drwxrwsr-x   2 root    mailman 4.0K Jul 29 13:17 .
drwxrwsr-x 194 root    mailman  12K Jul  6 21:51 ..
-rw-rw----   1 root    mailman 1.7K Jul  6 21:51 admindbpreamble.html
-rw-rw----   1 root    mailman 8.9K Jul  6 21:51 config.db
-rw-rw----   1 root    mailman 8.9K Jul  6 21:51 config.db.last
-rw-rw----   1 apache  mailman  14K Jul 29 13:17 config.pck
-rw-rw----   1 mailman mailman  14K Jul 29 00:54 config.pck.last
-rw-rw----   1 root    mailman  12K Jul 27 18:42 digest.mbox
-rw-rw----   1 root    mailman  189 Jul  6 21:51 handle_opts.html
-rw-rw----   1 root    mailman 1.1K Jul  6 21:51 headfoot.html
-rw-rw----   1 root    mailman 3.1K Jul  6 21:51 listinfo.html
-rw-rw----   1 root    mailman 4.1K Jul  6 21:51 options.html
-rw-rw----   1 mailman mailman   46 Jul 29 00:54 pending.pck
-rw-rw----   1 root    mailman    2 Jul  6 21:51 request.db
-rw-rw----   1 mailman mailman  13K Jul  6 21:51 request.pck
-rw-rw----   1 root    mailman 1.2K Jul  6 21:51 roster.html
-rw-rw----   1 root    mailman  198 Jul  6 21:51 subscribe.html

After setting these permissions the mailman server resumed normal operations.  It looks like apache will take over the files that are edited directly from the web interface.  That should be ok.  The main problem is giving mailman read/write access to the files that it needs to update and maintain the mailing list archives.  Trust me, if mailman can’t access any of these files it will move the message quietly over to the /var/spool/mailman/shunt directory.  Nobody wants that.  Once you resolve any permissions issues be sure to restart the mailman daemon.  To remove e-mail from the shunt directory run /usr/lib/mailman/bin/unshunt.

/var/log/mailman/error

Jul 26 12:25:43 2010 (2755) Uncaught runner exception: [Errno 13] Permission denied: ‘/var/lib/mailman/archives/private/listname/index.html’Jul 26 12:25:43 2010 (2755) Traceback (most recent call last):

File “/usr/lib/mailman/Mailman/Queue/Runner.py”, line 112, in _oneloop

self._onefile(msg, msgdata)

File “/usr/lib/mailman/Mailman/Queue/Runner.py”, line 170, in _onefile

keepqueued = self._dispose(mlist, msg, msgdata)

File “/usr/lib/mailman/Mailman/Queue/ArchRunner.py”, line 73, in _dispose

mlist.ArchiveMail(msg)

File “/usr/lib/mailman/Mailman/Archiver/Archiver.py”, line 217, in ArchiveMail

h.close()

File “/usr/lib/mailman/Mailman/Archiver/pipermail.py”, line 324, in close

self.write_TOC()

File “/usr/lib/mailman/Mailman/Archiver/HyperArch.py”, line 1094, in write_TOC

toc = open(os.path.join(self.basedir, ‘index.html’), ‘w’)

IOError: [Errno 13] Permission denied: ‘/var/lib/mailman/archives/private/listname/index.html’

Jul 26 12:25:43 2010 (2755) SHUNTING: 1280155615.876646+a19c8dce602a83897d29592d36d618fc80195ec7

>>I ran several times check_perms -f and it says all is fixed.

>

>

> check_perms is lying (actually, there are many files, as opposed to

> directories, that check_perms doesn’t check). The above file and all

> files in /var/lib/mailman/archives/private/ excluding those in

> /var/lib/mailman/archives/private/*/database/ need to be group

> writable.

>

> Once you fix these permissions, you could run bin/unshunt to add the

> shunted messages to the archive, but there is an issue in that the

> messages have been successfully added to

> /var/lib/mailman/archives/private/mylist.mbox/mylist.mbox, and

> unshunting will add them again.

>

> Rather than trying to fix archive permissions, I suggest you verify

> that /var/lib/mailman/archives/private/mylist.mbox/mylist.mbox

> contains all the lists posts from inception to date, and mayby verify

> there are no stray “From ” lines in message bodies with bin/cleanarch,

> and then stop Mailman and rebuild the archive with

>

>  bin/arch –wipe listname

>

> and then start Mailman. This way, the pipermail archive will be

> completely rebuilt with correct permissions.

>

> This is one reason why I always recommend when moving lists to just

> move the LISTNAME.mbox/LISTNAME.mbox file and build the archive on the

> new machine with bin/arch.

>

> Note if you do this, remove the shunted messages from qfiles/shunt/ so

> they don’t accidently get unshunted in the future.

GNU Mailman

We have a long running history with this software.  Sometime around 2003 I was tasked with setting up a mailing list solution for the Conference.  Several of our local churches had also expressed interest so I had to find something cheap, scalable and fast.  GNU Mailman was the perfect choice.  It’s free and open source software, you can continue throwing lists at it and it supports lists of all sizes.

The list server is my oldest Linux installation.  I was a lowly Windows admin at the time so my good friend Alan Swartz helped me with the original Red Hat installation.  My how times have changed.  Back then I had a brief list of commands to create new lists, reboot the server and perform a few basic administrative tasks.  I wish I had kept a copy of that original handwritten list but alas, it is lost to the sands of time.  This software has proven robust over the years as it has moved across several physical computers and 3-4 different Linux distributions.

Victims of our own success.

It would seem that too much of a good thing always lead to problems.  The mailing list server maintains an archive of all of the e-mail that is sent over each of the mailing lists.  These files grow over time as new messages are sent.  Over time disk space can become a problem.  It took us several years of constant usage to amass a corpus of around 80 gigabytes (GB).  Mailman must have changed how it stores e-mail because over the course of a year or so we shot up to around 280 GB.  Maybe people realized that you can send attachments to the lists?  Once things get back to normal I plan to dig into why these list archives are growing so quickly.

Everyone loves a good history lesson but why is the server down today?  The simple answer is that the hard drive is full (again).  Once it fills up the mailman daemon stops responding.  Since I am out of the office it could take me a good while to discover that the system is down.  That’s why I decided to go ahead and replace it.

On June 17th the system went down due to a full hard drive.  With the building move coming up soon I decided to try temporarily remove the larger archives from the internal mailing lists.  This would free up enough hard disk space to keep the server running (hopefully) until well after the building move when I could properly schedule an outage.  I’ve been monitoring the disk utilization since then, moving archives as I can.  Unfortunately, I’ve moved all of the larger ones and was forced to move forward with plans to switch the drive.

Last night I pulled the 320 GB drive and replaced it with a 1.5 Terabyte (TB) drive.  It takes awhile to copy the archives back to the new drive however.  Overnight 60 GB of the 280 GB data store copied.  I expect progress all day and will bring the system back online as soon as I can.  Hopefully this will buy us a good bit of time before I have to permanently retire some of the archives.

Update: Friday, July 9th 2010 @ 12:17 PM
The list server is back up!  We have plenty of available disk space now.  I’m hoping that this one will last us a good while.  I still need to research what is eating so much disk space but moving forward we should be in good shape!

Google’s Chrome OS project, first announced in July, will become available for download within a week, we’ve heard from a reliable source. Google previously said to expect an early version of the OS in the fall.

Hardware support is a problem with all operating systems upon launch.  I hope the Mini 9 is supported soon…

What can we expect? Driver support will likely be a weak point. We’ve heard at various times that Google has a legion of engineers working on the not so glamorous task of building hardware drivers. And we’ve also heard conflicting rumors that Google is mostly relying on hardware manufacturers to create those drivers. Whatever the truth, and it’s likely in between, having a robust set of functioning drivers is extremely important to Chrome OS’s success. People will want to download this to whatever computer they use and have it just work.

We expect Google will be careful with messaging around the launch, and endorse a small set of devices for installation. EEE PC netbooks, for example, may be one set of devices that Google will say are ready to use Chrome OS. There will likely be others as well, but don’t expect to be able to install it on whatever laptop or desktop machine you have from day one. Google has previously said they are working with Acer, Adobe, ASUS, Freescale, Hewlett-Packard, Lenovo, Qualcomm, Texas Instruments, and Toshiba on the project.