{"id":12,"date":"2007-04-30T20:35:43","date_gmt":"2007-05-01T02:35:43","guid":{"rendered":"http:\/\/blogs.cae.tntech.edu\/mwr\/2007\/04\/30\/infrastructures-version-control\/"},"modified":"2024-10-27T14:26:20","modified_gmt":"2024-10-27T14:26:20","slug":"infrastructures-version-control","status":"publish","type":"post","link":"https:\/\/sites.tntech.edu\/renfro\/2007\/04\/30\/infrastructures-version-control\/","title":{"rendered":"Infrastructures: Version Control"},"content":{"rendered":"

The infrastructures mothership says the following about version control<\/a>:<\/p>\n

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.<\/em><\/p><\/blockquote>\n

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.<\/p>\n

I have occasionally used version control on more complicated development projects<\/a>, 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.<\/p>\n

Basics of version control server: Debian, Apache2, and Subversion. Apache SSL enabled following instructions from debian-administration.org<\/a>. Subversion enabled following instructions in chapter 6<\/a>. 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:<\/p>\n

<Location \/svn>\nDAV svn\nSVNParentPath \/usr\/local\/svn\nAuthzSVNAccessFile \/etc\/apache2\/AuthzSVNAccessFile\nSatisfy Any\nRequire valid-user\nAuthLDAPEnabled on\nAuthLDAPAuthoritative on\nAuthType Basic\nAuthName \"CAE Subversion Repository\"\nAuthLDAPBindDN cn=REDACTEDUSER,cn=Users,dc=cae,dc=tntech,dc=edu\nAuthLDAPBindPassword  REDACTEDPASSWORD\nAuthLDAPURL ldap:\/\/REDACTEDSERVER.cae.tntech.edu:389\/cn=Users,dc=cae,dc=tntech,dc=edu?sAMAccountName?sub?\n<\/Location><\/pre>\n
where REDACTEDUSER with password REDACTEDPASSWORD has been delegated the authority to look up all account information in the Active Directory.<\/p>\n
Normal mode of operation pretty much matches the latter parts of Subversion’s chapter 1<\/a>, with the following exceptions:<\/p>\n
    \n
  1.  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\" filename<\/code> right after filename gets added to the repository.<\/li>\n
  2. 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 mwr<\/code> so 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.<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"
    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 … <\/p>\n
    Continue reading “Infrastructures: Version Control”<\/span><\/a><\/p>\n","protected":false},"author":87,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[],"class_list":["post-12","post","type-post","status-publish","format-standard","hentry","category-infrastructures","entry"],"_links":{"self":[{"href":"https:\/\/sites.tntech.edu\/renfro\/wp-json\/wp\/v2\/posts\/12","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sites.tntech.edu\/renfro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sites.tntech.edu\/renfro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sites.tntech.edu\/renfro\/wp-json\/wp\/v2\/users\/87"}],"replies":[{"embeddable":true,"href":"https:\/\/sites.tntech.edu\/renfro\/wp-json\/wp\/v2\/comments?post=12"}],"version-history":[{"count":1,"href":"https:\/\/sites.tntech.edu\/renfro\/wp-json\/wp\/v2\/posts\/12\/revisions"}],"predecessor-version":[{"id":507,"href":"https:\/\/sites.tntech.edu\/renfro\/wp-json\/wp\/v2\/posts\/12\/revisions\/507"}],"wp:attachment":[{"href":"https:\/\/sites.tntech.edu\/renfro\/wp-json\/wp\/v2\/media?parent=12"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sites.tntech.edu\/renfro\/wp-json\/wp\/v2\/categories?post=12"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sites.tntech.edu\/renfro\/wp-json\/wp\/v2\/tags?post=12"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}