2013-04-21
RCS should not be your first choice for version control
A while back I wrote that sysadmins should version control everything and kind of advocated using RCS for it. Based on one link to the entry I think that I may have confused people here about the merits of RCS, so let me clarify a bit.
RCS is a very old and rather primitive single-file version control system. Today it only has two real virtues: it works on single files and it's trivial to start using it on text files. It's not your best choice for a version control system in most circumstances, merely the easiest to start using so that you have some version control. And you want to have version control. If you're working on whole directories (and you should be if possible) any modern VCS is both better and more convenient than RCS. I'm partial to Mercurial for this but anything that you and your coworkers like will work fine. If you're already using git for other things and thus know it well, go with git.
(There are some situations where RCS may be a better choice. If you run into them you'll know it.)
Similarly, if you have a choice between using RCS on your configuration files and setting up good automation using Chef, Puppet, CFEngine, or whatever, you should set up automation. Full scale automation will get you much further than simply version controlling your configuration files in place on all of your different systems. Again, using RCS is the basic first step; you should start using it because you can do so right now and RCS is better than nothing. But once you've taken the first step you should keep moving towards an even better environment, not stop.
(I'm simplifying the issues surrounding full scale automation a lot, but again this is basic advice. Most people are better off automating and if you're going to automate, most of the time you're better off using a standard framework for it.)
Why a free SSL Certificate Authority is not horrifying
Back in this entry I casually mentioned in passing that there is a CA that will give you completely functional SSL certificates for free. To some people this will be horrifying; after all, as the story goes, SSL certificates are supposed to cost money so that they mean something and verify your identity (well, your website's identity).
The truth of what is going on here is that these free certificates contain exactly as much verification of your identity as everyone else's. In fact they may contain more verification, because this CA actually performs automated tests to verify that you have some control over the domain you want a certificate for; I don't know how much checking other CAs do besides making sure that they can charge your credit card. This particular CA is simply being honest about how much this particular 'service' costs to provide, ie essentially nothing. So they give you basic SSL CAs for free and charge you if you want additional features.
(There are a number of CAs that will give you free but short duration SSL certificates for testing purposes. This CA gives year-long ones and will happily issue you new ones for the next year.)
Given my long-standing irritation with what I've called the SSL CA racket, I'm kind of glad that there is a CA that is willing to be honest about exactly what's going on. If it horrifies people and offends them that such a CA is trusted by browsers, well, good, maybe it will spark a little reflection about what SSL CAs are really providing and not providing.
On a pragmatic basis, given that SSL certificates are a commodity and you can now obtain this commodity for free (which demonstrates its actual natural price) I see no reason to pay for basic SSL certificates any more.
(I continue to not name the SSL CA for a number of reasons including that I don't feel like doing their marketing for them. It isn't difficult to work out what CA it is, either with some web searches or by checking the SSL certificate chain for the website I mentioned in the earlier entry.)
Sidebar: what I mean by a basic SSL certificate
By a basic SSL certificate I mean one for a single name without wildcards. Single name certificates are slightly inconvenient but my impression is that SNI support is now common enough in both servers and (modern) clients that you can deal with this if you have to.
(I was pleasantly surprised about how few things I tried had problems with SNI after I set it up on various subdomains of my personal domain. Of course smartphones may complicate this pleasant picture.)