Archive for February, 2009

The Cost of the Penny

Back of the envelope here…

  • Time cashier takes to give me a few pennies in change: ~5 seconds.
  • Time I spend later fiddling with those pennies in my wallet while trying to get at other stuff: ~10 seconds.
  • Time I spend getting those pennies out of my wallet at some point: ~5 seconds.

Assume I am a typical US worker, making $20 an hour.

$20 / 60 / 60 * (5 + 10 + 5) = $0.11

Average change in pennies given by a cashier: $0.025

Thus, every penny you give me costs me 0.11/0.025 – 1 = 344% its worth. Not to mention your lost time.

Forget Energy, Health Care and Education, we need a penny ban now!

Comments

Removing Splashy

Splashy is a linux-boot graphical boot screen thinger. It aims to make your booting process into x11 more full of rounded corners and less of 1970’s terminal text streaking by.

Want to get rid of it? Well, make sure to purge it when you remove it, or your system will fail partway through the init scripts on the next boot. You won’t have x11 or networking or dbus. You will have a screen full of errors and a login prompt. So make sure you do:

sudo apt-get –purge remove splashy

However, if you already did just a apt-get remove splashy just like you’d do for any other package, and now your system suddenly won’t boot past 1980, what should you do? Kill the offending file.

sudo rm -ffffffffffffffff /etc/lsb-base-logging.sh

And reboot. Your system should come back up with networking and all. At this point you probably want to re-install splashy then re-remove it using the –purge option to get rid of all its last traces.

Comments (1)

How to force your Users into bad Password Management

This is straight off GoDaddy’s FTP user password requirements for their shared linux hosting plans:

You must create a password for your account. This means that your password:

  • Must contain 7 to 14 characters.
  • Must contain at least one lowercase letter.
  • Must contain at least one uppercase letter.
  • Must contain at least one number.
  • Must begin with a letter.
  • Cannot contain the user name.
  • Cannot contain the following characters: question mark, space, caret, single quote, double quote, colon, backslash, dollar sign, ampersand, greater than, less than, tilde, semi-colon, or accent.

The result of these kind of password requirements is that your user has to come up with a new password, or a new variation on one of their existing passwords, just for your site.  Now in the perfect world, users would have a unique password for everywhere on the internet they have a login.  There are programs out there to help users do that.  But guess what.  People don’t use them.  For some good reasons too – like now a copy of your passwords, one way or another, are being stored somewhere that isn’t your brain.  Which is the whole idea – your password is something that only you can produce and you can do so anywhere anytime you need to.

So in reality, your users likely have somewhere between 10 and 100 logins across the internet. If they’re forced to try to remember a special username/password combo for your site – they won’t. They’ll write it down, and stick in their wallet. Or in the drawer next to their desk. Or in a plaintext file on their desktop. Which is about as secure as, well, putting something yummy in the snack room with a sign that says ‘yummy’.

When a hosting provider like GoDaddy does this kind of bad practice, it isn’t that big a deal. It just makes their FTP user base more likely to be compromised. Now when your bank does it (I believe all my banks do it at one level or another) it’s serious. This isn’t helping the security problem – it’s just passing the buck. Even though this makes the average user more vulnerable to attack, that’s no longer your bank’s fault. It was you who didn’t safely guard your 7 different usernames, 3 levels of passwords, and up to 5 variations on those different passwords for your various logins across the internet.  That’s what I’m up to: 7, 3 and 5. Now soon to be 6.

As a user, what do you guys use to manage all your usernames/passwords?  As a developer, what kind of restrictions do you apply for your users’ passwords and/or usernames?  Do you know of any standard set of password restrictions, or any standard algorithm for computing what constitutes a ‘good’ or a ‘weak’ password?

Comments (1)

Ruby on Rails on DreamHost Installation

