• Get with the (electronic) times

    Today I went to submit for reimbursement from my flexible spending plan. Since I scan in all my receipts, assembling the information was quite easy. Our plan allows us to use a "wizard" to prepare the reimbursement. It generated a PDF cover sheet with all the information filled out. I added all my receipts (stored in Paperless), filled it out using PDFPen, added my signature and had one massive PDF. The form said to mail it via USPS or fax it. Since I pay $0.10 per page to send a fax via j2, I printed out the 13 pages, shoved them in my fax machine and sent it (the fax number was toll-free, but I have unlimited calling, so it didn't matter). Now if I had been able to upload the PDF to their web site, I would have saved the paper.

  • Dealing with Ruby on Rails Applications

    When I first launched my first web site in Ruby on Rails (RoR) to get my store for ReceiptWallet (based on Potion Store) going, I learned a little bit about performance. A basic RoR application is launched each time a user hits a web site; this, of course, is only for development and isn't practical for a production site. I opted to use lighttpd and FastCGI which worked well. However, modifying an part of the application required killing processes and restarting lighttd.

    As a learned more about RoR and had to deploy more applications, I started using mongrel as we had a bug with lighttd that caused our application to not handle uploads. So I've been using mongrel for a bunch of RoR applications on 4 separate servers. Things work OK, but each time an application is updated, I have to either restart all of mongrel or kill individual processes and restart them (if I restart mongrel, non-updated apps get restarted and could disrupt people).

    Last night as I was trying to catch up on some of my research (quiet time is only at night and allows me to leisurely do research), I came across Passenger which makes deploying RoR simple. All I have to do is setup the virtual host and point it to the RoR's public directory and presto; this is in comparison to setting up mongrel with proxies from Apache. In addition, in order to restart an application after I update it, I just do 'touch tmp/restart.txt'. Wow, that's easy!

    Is Passenger the holy grail for managing my RoR applications? It's too early to know, but I'm optimistic.

  • Standard, but braindead implementation

    One of the features of OS X Server's LDAP is the ability to disable an account after X failed logins. While this sounds like a great thing to turn on from a security point of view, the implementation has a lot to be desired. I turned this on several months ago and within 30 minutes had to turn it off. The reasons why it is flawed are quite simple.

    Let's say you have a VPN, a mail server (incoming and outgoing), a calendar server and a chat server and you have the failed logins set at 4. Let's also say that your mail server and calendar server are accessible outside of your VPN so that handheld clients that don't have a VPN client can get in. Most, if not, all services on the Mac store your password in the keychain and many don't offer you the option to enter it each time (which actually would get quite annoying). Next, let's say you just changed your password using a provided mechanism (OS X server requires an add-on to offer this if you only use the LDAP server without all the other management capabilities). Within a few minutes, your mail client will check for mail with the old password, iCal will check your calendar with the old password, you might be sending mail with the old password, and you login to iChat using the old password. Boom, you just hit your 4 failed logins without you entering or being prompted for your password once.

    A much more intelligent way to do this would be to have the 4 failed logins be 4 failed logins with different passwords. So if you tried to login 20 times with the same password, it would only be recorded as 1 failed login. Would this weaken security? I don't think so, but could leave your server open for a denial of service attack. In that case, why not take an additional 10 seconds to authenticate for each failed login? So while it would take awhile to have your login fail, at least you could enter your new password without having to contact your administrator. If your administrator is any bit like me, password resets are not easy.

  • A fix for a broken web site

    Today I had to purchase a Priority Mail label off the USPS web site and had a few problems with it. First off, Safari decided to keep eating the sample label. I then switched to FireFox and doing a Save As for the label saved it, but the file didn't end in .pdf, so Preview wouldn't open it even if I forced it to open it. (Yes, Preview should have attempted to decode it.) Once I renamed the file with a .pdf extension, the file opened just fine. Hmmm...what should I do to automate the process?

    I remembered that I had a program called Hazel on my machine that watches folders and acts on them. I removed Hazel on my last machine because I was trimming things down (it got bogged down). I created a simple set of rules to change all files that start with com.usps to end in .pdf, open them and then trash them. Now I have to figure out more uses for Hazel as this is a great way to automate things.