The infrastructures mothership says the following about version control:
It may seem strange to start with version control. Many sysadmins go through their entire careers without it. But infrastructure building is fundamentally a development process, and a great deal of shell, Perl, and other code tends to get generated. We found that once we got good at “doing infrastructures”, and started getting more work thrown at us, we had several distinct infrastructures at various stages of development at any given time. These infrastructures were often in different countries, and always varied slightly from each other. Managing code threatened to become a nightmare.
Managing Unix systems has been either a hobby or a job for me since 1991. I have never, prior to this infrastructure management thing, ever put any of that work under version control. Nor did any other sysadmins in my acquaintance, as far as I know. The VMS folks had backup versions of DNS and other configuration files made automatically as they edited. The Windows folks didn’t have a whole bunch of text to sling around to begin with. And I guess the Unix folks just sort of winged it like I did.
I have occasionally used version control on more complicated development projects, for the usual reasons. Easier change tracking, automatic publishing of latest versions, etc. But if the code was simple and nobody else had to see it or use it, it was easier to just write it and let the automatic tape backups handle it from there.
Basics of version control server: Debian, Apache2, and Subversion. Apache SSL enabled following instructions from debian-administration.org. Subversion enabled following instructions in chapter 6. We use mod_authz_svn to handle usernames allowed commit access, and look up passwords from the domain’s Active Directory server. Relevant bits from the Apache2 config file:
<Location /svn> DAV svn SVNParentPath /usr/local/svn AuthzSVNAccessFile /etc/apache2/AuthzSVNAccessFile Satisfy Any Require valid-user AuthLDAPEnabled on AuthLDAPAuthoritative on AuthType Basic AuthName "CAE Subversion Repository" AuthLDAPBindDN cn=REDACTEDUSER,cn=Users,dc=cae,dc=tntech,dc=edu AuthLDAPBindPassword REDACTEDPASSWORD AuthLDAPURL ldap://REDACTEDSERVER.cae.tntech.edu:389/cn=Users,dc=cae,dc=tntech,dc=edu?sAMAccountName?sub? </Location>
where REDACTEDUSER with password REDACTEDPASSWORD has been delegated the authority to look up all account information in the Active Directory.
Normal mode of operation pretty much matches the latter parts of Subversion’s chapter 1, with the following exceptions:
- Every file that can contain comments gets a CVS-like $Id$ keyword. And since Subversion doesn’t expand those keywords by default, there’s a lot of
svn propset svn:keywords "Id" filenameright after filename gets added to the repository. - I end up working as root most of the time I’m in the local copy, even though I don’t have to. So there’s a lot of
svn --no-auth-cache commit --username mwrso that I get authenticated properly and my password isn’t saved anywhere on disk. I should probably just break myself of that habit. Maybe I’ll start editing everything with XEmacs and TortoiseSVN in Windows.
Hi Mike,
You’ve got a nice few pages listed here for the infrastructure stuff — keep up the good work.
Did you have to change/edit the way your AD domain works at all to get the above setup working? I’ve tried to implement the setup you have above, but not matter what tweaks I make (I had to alter it a bit for apache2.2), I can’t seem to get it to authenticate using AD domain credentials.
I know that I could probably install apache and subversion on a Win2k3 box and do it that way, but I really, really, don’t want to 😉
I can get it to work from an OpenLDAP auth source, just not from AD — any hints and tips???
Cheers.
Dameon.
I don’t think we had anything non-standard in our AD setup. I first had this set up with our university’s central AD, and I’m almost positive that one was completely standard, with no attempt to support Unix explicitly.
Two things to make sure of, though: first, the REDACTEDUSER account I use above needs to have some pretty substantial authority over the Users tree delegated to it (Read all user information), which puts it in several administrator-level groups.
The second would be to make sure there aren’t any typos in the AuthLDAPURL line. I accidentally had it broken across two lines until just a few minutes ago.