At some point, I came to my senses and moved to IMAP, simultaneously moving back to hosted email (because, really, hosting an email server on a home machine is a mess), but with a provider that only hosted email.  IMAP was, at that moment, the ultimate solution to my issues of email being out of sync between multiple computers.  On the other hand, with IMAP, all of my email lived on the hosting company’s servers, so having an email hosting company that knew what they were doing was important.

The other major issue in the move to IMAP was filtering.  I had well over 100 filter rules in Eudora when I stopped using POP.  With IMAP, I no longer had to have filtering rules on every instance of my mail client, but I had to set up the filter rules in the framework allowed by my email host.  (One provider had a Bayesian filter system that could be set to learn from every message move made via IMAP, which was cool, but slow to learn and not accurate enough.)  As time went on, and through changing email hosting providers, this became very cumbersome (especially compared to using procmail on a receiving account, which is how I selectively filter the email that goes to my Blackberry).

When I finally gave up on the hosting company’s email filters, I had nearly 150 filters and there were dozens more I wanted, but just couldn’t be bothered to set up.  With 150 filters and no simple way to group and arrange them, managing the filters was impossible.  If I wanted to rename a mailbox that was the destination for a filter, I had to hunt down the filter and change it, which meant digging through a massive webpage listing of 150 filters.  But using an email hosting provider was non-negotiable for me.

After much searching for ways to run procmail on a remote IMAP account and finding nothing, I finally settled on trying imapfilter.  At first, dealing with the Lua scripting language used to configure it was tedious, but it was easy to learn and thus wasn’t a problem for long.  Now, a week into using imapfilter, my config.lua file is 372 lines long–it’s doing all the filtering I’d been doing through the email hosting company interface, all the filtering I wanted to do, grabbing some spam that persistently evaded the spam filter system, and automatically taking messages that I put in my Junk folder and sending them back to the spam filter system’s reporting address.  I have imapfilter running on a VPS (which I use for a variety of utility things) via cron job every few minutes.  When I want to add a new filter or change the behavior of an existing filter, I can just fire up (Mac)Vim, open the remote file, and apply the power of Vim for quick and easy editing.

It’s the biggest difference in my email use since the move to IMAP.  If you’re using IMAP and you want more powerful/flexible filtering, you should definitely look into imapfilter.

My experience thusfar with PTXL is that while they sent me login info almost immediately upon registration yesterday, they didn’t actually activate that info until about 20 hours later, so I couldn’t even *buy* the thing until today.  Now, I go to buy it and find that I have to add the money to my account, then use it to buy and that I can only add money through PayPal and that they charge a fee to add money through PayPal.  This makes their advertised price deceptive, though their quarterly pricing, even with the PayPal fees, is still quite reasonable.  Once I navigated the payment mechanics, the VPS turnup was almost instant.

My experience with Budget VPS/Web Wide is a bit different.  While the Web Wide site refers you to the Budget VPS site, the Budget VPS site kicks you back to Web Wide to actually transact business.  Strange.  Account creation was essentially instant, payment via PayPal was simple (no extra fees), and almost immediately yesterday, a VPS appeared in my account panel with status “pending.”  After a few minutes of this, I went digging through their knowledge base and it was suggested that while turnup is generally quick, it may take up to 24 hours or longer and that if it’d be over 24 hours, they’d email.  I was not thrilled with this, but I’d already paid and I’m not in all that much of a rush.  I came home tonight, about 30 hours after creation, to find it still “pending” and no email from them, so I’ve filed a support ticket.

Just for comparison, RapidVPS charges what they say they charge, no extra fees, deals directly with payment, no PayPal, and account creation and turnup are both really instant, no messing around.  I’ve also been using them for a while and they don’t seem to be vanishing into the mist anytime soon.  Oh, and when I was just starting out and had a few total n00b questions, they were really nice and helpful (at no extra charge!).

On the other hand, ssh is a very robust protocol and somehow ssh sessions seem to readily survive disconnect/reconnect cycles. Making use of this, it is possible to get a workable, if slow, connection to a passworded-and-sleeping Mac.  On one connection to the firewall machine, run a loop of the wake-on-LAN command so that the magic packets that make the Mac wake are being sent every second or so.  Use another connection to ssh into the Mac and do whatever you need to do.  It helps to plan out what you need to do so that you can get the commands in fast, but even during the cycle where the Mac goes back to sleep and gets reawakened by the wake-on-LAN loop, you can type commands; they just won’t appear (not even echoed) until ssh recovers the connection.

While this is an annoying way to use a machine and it’s probably not good for the hardware to cycle in and out of sleep repeatedly in such a short time span, it does give a way to get at a passworded and sleeping Mac remotely.

Over the past few years, as I’ve moved into VPS-based hosting, I’ve also started to use my VPSes as additional DNS servers, keeping the professional hosted-DNS for geographical and connectivity diversity.  As this incident has pushed me along in making sure that every domain I host has DNS from at least two different providers, I came to the conclusion that, given that I already have one commercial DNS host (giving me three nameservers), the best economics were for me to get a super-cheap VPS to run as only a nameserver.  While not the absolute cheapest, JustGotVPS.com is probably the best price-configuration balance, especially at their cheapest ($5/mo and $8/mo) plans, and they discount for longer-term prepayment.  There’s an entry for them, as well as numerous other VPS options around the $5/mo price point at lowendbox.com.

The tradeoff for this versus a commercial DNS host (since in both instances I’m paying about $60/year) is that the commercial host gives me three diverse nameservers but limits the domains, etc., whereas running my own VPS-based nameserver gives me only one host but substantially greater flexibility.  I would also note that I chose to get a cheap VPS box from some provider other than my primary VPS provider so that my new additional nameserver would not be in the same datacenter and on the same internet links.

