Posts for May 2008

2008-05-03: Kerberos v4 ending soon

This Thursday, we did the largest part of the final phase of Stanford's Kerberos v5 migration. Our account services database system has now moved from Solaris to Debian, from Oracle to MySQL, and from Kerberos v4 to Kerberos v5. This has a lot to do with why I've been exhausted this week (I've worked over 50 hours and will probably do some more work this weekend).

We're at the very end of a project that's been ten years in the making. Stanford first deployed Kerberos v4 in 1992 using the Transarc AFS kaserver as the KDC, with the full intention that it would be temporary until we moved to some Kerberos v5 implementation, probably Transarc DFS. Sixteen years later, we're finally turning off the OpenAFS kaservers and going to Kerberos v5 exclusively on May 15th.

Various people at Stanford have been working on this project fairly continuously since the late 1990s, particularly Booker Bense and Roland Schemers (Roland has now moved on to other things). I started taking responsibility for it about five years ago and it became my major project three years ago when we finally got funding to finish it. It's the biggest project of my career to date.

When we finally got funding and I was able to start working on it for a substantial percentage of my time, I went into the project with the intention to solve the large problem and do it right whenever possible. That meant trying to enhance the software where it was deficient rather than working around it, solving the large problem, and trying to improve the world and not just Stanford. Stanford University has been extremely supportive of that goal, and as a result, what's come out of the last three years is a bit staggering to look back on.

I was feeling rather down earlier tonight, mostly because I'm exhausted. It's been a very intense past six months, a very tiring week, and I've not had the energy and attention for other things that are important to me. But I started thinking about everything that we've been able to do as part of this project and realizing just how big this is and managed to cheer myself up a lot. Five years from now, ten years from now, thirty years from now, this is still something that I'm going to be proud of. That's a great feeling.

I was going to write up more specific details of how to tackle a project like this and do it right, listing some of the concrete results as examples, but yeah. Exhausted and low energy. Maybe I'll just do it over the next two weeks as a lead-up to May 15th. Immediately after that I'm going to the AFS and Kerberos Best Practices Workshop in part to talk about many of the things that we've written.

And then, for the first time in three years, all of my major projects will be cleared and I'll have several months to catch up on everything else, recover, and gather my thoughts before deciding what the next big project will be.

2008-05-05: Debian status

Tonight, I converted the XML-Security-C package from Stanford's internal Subversion repository to Git and packaged 1.4.0, but unfortunately I can't upload yet because Xalan needs to be updated to build against the latest Xerces-C. (I'd NMU, but I should not be taking on more things right now.) This is the first of the three current Shibboleth packages, and I hope to tackle OpenSAML and Shibboleth SP tomorrow or Wednesday.

An Alioth project for Shibboleth packaging now exists and the pkg-shibboleth-devel mailing list is being created. I've requested Git space on git.debian.org, and as soon as that's set up, I'll push the three existing repositories. Shibboleth 2.0 packaging will add at least three more packages (OpenSAML 2.0, Shibboleth SP 2.0, and another XML support library), possibly four if we have to package log4shib, but I still hope to use the standard log4cpp. And then there will be another couple of packages once the group packages the Shibboleth IdP and WAYF, which I hope someone with more Java experience can tackle.

One of the main goals for getting this set up is so that people other than me can do more of the work so that I can work on other things. Like, for example, krb5 packaging. Bastian Blank started using the Kerberos server packages and posted a whole flurry of bugs, a couple of which are (somewhat arguably) RC, and I'm trying to absorb that and fix the ones I can ASAP.

OpenLDAP is in desperate need of attention, but I don't feel as much responsibility for that. I said going in that I'd only have time to work on it in fits and starts, and just because no one else has any time to work on it either doesn't change that. However, I do need to find time to post an RFH, since it really needs an active maintainer, and I'll at least find time to upload the upcoming 2.4.9 release before lenny freezes more, since the current version has a ton of bugs.

Frank Lichtenheld has been doing a lot of the work on Lintian lately, which is wonderful, but I still have at least 10 bugs and patches that I want to deal with as soon as possible for it and get another upload out. We're well over my magic threshold of 100 bugs, and a lot of the stuff that's in the BTS just needs to be reviewed and committed.

And then there's Policy, which is just about ready for an upload, and where I owe several responses on bugs and discussion threads. It's in the best shape right now of the stuff on my hot list, but there really should be a new upload in May, and preferrably in the first half.

The current goal is to get the two other RC bugs against the Shibboleth packages dealt with in the next couple of days, then do a krb5 upload before the end of the week, and then Policy and Lintian are back at the top of the list, insofar as work lets me concentrate on anything else.

BTW, I have to say, the more I use Git, the more I'm becoming a convert. I still think I'd rather use quilt if I have complex merges. Ironic, given that that's supposed to be Git's strength, but I have fifteen years of experience merging patches and I really understand how quilt works. That may mean I'll change my mind when I become even more familiar with Git. But for the typical package with a small number of divergences from upstream, I'm getting the hang of managing those on branches and I think I like it.

I've yet to see a good reason to use rebase instead of merge, though, at least as part of a Debian packaging workflow. So either I'm still not getting something, or many of the people using Git are way more obsessive than I am about their branch merge graphs (which is weird, because I tend to be remarkably obsessive about things like that). I suppose if I ever get to using git bisect, that may change my mind.

2008-05-28: kstart 3.13

Time to start catching up on software releases, since Debian packages are now vaguely under control again. (I want to write a more general update, but I'm still completely exhausted from recent work deathmarch followed by an intensely social conference.)

This release makes -o, -g, and -m (to set the owner, group, and mode of created ticket caches) more generally useful, since apparently MIT Kerberos does now allow updating caches not owned by the current user and group if the mode is correct. It does change the permissions and k5start and friends have to change them back, so there's a small window where programs might be confused, but it's still helpful. Thanks to Howard Wilkinson for all the testing.

Also fixed in this version are portability issues with Heimdal and, separately, Mac OS X, plus a better environment variable for setting the path to aklog than the old KINIT_PROG.

As of this release, k4start should be considered frozen, since I no longer have a Kerberos v4 environment with which to test it. New tests and new features will only be added to k5start and krenew, although I'll fix bugs in k4start if someone reports them and I can figure them out.

You can get the latest version from the kstart distribution page.

Last modified and spun 2017-04-30