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.
All posts