LO, forty years ago

Forty years ago this day, the first message was sent from one computer to a computer located at a remote site. In those days, different operating systems could not talk to each other, so the first network connections were made by connecting the campus mainframe to a smaller computer known as the Interface Message Processor (IMP). The IMPs from each campus could then talk to each other, and each institution only had to get their machine to communicate with the IMP.

On October 29, 1969, at 10:30 PM, Charley Kline at Stanford Research Institute (SRI) attempted to log in to the computer at UCLA. His machine successfully sent the "L" and the "O" as he typed the word "LOGIN", but when he typed the "G", the SRI computer recognized the command and tried to auto-complete it. The sudden burst of three characters overwhelmed the connection, and it crashed. but the "LO" got through, and is recognized as the first Internet message.

whitehouse drupal

The new media team at the White House announced over the weekend that the whitehouse.gov website has been moved to Drupal. Open source advocates are hailing this as a victory for open source over proprietary software.

Tim O'Reilly says:

This move is obviously a big win for open source. As John Scott of Open Source for America (a group advocating open source adoption by government, to which I am an advisor) noted in an email to me: "This is great news not only for the use of open source software, but the validation of the open source development model. The White House's adoption of community-based software provides a great example for the rest of the government to follow."

John is right. While open source is already widespread throughout the government, its adoption by the White House will almost certainly give permission for much wider uptake.

Dana Blankenhorn says:

The switch was designed to be transparent, but even a casual observer will note the site now features five separate blogs, and that officials’ names are now listed on announcements that read more like stories, often with personal details.

So it’s one small step for Washington, one giant leap for open source.

He also notes:

Sites like Whitehouse.gov are the ultimate honeypots for hackers and script kiddies around the world. This is true regardless of the party in power.

Because the White House is such an inviting target, the White House team needs to be extra vigilant.

Security expert Robert "RSnake" Hansen explains:

According to Dries Buytaert, “…this is a clear sign that governments realize that Open Source does not pose additional risks compared to proprietary software…” This is a complete fallacy. More than that, it’s a dangerous that non-security people are touting their knowledge of security as if it’s fact. Look, if you were talking about vulnerabilities per line of code or something, I may get on board with that statement, but that’s just not how the real world works. There is one very massive difference between open source and proprietary coded applications. I can pen-test Drupal all day long without sending a single packet to Whitehouse.gov.

That is, if the White House is actually using an unmodified ont-of-the-box version of Drupal. But if the White House is concerned at all about security, they have already hardened their copy of Drupal before going live:

Like ha.ckers.org they most likely chopped it up, removed all the unnecessary functionality, stripped it down to bare bones, locked the server up so tight it would be impossible to even upgrade it without an act of Congress and on and on…

The irony of all this, RSnake notes, is this:

And how is a locked down highly customized variant of Drupal different than a proprietary solution?

using gnu/linux for leverage

From Linux and Free Software:

Gillian was assigned to research GNU/Linux and found out that it would meet all the needs her department required and could be easily used instead of Microsoft Windows. Moreover, this switch to open source software would save them a lot of money.…However, like in all bureaucracies large or small, she still needed to get approval from the management. Little did she know that the management never genuinely wanted to switch over. Instead, they took Gillian's research and did what they wanted to do from the beginning. They used it as a leverage to get the Microsoft representative to get them a much better deal.

What's left unsaid is that this tactic can't work forever. At some point, Microsoft will be unable or unwilling to offer further discounts. Is the unnamed company willing to follow through with its threat if the boys from Redmond call its bluff? That's when we will see whether Gillian's research pays off.

postgresql setup 2: authentication and roles

After you've created the database cluster, it's time to set up authentication and roles.

Authentication is handled through the pg_hba.conf (HBA stands for Host-Based Authentication) file. This configuration file supports seven formats of authentication rules:

local      database  user  auth-method  [auth-options]
host       database  user  CIDR-address  auth-method  [auth-options]
hostssl    database  user  CIDR-address  auth-method  [auth-options]
hostnossl  database  user  CIDR-address  auth-method  [auth-options]
host       database  user  IP-address  IP-mask  auth-method  [auth-options]
hostssl    database  user  IP-address  IP-mask  auth-method  [auth-options]
hostnossl  database  user  IP-address  IP-mask  auth-method  [auth-options]

For a standalone machine where local users are trusted, a rule of:

local      all       all                 trust

is sufficient. If password authentication is needed, several methods are supported, including MD5 hashing, Kerberos, LDAP, SSL Certificates, and PAM authentication. The PostgreSQL documentation explains authentication in detail.

The next step is to create user roles. Once the user logs in, PostgreSQL needs to know what to allow the user to do. A role can be assigned to a user or a group.

To begin assigning roles, log in to psql. As user postgres, you can simply type psql on the command line.

If your username is myuser, and you want to be able to log into PostgreSQL and create databases, and you want to encrypt the password in the database, you can create the role like this:

CREATE ROLE myuser WITH CREATEDB LOGIN ENCRYPTED PASSWORD 'password1'

Except, of course, you'll want to choose a stronger password.

If you'll be connectiong to PostgreSQL through Apache, you'll need to create a role for the apache user. There's no need for Apache to create databases, so you can leave off that option.

CREATE ROLE apache WITH LOGIN ENCRYPTED PASSWORD 'letmein'

The PostgreSQL documentation gives all the details on creating roles.

That should be enough to get PostgreSQL up and running. You can no exit the postgres user and try connecting from your own account.

postgresql setup 1: create a database cluster

There are a lot of things I like about PostgreSQL: It does a great job conforming to the SQL 92 and SQL 99 standards, while at the same time it supports more than a dozen procedural languages. It's robust and scalable. It grows with your needs. It's well documented.

But there's one thing I don't like: It's a pain to set up. Well, maybe pain is an overstatement. But PostgreSQL does not just work out of the box; it takes a little effort to get it set up.

I recently set up PostgreSQL on a new machine running Fedora, and it took a little research to find all the necessary steps. I'm going to try to pull everything together here.

Part 1: Create a database cluster

A database cluster is the collection of databases to be managed by a database server. The initdb command sets up a cluster with two default databases you'll need to have: postgres, which is used by many third party apps, and template1, which will be the template for the databases you create.

The cluster must have a home directory. This can be located anywhere on the machine; popular choices, according to the PostgreSQL documentation notes that /usr/local/pgsql/data and /var/lib/pgsql/data. You may have to create the directory first, then chown it to user postgres.

Next, you'll need to log in as user postgres in order to run initdb. Confession time: I've never gotten sudo to work, so I always su to the user I want to execute the command as, then exit when I'm done. So su me.

So, the postgres user has no password by default, which means it's impossible to su directly to postgres. The only way I've found to execute a command as this user is to su root, and then su postgres. If anyone has a better way, or if you can explain sudoers configuration to me, let me know in the comments.

Anyway, as postgres, execute this command:

initdb -D /usr/local/pgsql/data

The -D option tells initdb what home directory to use.

That's all there is to creating the cluster, but don't exit the postgres user yet.

Up next: authentication and roles