paul lockaby - photos and essays from an engineer

Etherpad User Interface 2.0 [PROJECTS]

Mon, 06 Feb 2012 02:35:59 +0000

Adding ability to rename and change privacy on notepads. Updating interface to work well with mobile Safari on iOS. Fixing stripslashes problems.

Olympic Mountains at Sunrise [PHOTOS]

Sat, 04 Feb 2012 17:14:48 +0000

The Olympic Mountains at sunrise, as seen from Seattle over the Puget Sound.

Taken at 7:40AM on February 2, 2012
Copyright 2012 Paul Lockaby. All rights reserved.

OpenID Server Application 3.1 [PROJECTS]

Sat, 28 Jan 2012 08:32:42 +0000

* Cosmetic changes to make the interface very pretty when using iOS.
* Enable detection of cookie support to avoid errors when cookies are disabled.

Jake [PHOTOS]

Wed, 25 Jan 2012 02:54:45 +0000

In love with the snow. Well at least one of us is.

Taken at 3:56PM on January 1, 2012
Copyright 2012 Paul Lockaby. All rights reserved.

Etherpad User Interface 1.1 [PROJECTS]

Sat, 21 Jan 2012 09:25:15 +0000

Updated the installation instructions and added missing images. Also fixed the includes path for all PHP libraries. Removed some legacy functionality that was breaking the configuration options.

Special thanks to John McLear for finding most of these bugs and kicking my butt into releasing fixes.

Downtown Seattle at Night [PHOTOS]

Sat, 07 Jan 2012 19:53:42 +0000

Looking toward downtown Seattle from the roof of my apartment in Central District.

Taken at 1:32AM on January 1, 2012
Copyright 2012 Paul Lockaby. All rights reserved.

Etherpad User Interface 1.0 [PROJECTS]

Sun, 01 Jan 2012 21:39:38 +0000

Initial release of this new software.

OpenID Server Application 3.0 [PROJECTS]

Mon, 26 Dec 2011 03:42:20 +0000

Adds the choice of two authentication mechanisms: MySQL/database and pwauth/system authentication. Also fixes some security bugs in the login process.

OpenID Server Application 2.0 [PROJECTS]

Thu, 08 Dec 2011 03:38:38 +0000

This release adds these enhancements:
- Added profile editor for SREG communication.
- Added trust interface to allow the user to specify what SREG fields should be sent to the remote website.
- Added interface to add, remove, and modify users from the OpenID system.

This release features these bug fixes:
- Removed undefined warnings when no nickname, fullname, or email address appears on profile.pm
- Removed use of the forged header check because the OpenID protocol makes this check redundant and it wasn't working so well in my code.
- Fixed bug where DBI errors weren't being raised. (RaiseError was set to 0, not 1.)
- Fixed bug where the SSL version of the user's profile was being referenced in the OpenID endpoint. (Breaks some OpenID consumers when used with self-signed certificates.)
- Added extra checks on the user to ensure that someone is logged in before allowing certain actions.
- Updated documentation for installation and the default configuration to be consistent with one another.

Weave API Perl Modules 1.0 [PROJECTS]

Wed, 23 Nov 2011 00:19:00 +0000

OpenID Server Application 1.0 [PROJECTS]

Sun, 20 Nov 2011 20:39:35 +0000

So you want to generate self-signed certificates... [ESSAYS]

Sun, 30 Oct 2011 14:42:56 +0000

For whatever reason, you want to sign your own certificates for a number of domains that you run. You're probably doing this so that you can have a secure area of your site that only you log into. A self-signed certificate is definitely not a good idea if you are running a public facing encrypted site.

But we'll make this a little easier by signing each certificate with a certificate authority that we also control. This makes it really easy to download the CA and install it on computers that we may be using and avoiding the whole hassle of trying to "accept" it.

Self-signed certificates should be made as the root user. This is primarily because it'll be use by parts throughout your system. It's good to have your certificates stored in a location that is available to everybody but easily locked down. So let's make that location:



