Posts Tagged ‘ VPS

Now in Chi-town

The server that hosts this blog has been relocated from Scranton, PA to Chicago, IL. Things might be unstable for a few days as the new configuration is finalized.

fancy new SSL, all thanks to Mercurial

As of today, I finally bit the bullet and installed a real (as in, not self-signed) SSL certificate for my server. It should validate with most browsers out there, but it was relatively inexpensive so I’m not sure how great the compatibility will be.

The main motivating factor was the new version of Mercurial became very irritating when pushing/pulling/cloning/etc from a remote https repository where the certificate was not able to be validated:

chuck@silverstone:~/Documents/cs433$ hg push --insecure https://charliemeyer.net/hg/cs433
warning: charliemeyer.net certificate with fingerprint b0:f2:09:06:87:32:b1:8d:cc:7f:51:09:07:28:44:45:8d:86:f8:fd not verified (check hostfingerprints or web.cacerts config setting)
http authorization required
realm: charliemeyer.net authentication
user: cemeyer2
password: 
warning: charliemeyer.net certificate with fingerprint b0:f2:09:06:87:32:b1:8d:cc:7f:51:09:07:28:44:45:8d:86:f8:fd not verified (check hostfingerprints or web.cacerts config setting)
pushing to https://charliemeyer.net/hg/cs433
warning: charliemeyer.net certificate with fingerprint b0:f2:09:06:87:32:b1:8d:cc:7f:51:09:07:28:44:45:8d:86:f8:fd not verified (check hostfingerprints or web.cacerts config setting)
warning: charliemeyer.net certificate with fingerprint b0:f2:09:06:87:32:b1:8d:cc:7f:51:09:07:28:44:45:8d:86:f8:fd not verified (check hostfingerprints or web.cacerts config setting)
searching for changes
warning: charliemeyer.net certificate with fingerprint b0:f2:09:06:87:32:b1:8d:cc:7f:51:09:07:28:44:45:8d:86:f8:fd not verified (check hostfingerprints or web.cacerts config setting)
bundling changes [ <=>                                                                                                                                                                                           ] 0
warning: charliemeyer.net certificate with fingerprint b0:f2:09:06:87:32:b1:8d:cc:7f:51:09:07:28:44:45:8d:86:f8:fd not verified (check hostfingerprints or web.cacerts config setting)
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 3 changes to 3 files

As you can see from above, not only is the extra noise irritating, but I also have to append “–insecure” to all of my commands. I know I could have modified my hgrc and imported my self-signed certificate, but I already had my global hgrc set up to recognize properly signed repositories:

[web]
cacerts = /etc/ssl/certs/ca-certificates.crt

I do a lot of work with remote hg repositories that do have valid certificates, but also a lot of work with hg repositories on this server, enough work that I didn’t want to import the self-signed certificate for each hgrc file in each clone of a repository I have on every one of machines. Plus, when I go to other machines, it would take a lot of unnecessary configuration just to get it to work properly.

So, to ease the irritation that Mercurial was causing, this server can now be accessed using a “more secure” https than before:

chuck@silverstone:~/Documents/cs433$ hg incoming
comparing with https://cemeyer2:***@charliemeyer.net/hg/cs433
searching for changes
no changes found

now running Ubuntu

After running this server for several months with CentOS 5.5, I have taken the plunge and reinstalled it with Ubuntu Server 10.04 LTS. Since this is a VPS, running fantastically courteously of BurstNet, there are several limitations that would not be encountered by a traditional server. The platform that this server runs on is OpenVZ, which has its own way of virtualizing containers. In particular, when running CentOS, it was almost impossible to run any Java application on this system due to the way that OpenVZ allocates memory for processes. Based on how I understand it, when launching a Java application, the JVM requests a large block of contiguous memory to run in. OpenVZ often fails to deliver the memory requested, which causes the JVM to fail. For some reason that I don’t completely understand yet, running Ubuntu in OpenVZ alleviates this problem. I’m thinking it has something to do with the way the Ubuntu template for OpenVZ was constructed. I run Ubuntu on all of my desktop machines, so I am looking forward to using the server variant here in the future.

So far, I have only restored basic services on this machine such as the basic LAMP stack for WordPress and such, but I’ll get SVN, Mercurial, Git, Tomcat, NX, SFTP, my Pylons applications, and such back up later this week. Stay tuned.