I also have been using EveryDNS.com, a free DNS host, for additional backup (I’ve donated since I’m using them on several domains and they seem to provide a good service), but having used GraniteCanyon and others in the past, I don’t consider a free DNS host as a serious alternative to a commercially-provided option.

1. Verify that the slug can do Reset Button Upgrade Mode.
2. Get the Unslug firmware.
3. On the admin web page for the slug (default IP is 192.168.1.77), go to Administration > Advanced > Upgrade (default username/password is admin/admin), browse to the unslung firmware, and do the upgrade.  (This step takes a few minutes.)  Wait for the reboot.
4. Verify that the admin web page now shows the unslung firmware version.
5. Do any network config you need (set IP address, etc.)—avoid DHCP as it doesn’t seem to work (the slug does a DHCPDISCOVER, my server(s) do DHCPOFFER, but the exchange goes no further).
6. Enable telnet access (Home > Manage Telnet).  Note that this must be done before any disks are connected.
7. Telnet into the slug (username/password is root/uNSLUng).  Keep this session open through the next steps, so there’s guaranteed root access.
8. Plug the 1GB flash drive into the upper USB port (closer to the ethernet jack).
9. Once the slug recognizes the disk, go to Administration > Advanced > Disk and format the flash drive (Disk 2).  This again takes several minutes (especially with the cheapo slow 1GB flash drives I’m using).  When the page shows “Formatted (EXT3)” for Disk 2, it’s ready for the next step.
10. In the telnet session from step 7, type “unsling disk2″.  Enter a new root password here.
11. Reboot by typing “DO_Reboot” in the telnet session.  The device will beep when it’s fully booted.
12. Go to the admin web page and verify that it says “uNSLUng status:   Unslung to disk2, /dev/sda1″ in the bottom blue bar.
13. Enable telnet again and connect to the device again, verifying that the “NOTE: THIS SYSTEM IS CURRENTLY UNSLUNG” banner shows upon login.
14. Run “touch /.ext3flash” so that (after the next boot) the OS will try not to thrash the flash drive.
15. Verify internet connectivity (e.g. ping google.com).
16. Run “ipkg update” to update the package system.
17. Run “ipkg install openssh” so we can get to the slug without having to enable telnet.
18. Verify that SSH works by logging into the slug over SSH.  Disable telnet.
19. Run “ipkg install openssh-sftp-server” so we can use SFTP to edit files on the slug.
    
20. Set the admin web page password (it is independent of the root password).
    

Other notes:

• The MAC address label on the bottom of the device is the default device name and seems to be “LKG” + the latter half of the MAC address; it seems that the correct MAC address is found by replacing “LKG” with “00:18:39″.

On the Mac, however, I have tried several programs and never really been happy.  So I wrote a little AppleScript that not only sets up the SSH tunnel, but also deals with switching my location to set the system’s network settings to use the proxy (the code is after the cut).  Combine this with System Proxy for Firefox and all my application traffic goes through the SSH tunnel.  Note also that if you’re using a SOCKS5 proxy with Firefox, you probably want to set it to do DNS lookups through the proxy.

This script also stores the info for creating the tunnel (server, login, pw) in the keychain.

Here’s the “library” script where I put the functions to do the underlying work (since I have various different tunnels I use):

And here’s the actual script I run.

Well, first I learned from a mailing list archive post that under OpenBSD, the LEDs are easily controlled with gpioctl (using 0 and 1 for off and on):

That’s pretty easy, but it’s just on and off (though it does require privileged access to control the GPIO pins).  Poking around on the web today, though, I found Jordan Sissel’s blog post on making the Soekris net4501′s LEDs do the Apple-style pulsing fade-in-out.  His C program didn’t work straight away on my Alix, perhaps because he was working on FreeBSD and I’m using OpenBSD, but with a little digging in the OpenBSD source code for gpioctl, I was able to cobble together some C code to replace his “led” function that set the state of the LED as well as the device initialization.  With a little tweaking to make the code feel more like my own and to make the LED pulse just once (the original code pulsed indefinitely), I arrived at pulse_led2_once.c (which still must be run as root to work, since it uses the GPIO interface).

NOTE:  This file is provided “as is” and is not guaranteed to do anything at all, including not guaranteed to be safe to run.  It worked for me, YMMV.  I’ve posted my modifications having asked Jordan Sissel first; I’d appreciate it if you’d let me know if you wanted to post modifications to my code.  AFAIK, my inclusion of OpenBSD source was done in compliance with the copyright notice in their source file, reproduced as requested by the code I used.

The “Oh, DUH!” moment came today when I realized (after much mucking about with pulling various programs I needed from other OpenBSD boxes with more complete installs and running into various issues with version differences) that I could just download base43.tgz from an OpenBSD ftp mirror onto my Mac, unzip it, and sftp what I needed over to the flashdist machine, no other OpenBSD box needed.  Once I’d copied ldd over to the flashdist machine, I could even find out what libs I needed to copy over, too.

This means, of course, that I now have dhcpd and BIND running on my Alix.

Speaking of OpenBSD boxes, the Alix seems to be much closer to usable than I’d expected now, having restarted from a newer pre-built flashdist image.  The hokey thing I’d forgotten about is how few of the standard basic *nix command programs are in the base flashdist, so I end up copying over program after program from another running OpenBSD box.  I’m hoping to get BIND and dhcpd up and running soon, get pf all set up for router/NAT/firewall use, and try it out with a DSL modem before the weekend is up.

And, with a little luck, by the end of the weekend, all these various devices will be self-updating the various common config files (BIND zones, dhcpd.conf, etc.) from a common server.  I’ve already got a shell script that can check for an update to itself and replace itself with the newer version; I just have to make it check for and retrieve updates for the actual config files.