mkdir /etc/ssl.key

mkdir /etc/ssl.csr

mkdir /etc/ssl.crt

mkdir /etc/ssl.ca

We'll change the permissions on it later, once all of the certificates have been created. Now let's create the certificate authority so that we can sign our certificates. In this process it's going to ask you a bunch of information about your your signing authority. You can really fill in whatever you want. Just try to make sure that you remain consistent between each certificate that you sign, for no other reason than consistency is nice. The "common name" in this command can also be anything that you want.



openssl genrsa -des3 -out /etc/ssl.ca/ca.key 4096

openssl req -new -x509 -days 3650 -key /etc/ssl.ca/ca.key -out /etc/ssl.ca/ca.crt

That made a certificate authority file that is valid for ten years. I think that should cover you until well after the robots take over. Now let's create our first certificate:



openssl genrsa -des3 -out /etc/ssl.key/example.com.key 1024

openssl req -new -key /etc/ssl.key/example.com.key -out /etc/ssl.csr/example.com.csr

openssl x509 -req -days 3650 -in /etc/ssl.csr/example.com.csr \

    -CA /etc/ssl.ca/ca.crt -CAkey /etc/ssl.ca/ca.key \

    -set_serial 1 -out /etc/ssl.crt/example.com.crt

openssl rsa -in /etc/ssl.key/example.com.key -out /etc/ssl.key/example.com.key.insecure

mv /etc/ssl.key/example.com.key /etc/ssl.key/example.com.key.secure

mv /etc/ssl.key/example.com.key.insecure /etc/ssl.key/example.com.key

A few things to point out about this list of commands.

The first is that the value for "-set_serial" in the third command must be incremented for every certificate you generate. If you re-use a number, neither certificate will work.

The second is that when filling in details for this certificate, the "common name" must be the domain name for which you are signing the certificate. This can www.example.com or example.com or if you are feeling lazy it can be *.example.com. (Note that *.example.com will only sign one level of hostname. So that will cover foo.example.com but not foo.bar.example.com.)

The third is that there is a step in there where I create a copy of the private key and rename it to .insecure. What this step does is remove the password on the private key. If I did not do that, every time a service is started that needs access to the private key, I would have to enter a password when it started to access the private key. That's kind of annoying sometimes! So I disable that.

Now after we're done creating all of our certificates, we want to lock them up so that only authorized users can access the private ones and the public ones are accessible.



