Midnight Oil

Before we switched to Slicehost, we had our VPS on Rimuhosting. I must say that I was very pleased with Rimuhosting’s service, and we never had any problems with stability. We eventually had to switch to Slicehost anyway because it was simply cheaper and we’re on razor-thin margins here.

Still, switching hosts is not a trivial process, and you have to factor in the switching effort when deciding if the price differential is worth it. If you’ve found a cheaper host and are thinking about jumping ship, the very first thing you should do is contact your current provider and see if they’ll match the new host’s price. That’s what we did initially with Rimuhosting. They didn’t match the deal, but they did give us a little more RAM for free. That tided us over for another month or two before we decided we wanted to give Slicehost a shot.

So, for posterity, and to help other bargain hunters, here is the letter I sent, and Rimuhosting’s response.

I’ve been a Rimuhosting customer for several months now. In general I am happy with the service, although my server seems to be getting more and more sluggish in recent weeks.

Due to the performance issues, I began shopping around for alternatives and I came across Slicehost ( http://www.slicehost.com/ ). Since they’re a competitor, I’m sure you’re already familiar with them.

According to their price list, they will give me 256MB RAM plus more disk space for $20/mo, compared to the 160MB of RAM I’m getting for $29. For me, the RAM is the big deal, and the extra storage is just icing on the cake.

I am seriously considering moving to slicehost, as I am finding that the 160MB I currently have is eaten quickly by Tomcat, mongrel, and MySQL. Plus, as I mentioned earlier, I have been seeing some very serious performance issues lately, with slowdowns on ssh as well as terrible response times from the web server. This could be due to not enough memory on my VPS, but I’m concerned it has to do with too few CPU cycles being devoted to the VPS.

In all honesty, I would rather not switch hosting companies, as I have been pleased with the level of service from Rimuhosting. In addition, moving a VPS installation is no small task and I do not relish the idea of trying to replicate all my settings on a new machine. Still, Slicehost’s pricing plan is very attractive.

Before I make any decisions, I would like to ask what sort of plan you would be willing to offer in order to compete with Slicehost. If you could offer a combination of more RAM and a lower price, it would go a long way towards tipping the scales in Rimuhosting’s favor.

Thanks for your time and I look forward to hearing from you.

Micah Wedemeyer
http://www.aisleten.com

Their response to me:

Hi Micah,

I’ve added some additional memory to your VPS:

[root@obsidianportal ~]# free -m
             total       used       free     shared    buffers     cached
Mem:           300        148        151          0         16         55
-/+ buffers/cache:         76        223
Swap:           95          0         95

Also moved your current pricing from 39.95, to where our current MiroVPS2 plans are, at 29.95 a month.

We feel that we offer a good value for the service we provide. We appreciate your business and hope you will stay with us.

Recently, I went to a meeting of the Atlanta Web Entrepreneurs. They sponsored a presentation by John Sherrod of Primedia regarding Search Engine Optimization (SEO).

All in all, it was a good talk, and I didn’t feel too sleazy for being there. I was worried that an SEO talk would devolve into discussions of how to fool Googlebot into putting you at the top of the list for keywords like ’stud’ and ‘teen.’ Luckily, John stressed one main point on how to best climb the charts: provide high quality, original content that has value to your readers.

Beyond that, he gave many good tips that are applicable across a wide variety of sites. I’ll list off the ones that I was quick enough to write down.

John’s Tips

Make sure your links are spider-friendly

When the search engine spiders reach your page, they will rely on you to navigate them around. The only way they can find their way to all your pages is if there are links providing navigation to the each page. Also important, these links should be text links, not flash. The text of the link helps the spider identify the keywords to associate with the material on the page. Further, some links are incomprehensible, such as Flash or Javascript links. The more plain text you have, the friendlier it is to the spider.

Avoid URLs with lots of query string variables

I can’t say much to this one, since I don’t know how the spiders work. John, however, claims that they do not like URLs with lots of query string variables. In any case, these URLs are definitely not friendly to users, and they look ugly in a search result. Instead, allow the URL to express some sort of organization of your site. For example, compare the following two URLs:

http://mysite.com/products/jewelry/gold/diamond-tennis-bracelet

http://mysite.com?cat=44&subcat=92&prodId=2412145

Which one is more descriptive? They could be talking about the same thing, but it’s impossible to tell from the URL.

In the Rails world, URLs like this are fairly easy to achieve, thanks to routing. By implementing a few routes, you are able to clean up your URLs and make them look nice and pretty. Take a quick look at the official manual on routing and you’ll see just how easy it is.

On Obsidian Portal, we are trying to use nice, easy to read URLs for as much as we can. Currently, we’re not doing as well as we could, but that’s mainly because we have so many features we’re trying to implement. Making URLs look pretty is not exactly at the top of the list. However, we have had some success with campaigns and game content. For example, http://www.obsidianportal.com/campaign/kensing takes you directly to my campaign, called Kensing. In another example, http://www.obsidianportal.com/game_contents/show/memory-steel, takes you to an item I created called memory steel. That URL could use some cleanup, but you get the idea.

Unique <title> tag on every page

The search engines place a lot of weight on the words they find inside the title tag. So, make sure every page has keywords in the title. Personally, I am not a big fan of long, jumbled titles that are just a mish-mash of keywords. Instead, give each page a meaningful title that happens to contain 1 or 2 keywords related to the material presented on the page. This will give it a nice appearance in the search engine result pages.

Establish a baseline for your current stats

Before you can get better at anything, you need to know where you currently are. For search engines and page views, you need to establish your current baseline and then track your stats over time. Probably the easiest way to do this is by setting up a Google Analytics account. It provides a nice graphical view of how you are doing over time.

use link: on your competition

This is an excellent strategy for finding out why your competition ranks better than you. Go to Google and enter:

link:your.competitors.site.com

This will return a list of all the links (that Google knows about) to your competitor’s site. You may discover that they have several high-ranking incoming links that could also apply to you. Track these places down and see if you can get yourself listed there as well.

New friends and plans for next month

Besides listening to the SEO presentation, I also met a few Ruby on Rails developers here in Atlanta. Calvin Yu and Neil Green are members of the ATLRUG (Atlanta Ruby Users Group) and they’re working on a new site, but they asked me not to discuss their project just yet, so I’ll keep it under wraps.

Next month’s meeting will be a round-table discussion of various web technologies (such as RoR). I cornered the organizer after the meeting and offered to sit in as a RoR “expert.” Just don’t tell him how little I know

Ok, imagine that you have just created the most awesome website in the world for the greatest game ever, Dungeons and Dragons. Now, also imagine that no one knows about it. That’s about where I am right now.

Obsidian Portal has reached a stage where we are ready to begin beta testing. There is just enough functionality to make the site useful, and all that’s lacking is content. So now, I’m splitting my time between implementing features, adding content, and trying to think of ways to promote the site.

On my wife’s advice, I started looking around for college gaming groups. Lots of D&D groups form around colleges, and often larger organizations also form in order to help students find local games.

I finally managed to contact Mike Roselli of North Carolina State University. He is the president of the Collegiate Association of Table Top Gamers (CATTG), a multi-university organization dedicated to promoting table top gaming (including D&D and RPGs). Mike has expressed a lot of interest in Obsidian Portal, but he has some reservations about the fact that we are a for-profit enterprise. Perhaps I should tell him that we have a long way to go before we see anything that could be considered “profit”

The CATTG presents a wonderful opportunity for OP. If we can get exposure to college gaming groups and develop a core following, it would be excellent. For a shoestring-budget site like ours, the only kind of marketing we can afford is the word-of-mouth viral marketing. Luckily, that’s exactly the kind we want. Hopefully, we are on our way.

I went ahead and disabled the .htaccess password on Obsidian Portal. I guess I was way too optimistic that users would be trampling down my door. Instead, I think I just made an unnecessary obstacle to them getting in. Probably not a great idea.

It is free and clear now, so hopefully people will be more comfortable with using it.

Lesson learned

Unless you have a very good reason to restrict access, it is probably a bad idea.

After writing my last post about drowing in passwords, I started to wonder if my plan of partitioning passwords was just plain bad. There were some issues that were still bugging me:

• Keeping track of which password goes where
• Tracking the passwords in general (ie. how many do I actually have?)

After thinking for a while, I decided to try a password manager. I have tried one before, but for some reason it just didn’t work out. I cannot remember why, but these things usually boil down to ease and usability. If the program is slow or complicated, and takes significantly more work than just typing a password into a field, then I usually give up. Still, I have a lot more passwords to juggle these days.

I found a password manager called KeePass that looks pretty promising. In addition, there is a port, KeyPassX that runs on Linux and hopefully Mac OSX (although I am almost never on a Mac).

So, with a password manager, I just need to remember one master password. It is never transmitted over the network, and never displayed in plain-text (unless I write it down). This master password unlocks all my other credentials. I can store the password database on a USB drive, along with the KeePass binaries. Then, it’s just plug-and-play on any computer I want to use.

This means I need to add my USB drive to my “always there” kit. Currently that kit includes my wallet, cell phone, and keys. If I can figure out how to get my current USB drive on my keychain then that would be perfect, since I would just need to remember my keys, which I almost never forget.

New plan: password manager + keychain USB + different passwords for everything + changing frequently = maximum security with minimum hassle

Update: I’ve totally deprecated this plan in favor of using a passord manager.

I am becoming overwhelmed by the number of passwords I am having to juggle. As a single user, you probably have a couple passwords to remember. Onilne bank, home computer, work computer, e-mail, and maybe a few others. If you’re like me, you probably use one or two easy to remember passwords across all these arenas. Sure, you’re not supposed to, but anything more complicated just gets too hard. Besides what are the real odds that anyone is going to go to the effort of cracking your password?

Now, I am spinning up a website that I hope thousands of people will be coming to on a daily basis. That makes me a nice target for all the jerkos and script kiddies out there, which means I need to be more security conscious. On the other hand, I have several more credentials to remember. In fact, here’s a quick list of the ones I can name off-hand:

• subversion
• server root
• server normal login
• MySQL root
• MySQL Obsidian Portal user
• MySQL blog user
• MySQL forums user
• Obsidian Portal admin user
• Obsidian Portal normal user (Micah)
• Blog admin user
• Blog normal user (Micah)
• Forum admin user
• Forum normal user (Micah)

I’m sure there are some others that I’m forgetting here, too.

Obviously, certain credentials are more sensitive than others. If someone were able to crack the server root password, they could effectively shut the site down and cause a lot of problems. Likewise, cracking into the MySQL databases would allow for corruption of the data in nefarious ways. By contrast, if they cracked my Obsidian Portal normal user, they could log in and make comments or delete my campaigns. Irritating, but not show-stopping.

Tangential to a password’s sensitivity is its “risk profile.” By this, I mean that certain passwords are at a higher risk of being intercepted. Lowest risk would be passwords that never go out over the network^*. For instance, when this blog connects to the database, it uses a password that stays on the localhost, since the database is hosted locally. At higher risk are passwords that travel over the network, but are encrypted. SSH logins are a good example of this. Finally, the highest risk (hopefully?) are credentials that are sent in plain text over the Internet. Blog login, Obsidian Portal login, and forum login are all like this.

So how do I cope with this mess? Currently, I don’t…at least not very well. However, I have a plan. I will partition the set of credentials based on their at-risk status:

1. high - plain text over the network
2. med - encrypted over the network
3. low - localhost only

Then, I will use a single password for each category, and I will change them regularly, say once a month. I might even get rid of the low-risk profile altogether, for reasons noted at the bottom of this post.

Another option would be to partition the passwords based on sensitivity, but there is one big problem with this: you may not remember the rated sensitivity of a set of credentials in the future. So, is my subversion login high or medium sensitivity? This is a really bad situation, because if I cannot remember, I will simply start iterating through my passwords until I find the right one. Assuming someone is listening in, I have just given away all the keys to the kingdom.

So, here’s a question to the readers: How do you manage all your different identities? Automated tools? A good memory? Tattoos? I’d love to hear a better way than what I’m doing, as it truly does not sound all that secure to me. Still, it’s better than just using my dog’s name for everything…

^* Note that some of these “low risk” passwords are not as low risk as they may seem. This is because they must get to the server at some point. So, if you insecurely FTP a file containing one of these passwords, then it has gone out over the network in plain text, which makes it high-risk.