The building block of the VPS offering is a node: a discrete unit of CPU time, RAM, storage, and bandwidth. These nodes can be deployed as separate servers, or combined together to create a more powerful server. Servers can be upgraded or downgraded by attaching and detaching nodes from them. The CPU/bandwidth changes can be applied without rebooting, but to apply RAM and storage changes, the VPS needs to be rebooted so that the RAM reassignment can happen and so the VPS root volume can be rebuilt. You can bill nodes per month or per day. The daily option is more expensive, but allows you to throw an extra node or two at a server that’s being slashdotted until the traffic subsides — much cheaper in the long haul then monthly nodes. Daily nodes are also a good choice for a throwaway server you’re going to test something on and then scrap. The math suggests that if you’re going to be using the server for longer than two or three weeks, monthly nodes are a better deal.

To further sweeten the deal, nodes are portable across any of their data centers. While you can’t easily migrate deployed VPSes, you can destroy a server in one data center and create a new one in another using the same node. I look forward to the day when we’ll be able to live-migrate running VPSes across the country. Hopefully someone at VPS.NET is working on that…

Initially I had one node and this blog was about the only thing running on the server. Since then, I’ve expanded the services I host to my personal email server (hosting a few domains for friends too), a Git-based personal software forge, some services for Wikimedia, and a few odds and ends. While not a feature unique to VPS.NET, having root on your own server is really nice. Need some software? Install it. Want to tweak the firewall? Go ahead. I’m a hacker, so it’s nice to be able to use my server to just try stuff out and see what works.

Each VPS has CPU and network usage graphs so you can pinpoint busy times and optimize accordingly. There’s also a console for each VPS that connects directly to the offline OS terminal, allowing you to recover from a botched network or ssh config without involving support. While I’d like to claim that I’ve never had to make use of this feature, that would be a lie. I don’t often need it, but it’s there when I do.

Uptime has been pretty good all-around. I’ve had a few outages here and there: a SAN failure that the staff were not properly prepared for, causing a few hours of downtime; a bootloader issue with Debian caused by upgrading to squeeze (arguably not VPS.NET’s fault, as Debian decided to change the boot volume path); and most recently, volume corruption caused by upgrading my node, which the support staff remedied within minutes, but ideally should have never happened. (This makes me a bit reluctant to upgrade again without someone over there babysitting the box to make sure it boots up correctly.) However, these occurrences were not frequent. That’s three distinct issues I can recall since late 2009, two if you attribute the bootloader problem to Debian. This isn’t 100% uptime, but it’s pretty darn close to it, and support is usually quick to respond when problems happen.

I resell a few nodes to some friends and former business partners, and they’ve had very little issues getting started. It takes about 10 minutes to go from purchasing a node to having a running server. When a friend wants another server, I can deliver them their login credentials to a running server within about 15 minutes. That’s pretty cool.

There are a few network-level filtering things one should be aware of. VPS.NET monitors outgoing SMTP (port 25) connections and applies their own spam filtering, rejecting mail if it’s too spammy. Some people might like this since it can protect them from being listed on a spam blacklist if their server gets compromised. Since I run my own mail server and do my own filtering, I wasn’t pleased when this was deployed, especially since it was done so without any communication on their part. Once I figured out what was going on, I was able to opt-out of this filtering by filing a support ticket. I would have preferred more transparency about this change. Finally, as with most hosts, IRC ports are filtered bidirectionally. As I was wanting to use my VPS to run a service that collects data from Wikimedia’s real-time change notification IRC server (essentially just a data stream delivered via IRC) this was a bit of a bummer. They will not budge on this policy, which is disappointing.

Overall, I am a happy customer. Things don’t go wrong often, and when they do support is quick to respond. I’d suggest trying a daily node or two if you want to see if they are a good fit for your hosting needs; they’re only a dollar per day.

Enter Gazebo. I started this project last Friday night, so it’s only been about two days. Still, what I have right now is rather impressive for that amount of time. At face value, the current version is not very representative of the time that’s gone into the project so far, and for a very good reason.

The HTTP protocol used by web servers was not engineered around the idea that you’d establish a long-lasting connection with the server. It’s better suited for quick request-response cycles. Because of this, the PHP web service has no good way to maintain a connection to FICS.

The solution I came up with for this problem is simple, yet very involved. A daemon script (yes, written in PHP…) listens on a UNIX socket for connections from the PHP web service script. If a new FICS session is requested, it creates a new session and returns some authentication parameters to the web service. On every request to the service, another connection to the daemon is made over the UNIX socket, the session attached to with the authentication parameters, and some action taken, like “write this to the network socket” or “tell me when you get new data from the network socket” or even “close the network socket and destroy the session.” The daemon essentially acts as a super-proxy that persists the network sockets and enables access to all of them from one UNIX socket.

Yes, it’s kinda ugly. But it also works incredibly well. There is still some tuning to be done, but behold the awesomeness of what is essentially in-browser, color-coded telnet:

I don’t know what they put in the water either, but I bet Obama can fix it with his amazing super change-bad-stuff powers!

Did Delicious hire the Twitter engineers, or what?

At work we are working on an internal site that requires three columns (or to be more precise, up to two sidebars). I have never been completely satisfied with the many existing three-column hacks so I decided to roll my own after laying out some requirements:

• The unstyled page should look decent (primarily for mobile browsers). This includes having the sidebars come after the main content in the HTML source.
• The sidebar backgrounds should extend down to the header, without using any background image tricks.
• IE7 and FF2+ must render the layout correctly. Minor defects are ok in other browsers.

The sidebar backgrounds have always been the tricky part, but I have a non-image solution for IE7 and FF2+. It also works in Safari.

IE6 does not extend the background colors to the footer, but it does correctly position the sidebars at least. After a bit of hackery anyway. Apparently IE6 doesn’t correctly compute the correct X position for absolutely-positioned elements. left:0px was making the left sidebar overlap with the content. I replaced this with float:left and IE6 positioned it like the other browsers, and thankfully the other browsers continued to position it in the same place. So as a bonus, no IE conditional comments were required.

Anyway, here it is. I am releasing the CSS and HTML source to the public domain, but if you reuse the code a link to this post would be appreciated.