chmod 600 /etc/ssl.csr/*

chmod 600 /etc/ssl.key/*

chmod 644 /etc/ssl.crt/*

chmod 644 /etc/ssl.ca/*

chmod 700 /etc/ssl.csr

chmod 700 /etc/ssl.key

chmod 755 /etc/ssl.ca

chmod 755 /etc/ssl.crt

Once you've got these certificates you'll want to install them in four places: your local browser, your local Java installation, your server's Java installation, and your server's OpenSSL certificate location.

To get them into your browser is easy: just navigate to the ca.crt file from your browser and follow the instructions! On Mac OS, when you install it into Safari, it will just download the file. You can try to "Open" the file and that will install it into your Keychain and that will make it available to Safari and your entire operating system. On Windows, installing the certificate into Internet Explorer will also make it available to your entire operating system. You'll still have to manually install it into Firefox, Opera, Chrome, etc.

To get it into Java, you import it manually into the jssecacerts file, and that just takes this command on Windows, Linux, or Mac OS.



$JAVA_HOME/bin/keytool -import -alias root \

    -file /etc/ssl.ca/ca.crt -storepass changeit \

    -keystore $JAVA_HOME/jre/lib/security/jssecacerts \

    -noprompt -trustcacerts

And finally, to get it into your server's list of authorized certificates. On Debian this location is /etc/ssl/certs and you can link to it by just doing this:



ln -s /etc/ssl.ca/ca.crt /etc/ssl/certs/localhost.ca.crt

And now you've done it. If you need to add another certificate for a new domain name just repeat the step where you created example.org.

So you want to run MySQL with UTF-8 enabled by default... [ESSAYS]

Fri, 28 Oct 2011 01:51:53 +0000

The default character set for MySQL is Latin1. This is kind of silly because the whole world is indeed moving towards UTF-8. But you can change this! Because really, you most definitely want to support any and every language in the world. Or at least you want the potential to do that.

Are there drawbacks to working the database in UTF-8? There are only two drawbacks that I've encountered. The first is that a unique index on a UTF-8 column is limited to 333 characters. The second is that you have to configure UTF-8 onto every client with which you connect to the database. But otherwise it's really to use and set up.

All you really need to do is edit your my.cnf file. This file is in different places on different Unix systems and Windows systems. On Debian, for example, this is located in /etc/mysql and on Fedora it is located in /etc.

To make your clients connect and send UTF-8 data, set this in the [client] section:



default-character-set = utf8

You want to make MySQL communicate in UTF-8 and store things in UTF-8. To have the server do that, add this to the [mysqld] section:



character-set-server = utf8

Just a few other things that you probably want to add. For example, if you are going to use InnoDB it will create one giant file. This makes it slow to alter tables, add new tables, back things up, etc. You want to make InnoDB function like MyISAM: one file per table. To do that, add this to [mysqld].



innodb_file_per_table

If you expect to insert LOBs into the database, you will probably want to set this in the [mysqld] section:



max_allowed_packet = 1024M

Of course if you do insert a LOB, you will have some trouble backing up the database with mysqldump unless you add this to the [mysqldump] section of my.cnf.



max_allowed_packet = 1024M

You might also need to add --hex-blob as an option to mysqldump to properly get LOBs saved in a dump file.

And those are changes that I make to MySQL before starting it up for the first time.

So you want to automatically login with SSH... [ESSAYS]

Thu, 27 Oct 2011 12:08:23 +0000

Nobody really likes entering one's password repeatedly and sometimes you have automated jobs that need to log in remotely to other systems and you aren't there to enter a password. Fortunately, this is a really easy problem to solve. Depending on your local client -- Windows or Unix -- there are two ways to go about it. The server, on the other hand, is very easy to configure.

Let's look at Unix first. On the local computer -- the one from which you will be logging into the other -- run this command:



ssh-keygen -t dsa -b 1024

This will generate a key pair and ask you where you want to save it. The default is in the ~/.ssh directory and that should be where you put it. The second question will be if you want to put a passphrase on the key. Unless you want to continue to enter a password when you try to ssh between systems, do not enter a password here.

The two pairs to the key that were generated are id_dsa and id_dsa.pub. The former is your private key and should never be shared and will stay on this system. The latter, id_dsa.pub is the public key. The public key needs to be placed on any system to which you wish to connect.

On the other hand, if you are using Windows, make sure that you've downloaded the Windows installer. When you've finished installing it, you want to run PuTTYgen. Generate a standard SSH-2 RSA key with 1024 bits in it.

Once you've completed making a key, save the public and private keys somewhere on your computer where no one else can access them. You will use the private key in the near future. In the top of the window, where there is a read-only text box that says "Public key for pasting into OpenSSH authorized_keys file", copy that text and paste it into Notepad and save it into a file called id_dsa.pub. This public key needs to be placed on any system to which you wish to connect.

However, you are not done with Windows. To make PuTTy automatically log in to your remote server, you must also run Pageant. Pageant sits in the system tray and holds private keys. You must manually add each private key for Pageant to recognize them. You should place Pageant into your Startup folder so that every time you reboot it is loaded. And of course, you must follow these instructions to have Pageant automatically load your private keys on startup.

Great! Now let's put those id_dsa.pub files on your remote servers. Copy each one over using a secure transmission protocol, such as SCP. Then log into the remote system and run these commands:



touch ~/.ssh/authorized_keys

chmod 600 ~/.ssh/authorized_keys

cat id_dsa.pub >> ~/.ssh/authorized_keys

You'll need to copy each public key into the authorized_keys file. And then you're done. That's all there is to it. Now, every time you try to log into that remote server, you will never have to enter a password.

So you want to set up a firewall... [ESSAYS]

Thu, 27 Oct 2011 01:58:35 +0000

Let's say you have a server that is on a network and you want to only allow access to specific services, such as SSH, HTTP, and DNS. And you want this firewall to persist between reboots. Oh yeah, and you want it to work with both IPv4 and IPv6. This is an easy problem!

We're going to make a few assumptions:

You are running Linux -- distro doesn't matter

You have iptables installed, though this usually comes with the default installation of your operating system. You can see if it is available by running iptables --list.

You can run commands as root. iptables will only run as root.

Your IPv4 address is 1.2.3.4. (Please substitute your IPv4 address as appropriate.)

Creating a firewall with iptables is simple: you run the iptables command a few times, each time telling it a new rule, and it applies them, in order, to any packet that comes in. So if you first tell iptables to drop all packets and then tell it on the next command to accept some types of packets, the second command will never really run because the packets were all dropped in the first step.

First we are going to flush all of the rules that are present so we can start fresh:



iptables -F

The next rule, a very basic rule, will allow any existing and established connection:



iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Then we are going to accept any connection that comes from localhost or from ourselves:



iptables -A INPUT -s 127.0.0.1 -j ACCEPT

iptables -A INPUT -s 1.2.3.4 -j ACCEPT

It might be very useful to allow incoming ICMP requests. This will allow ping and traceroute on both sides of your interface -- incoming and outgoing -- to work successfully. For iptables this would look like this:



iptables -A INPUT -p icmp -j ACCEPT

For ICMP, this is the only instance where the -p flag is different between IPv4 and IPv6. Everywhere else you can pretty much replace iptables with ip6tables and it will work. That makes the IPv6 statement it look like this:



ip6tables -A INPUT -p icmpv6 -j ACCEPT

Once we've done those basic steps, we want to decide which ports we want to allow in. As listed above, we want to allow SSH, HTTP and DNS. In this example we are going to use the names of the ports, but it is very simple to replace "ssh" or "domain" with "22" and "53", respectively. Let's open up a few ports:



iptables -A INPUT -p tcp --dport ssh -j ACCEPT

iptables -A INPUT -p tcp --dport domain -j ACCEPT

iptables -A INPUT -p udp --dport domain -j ACCEPT

iptables -A INPUT -p tcp --dport http -j ACCEPT

iptables -A INPUT -p tcp --dport https -j ACCEPT

However, we want to limit people from connecting to our SSH server too quickly. To do that, we can restrict new connections on port 22 when the remote address has made more than four connections in sixty seconds:



iptables -I INPUT -p tcp --dport 22 \

         -m state --state NEW -m recent --set

iptables -I INPUT -p tcp --dport 22 \

         -m state --state NEW -m recent \

         --update --seconds 60 --hitcount 4 -j DROP

Finally, after allowing in all of the above connections, we want to drop anything else:



iptables -A INPUT -j DROP

Now that we've done this, our server will only accept outside connections on ports 22, 53, 80 and 443. But when we reboot, you will quickly find that everything was lost! Saving your firewall between reboots depends on the system. On Redhat-like systems -- CentOS, RHEL, Fedora -- this capability is built in:



/etc/init.d/iptables save

On Debian, you have to set it up yourself:



mkdir /etc/firewall

iptables-save > /etc/firewall/ipv4.conf

Then force the firewall to reload on the next boot by editing /etc/rc.local and adding this simple line:



iptables-restore < /etc/firewall/ipv4.conf

Now you've got a simple firewall set up.

Directions to Popular Hiking Destinations in Northern Virginia, Part 1 [ESSAYS]

Mon, 18 Jul 2011 01:05:22 +0000

Mary's Rock

Mary's Rock is without a doubt the shortest hike for the best view. A mere 2.2 miles round-trip, you arrive at the top for a 360 degree view of Shenandoah National Park. To get to the trailhead, you must pay a fee. Last I checked it was $15 to get in for seven days, but a year long pass is still just $30.

To get there, take I-66 west and exit at 43 onto US-29 southbound, toward Gainesville. Stay on US-29 southbound for about 13 miles until you begin to come up to Warrenton. As you approach Warrenton, the road will get wider and if you stay to the right where US-29 joins US-211. You want to stay on US-211 through Warrenton and then right back out of Warrenton. You will follow US-211 for about twenty-nine miles to Thornton Gap. The last section of this road will lead you up the side of the Shenandoah Mountains through a series of awesome switchbacks until you reach the top where US-211 intersects with Skyline Drive.

Get on Skyline Drive heading south, after paying the outrageous park fee. You will go through a tunnel and then past three scenic views on your left until you reach a parking lot that does NOT have a scenic view. This parking lot is actually for another trail but if you cross the road and and walk south about 100 feet, on the right you will see the trailhead for Mary's Rock.

The first part of the trail is blue blazed for 0.6 miles. You will pass a destroyed building that says no camping and eventually reach an intersection with the Appalachian Trail. Take a right and follow the ridge for another half a mile when you will see another trail marker and a spur trail to your left that is a straight path up to summit. So easy!

Mary's Rock

Sugarloaf Mountain

Sugarloaf Mountain is a privately owned mountain that is open to the public for the summer. There is no fee to get to the mountain but you should check that it is open before heading out there because it does close for the winter. It is also an incredibly easy hike with a great reward at the top. It does have a bit of a climb that is assisted with a staircase and there is usually a pretty big crowd at the top, too, so this is not a hike for solitude.

To get to Sugarloaf, head on I-270 northbound from I-495. Continue until I-270 narrows into a four lane highway and get off at Exit 22. At the bottom of the ramp, take a right onto MD-109, also known as Old Hundred Road. Continue on this road for about two miles until you come to Comus Road. There will be the Comus Inn on your right. Also on your right is a farmers market if you are so interested.

Head on Comus Road for between two and three miles until you reach a stop sign in the road and an open parking lot-like area. You can go straight, left, hard right or soft right. If the Mountain is not open, the soft right will be closed. Do not be tempted to take the hard right. It will take you nowhere. Follow the road up the side of the mountain until you reach the large parking lot at the top. There you will find the entrance to the short hike up to the view seen below.

Sugarloaf Mountain

Old Rag

Old Rag is probably the most popular hike in Virginia. However, it is in a portion of the Shenandoah National Park that has a fee. Last I checked it was $15 to get in for seven days, but a year long pass is still just $30. The park service has also closed the parking lot that is closer to the trail head in favor of having people park at a field that adds another mile to the hike.

But to get there, take I-66 west and exit at 43 onto US-29 southbound, toward Gainesville. Stay on US-29 southbound for about 13 miles until you begin to come up to Warrenton. As you approach Warrenton, the road will get wider and if you stay to the right where US-29 joins US-211. You want to stay on US-211 through Warrenton and then right back out of Warrenton. You will follow US-211 for 28 miles until you reach Sperryville. You will know you are in Sperryville because the road will change from four lane divided to two lane non-divided highway. Right after that change in the road, take a left to continue onto US-522 which will lead you through downtown Sperryville. Continue on US-522 for half a mile until you arrive at VA-231, also known as F.T. Valley Road, on your right, which you will take for about seven miles. When you see County Road 707, also known as Sharp Rock Road. When County Road 707 turns right and you see State Route 600 on your left, turn left onto State Route 600. Once on State Route 600, you will see the parking lot on your left because the park service blocks the road and forces you into the parking lot.

The hike itself can either be a 7.2 mile loop or a 5 mile in and out. I recommend the loop because you get to do a lot of scrambling on rocks to get up. To do the loop, you take a trailhead that starts at the upper parking lot -- which is now closed. The in and out trail starts a little farther back and you will know that you are on it because you will cross a stream on a bridge first. After taking a fire road for a few miles, you will reach a juncture and take a trail to the left that heads to the summit. This is really boring.

The loop, though, is much better. It starts out flat and a little boring but it gradually gets steeper and eventually you will start to have to work your way through climbing up rocks and then worming your way through holes in those same rocks. The views at the top continue for the last several miles of the trail. Be sure to be prepared for the fact that the top of the mountain is cooler than the parking area and will be windy. Also plan to take about six hours to do the whole hike, and perhaps longer if there are a lot of people at the parking lot who will back up the trail. But there is a reason that it is the most popular hike in Virginia.

Wolf Gap

The Wolf Gap Recreation Area is the trail head to two great hikes: Tibbets Knob and Big Schloss. The former is a hike for solitude, the latter has a better view but is more popular. There is also camping here when the park is open.

To get to Wolf Gap, which is situated on the border between Virginia and West Virginia, head out to I-81 and Exit 279 to Woodstock. However you are going to head west on VA-42, away from Woodstock. After about five miles you will pass a church on your right and you will cross a stream and you will see State Route 675, also known as Wolf Grap Road. Wolf Gap Road will cross the same stream again and take a left and parallel the same stream.

You will see several forks in the road but it is not until you see one that leads Wolf Gap Road, aka State Route 675, to the right. There will be a green sign that says Wolf Gap and points to the right. Continue on Wolf Gap Road until you arrive at the Wolf Gap Recreation Area. You will know that you've gone too far if you see a sign that says "Welcome to West Virginia".

Once you are at the parking lot, you can stay on that side of Wolf Gap Road and go to the trail head for Big Schloss or you can cross the road and go to the trail head for Tibbet Knob. Tibbet Knob is about three miles of easy hiking and has a big of climbing to get to the top and as said before provides lots of solitude. Big Schloss, on the other hand, is four miles that starts out straight up on a fire trail. Once you get to the top of the ridge it is another three miles of views until you reach a white blazed spur that will bring you to a 360 degree panoramic view called Big Schloss.

Warning: Use these directions in combination with a road map, a topographical map, and a weather report to ensure that you know where you are going and that you can arrive at your destination safely.

Downtown Vancouver at Night [PHOTOS]

Thu, 02 Jun 2011 22:39:37 +0000

Vancouver Skyline [PHOTOS]

Thu, 02 Jun 2011 22:27:25 +0000

To the left is Stanley Park. The road visible at the bottom is West George Avenue. In the back, just before the mountains, is English Harbour.

Taken at 7:32PM on May 5, 2011
Copyright 2011 Paul Lockaby. All rights reserved.

Capital Columns [PHOTOS]

Mon, 09 May 2011 00:29:37 +0000

These columns used to be part of the Capitol building until it was expanded in the 1950s. At that point in time they were moved to the National Arboretum in Northeast D.C.

Taken at 12:59PM on May 5, 2011
Copyright 2011 Paul Lockaby. All rights reserved.

Denny Lockaby [PHOTOS]

Wed, 15 Dec 2010 23:46:02 +0000

Tractor [PHOTOS]

Thu, 03 Jun 2010 02:02:49 +0000

Protesting [PHOTOS]

Thu, 25 Mar 2010 12:20:37 +0000

A man protests health care by continuously standing in front of the Capital Building simply holding an American flag.

Taken at 12:24PM on March 3, 2010
Copyright 2010 Paul Lockaby. All rights reserved.

Heading West [PHOTOS]

Sun, 07 Feb 2010 01:46:46 +0000

Orange Slats [PHOTOS]

Sat, 06 Feb 2010 19:46:15 +0000

Hains Point [PHOTOS]

Sun, 31 Jan 2010 01:37:48 +0000

An empty bench overlooks the Potomac River. Reagan National Airport is unseen in the background through the falling snow and the dirty clouds. A winter day.

Taken at 2:29PM on January 1, 2010
Copyright 2010 Paul Lockaby. All rights reserved.