I’m no Rails expert, nor a Ruby expert, and this is only my second installation of Rails in 4 years, and my first on DreamHost.  So no promises.  But here are the steps I went through to get Rails working on DreamHost with MySQL.

  1. Set up a domain and directory. This where your Rails installation will live.  DreamHost’s preferred method of running Rails is now officially with Passenger (aka mod_rails) which they have on all their Apache 2 servers. You can use the DreamHost admin panel to set this up: go Domains->Manage Domains->Add New Domain/Sub-Domain and make sure to check off on “Ruby on Rails Passenger (mod_rails)”. If you plan on making ~/path/to/rails/root your root directory for your Rails installation, then you need set the web root directory to ~/path/to/rails/root/public when you add this domain using the DreamHost admin panel.

  2. Set up a database. You can do this through DreamHost’s admin panel as well.  Goodies->Manage MySQL->Create a new MySQL database.

  3. Set up Rails. Go to the directory you’re going to run your Rails installation out of (~/path/to/rails/root from step 1) and run:

    rails . -d mysql

    (Note the dot for ‘current directory’.)  This will create all the Rails directory structure and default starter files.

  4. Set the permissions. I’m not sure what the exact minimum possible permissions are to run Rails on DreamHost, but this created an acceptable situation for me for now: (note that I ran step 3 with a umask of 0027)

    find ./ -type d -exec chmod o+x {} \;
    find ./ -type f -exec chmod o+r {} \;
    chmod o-r config/database.yml

    You would absolutely want to lock these permissions down further if your application involved any sensitive data or services whatsoever. Leaving all your scripts world-readable allows any other DreamHost user to potentially scan your code and look for vulnerabilities.

  5. Do an intermediate test. At this point you should be able to navigate to your domain and see the Rails welcome page.  Note that the “About your application’s environment” link will not work in ‘production’ mode, DreamHost’s default. If things aren’t working, your friends are the logs in ~/logs/your.rails.domain.com/http and ~/path/to/rails/root/log.

  6. Set up the database connection. This involves editing the file config/database.yml.  DreamHost has its Virtual Hosts set up to default your Rails installation to run as ‘production’, but you can change this by setting ENV['RAILS_ENV'] in config/environment.rb.  Here’s a good way to do this automagically once you have development/staging/production sites all set up. After editing any of your Rails config files, you need to do:

    touch tmp/restart.txt

    to make sure Apache reloads the Rails config files on the next HTTP request.

  7. Test it. My test was to get the ’skeleton’ version of this project up and running by copying a few files into the Rails directory structure in the appropriate places.

Probability I find something wrong with these instructions in the next week or so?  ~80%.  I’ll update this post when I do.

Update:

Fyi, if you run the Webrick server in script/server, a DreamHost bot will auto email you telling you to please stop it:

From: DreamHost Policy Bot <support@dreamhost.com>
To: Michael Fogel <******@gmail.com>
Our automated system has come across the following activity under your account that is in violation of our Terms of Service.
We request that you take any necessary action to cease the activity as quickly as possible or we will be forced to take further action. If you were not aware of any such activity, please feel free to contact support and we can look into the issue further.

User **** running “ruby ./script/server”. This process is against our policies.

Please run ruby via cgi, not the built-in Webrick web server

They should add to this email a thinger about mod_rails being their preferred way to run Rails.

Update 2:

Ug, you can’t use HTTP Basic Auth with mod_rails (as of version 2.0.6). Note this is what DreamHost will set up for you if you use their web panel to set up authentication. Here’s a relatively simple if not elegant solution to the problem while we wait for mod_rails 2.1 to be released.

Comments

Stimulating a Deeper Hole

The Senate and the House are currently munching on their respective plans for our mind-blowingly large economy kick-start stimulus package. Super-mind-blowingly large.  How large is that?  Well, let’s compare this stimulus package to some previous expensive programs that have come to help define the US of A as a country and a people:

The version of the stimulus currently on the Senate floor: ~900 Billion. Wow. This is more money than has been spent on any project we’ve ever seen in our lifetimes – excluding those readers that are old enough to remember WWII.

So what should we spend it on? Well, how about stuff that will work to keep our economy and productivity on top of the world on a time span of similar scale to the dollar amount being spent – say 100 years? Hum, what should we invest in that’s going to be keeping us going then?

How about new minivans?? Everybody gets a new minivan for cheap! Courtesy of your tax dollars.

Or how about a fat chunk of money (say 50 Billion – enough for ~8 new bay bridges) to repave all our highways? That’ll let us get around really fast in our new minivans, right?

Wrong.

Investment beyond required maintenance in our decaying automobile system will function only to slow us down and help speed our competition up.  Every dollar that makes it easier to drive reduces demand for other transport modes – which slows our transformation to a balanced mode share.  It’s not just a break-even investment – say sacrificing long-term productivity for short-term convenience – it’s plain detrimental to our progress.

China is using their stimulus to transform their national transportation system. They’ll reap benefits from this investment through the 21st century.  We can learn a lot from a little compare/contrast here.

Stimulating new minivans and repaved time-wasting mere 80mph highways will just push us deeper and deeper into the very hole we need to climb out of.  Rather than trying fix an unfixable system, we should be focusing on introducing a viable alternative. We can’t expect 21st century growth and prosperity to magically appear out of a 1950’s solution to our modern-day transportation problems.

Comments