The Life of a Sysadmin

We're going to switch from CVS to Subversion at work. I don't make a whole lot of use of CVS, so the finer points of change management are more academic to me than anything else. But authentication...ah, that's a different story. Right now, Unix clients access the CVS repository by NFS; Windows users use the pserver protocol/authentication. NFS access does cause some problems for CVS, but it's completely out of the question for Subversion if you use their Berkely DB filesystem. It's okay for read-only access if you use their FSFS (actual real filesystem files filesystem; the equivalent of CVS' bunch of directories and files). This leads to questions about how we'll allow access over the network, and how we'll authenticate users. Here's my thinking so far.

1. Daemon + DB2
   • Pro: Can restrict access through file permissions to prevent access by NFS.
   • Con: Plain text password file. YAFPF.
2. svn+ssh + DB2
   • Pro: Secure access from home. SSH key-based authentication.
   • Con: The mirrored drive where the repository should be kept is available by NFS and Samba; this can't change. Since file permissions would need to be open to allow read/commit, there's nothing preventing access by NFS and resultant corruption. The other alternative is putting it on a non-mirrored drive, which isn't an option either.
3. Apache + PAM
   • Pro: Can restrict file permissions to prevent NFS/Samba access. Uses already existing FPF, and since we're not using PAM now we can eliminate AFPF. Prod to switch Samba to PAM, which would be AFPF gone.
   • Con: Haven't worked with A2, DAV or mod_auth_foo before. Since will need to coexist for a while with A1, possibility of calcification.
4. Apache + LDAP
   • Pro: Full buzzword compliance. One FPF to bind them all. Get ready for the groupware that will someday be coming down the pike. Can restrict file permissions to prevent NFS/Samba access.
   • Con: Haven't worked with LDAP, either. Will need to convert current password file rather than access directly, creating YAFPF (at least in the short term). Much bigger change, so even bigger danger of calcifictation. (Heh...I like that typo.)

I think I can do Daemon + FSFS, but I need to reread the Subversion book (truly excellent, BTW). This might be the best way to get things going quickly. And of course, any insights or hints are welcome.

Nicks' post on customizing your home was interesting. Over the last year or so, I've been slowly improving the way I do this. My results have been mixed, probably because of the way I use Mercurial.

So I've got a repo to keep my dotfiles. There's a truly awful script that will symlink the real files to the repo, and doesn't clobber the originals more than one time out of three. I clone to work, or to a laptop, and start customizing. Overall, I feel like this should work…but it's decidely awkward.

Let's take the case of bash init files. I've got mine divided into .bashrc and .bashrc_local. The latter, as you'd expect, is machine/situation-specific — ssh aliases, commands for work, etc. .bashrc sets various aliases and functions that are unlikely to change. Just before exporting all the environment variables, .bashrc_local is sourced, which gives me a chance to override anything.

.bashrc should be in the repo — no question about that. But .bashrc_local should be there too, since I may clone my repo at work (say) to another filesystem. Since Mercurial is distributed, there's no problem with this — except when it comes to merging things back home. Since I think about home as The One True Repo, I want to keep everything there. But usually I've run hg push ssh://home, which promptly clobbers .bashrc_local there (at least when I do an hg update. Or if I merge from home, I end up creating new heads in my repo, and a multi-headed repo can't be pushed. (I'm fuzzy on the details; usually when this happens I bang away at it randomly until merges happen, and swear until I'm blind.)

As outlined here, the difficulty is probably in the way I use Mercurial and the way I've become used to SVN's (and CVS's) idea of branches that look like directories (and are thus very, very visible and easy for me to think about). xyld says, "I'm fed up with having to do hg merge and not actually merge anything, but just to satisfy the Mercurial internals." That's pretty much how I'm starting to feel. There's the option of doing pull, rather than push, to cherrypick the changes I want, but it's still a bit awkward for me to think about.

I understand SVN; it fits well with my brain, which is not a developer's. I understand hg, and I like the idea of distributed repos for certain things. But xyld's comments about switching to git resonate with me, and I may start trying that out.

After this entry about the difference between push and pull for Mercurial, and how that doesn't fit with the way I instinctively want to use a repository, it's interesting to read Ted Tso responding to a similar complaint from a git user. Tso explains the discrepancy well:

Part of the problem here is that for most git workflows, most people
don't actually use "git push". ....in most large projects, the number
of people [who] need to use the "scm push" command is a very small
percentage of the developer population, just as very few developers
have commit privileges...

Ah, but in a distributed SCM world, things are more
democratic....While this is true, the number of people who need to be
able to publish their own branch is small....

There is one exception to this, of course, and this is a developer
who wants to get started using git for a new project which he or she
is starting and is the author/maintainer, or someone who is
interested in converting their project to git.

The whole entry, plus the comments, are worth reading.