Wednesday 19 October 2011

Source Control for Server Admin

So you manage a server, or a lot of servers alone or in a team, however you are doing this, you are going to be tweaking configuration files often and creating custom scripts for automation.  There are two tools I use for revision control - RCS for configuration files (generally) and SVN for scripts (generally).

RCS.  The classic.  All the documentation you will ever need is in the man pages.  Well that and some context for how to use it.  RCS creates revision files in place.  So if you change /etc/dhcpd.conf, it will create /etc/dhcpd.conf,v.  This is a very useful setup when controlling local files in arbitrary locations - like most of /etc on most of your servers.  There are a few caveats to keep in mind:
  • RCS will put revision files (the ,v files) in an RCS folder if present
  • The default behaviour is to remove a file from its current path on check-in
Keeping these in mind, this is my general pattern for working with files under /etc.
  1. If there is no RCS folder (e.g. /etc/RCS), create it first
    • mkdir -m 700 ./RCS
    • Assuming your working folder is where the file in question is, this will create an RCS folder and protect it from other users (typically non-root)
  2. If a file doesn't exist in RCS, check it in first
    • ci -u dhcpd.conf && co -l dhcpd.conf
    • ci is short for "check-in", unlike SVN or CVS, "ci" is the command and not an argument to "rcs"
    • The -u "unlocks" the file leaving it in place (so dhcpd can read it)
    • co is "check-out" and -l "locks" the file for editing
      • I always leave files checked out to capture changes by other users or by the system (like rpm)
  3.  If the file does exist in RCS, check for any un-committed changes
    • rcsdiff dhcpd.conf
    • This does a diff against the last checked-in version by default but you can specify a version if you want to compare against earlier changes
    • Check-in any un-committed changes or find the person who made the changes and make them do it
  4. The file should always be left checked-out (per above comment), otherwise check it out
  5. Make changes
  6. Check-in changes, and check-out the file for the next user
    • ci -u dhcpd.conf && co -l dhcpd.conf
    • Give a brief log message indicating what the changes were and again, leave the file checked-out to capture changes by the system or other users
Now the last useful command I'll mention there is rlog which lets you read the revision history log.

Now SVN is a proper centralized source control system.  They have excellent documentation on setting up a repository.  This is very useful for system admin scripts. 

Although most system administration related scripts won't ever have "releases" or "branches", you probably still want to follow the SVN guide and create at least a trunk in case you ever do need to tag a specific version.   There's no cost, so I use a trunk even though I've never used it because changing later is a problem.

With SVN you'll want to keep an updated local working copy ("tip") either on a shared NFS location or locally on each server.  How you do it is up to you, just create a cronjob to run "svn update /path/to/tip" and then you can always run scripts from that path.

RapidSVN is a great tool, well maybe not great, but works very well for sys admin anyhow and its readily available.  So check out your own working copy of the trunk with RapidSVN.  I configured RapidSVN to use gedit as my standard editor and meld as my diff tool.  

This gives you everything you need for day-to-day creating and maintain system configuration files and your toolbox of scripts for automated system maintenance.

Saturday 15 October 2011

Debugging Python Scripts

This is really just props for a site I found with a nice walk-through of using the Python Debugger - pdb.

http://pythonconquerstheuniverse.wordpress.com/2009/09/10/debugging-in-python/

pdb your built-in step-through debugger allowing you to inspect objects and all the usual things you need in developing a program.

Popular Posts