The web interface for our new account management system, prometheus (which I’m mainly discussing in its own blog) uses the perl Catalyst MVC framework. The initial prototyping and development of prometheus was done on a DICE FC5 machine, with most of Catalyst installed from Extras. For some reason, last week seemed like a good point to move it to it’s eventual home architecture on Scientific Linux.
Let us be clear. Catalyst has a lot of dependencies. And by lot, I don’t just mean a few additional packages. On top of our standard DICE installation, an additional 73 perl modules are required to build, and use, Catalyst itself. Unfortunately for me, only 28 of those are actually available in the EPEL repository. Of the remainder, 6 of them were completely new to Fedora, and have now been packaged and will be submitted upstream. The last 39 are packages which exist in Fedora but which don’t have EPEL branches – at some point I should ask their maintainers about either doing so, or allowing me to comaintain an EPEL fork.
All that aside, a header to add catalyst support to a machine is available as ed/options/catalyst.h Feel free to tell me about any problems, or further missing packages (!)
I’ve been experimenting with Mercurial, as a means of streamlining the way I work with the OpenAFS CVS repository. In particular, I’m trying to improve the management of my disconnected operation code, as well as better controlling the large number of patches I’m producing as part of the prototyping and error removal exercise.
Because I tend to flit backwards and forwards between different pieces of code, I tend to find that with CVS I have a large number of different checked out sandboxes. For big projects, such as the disconnection work, there’s no history, or ability to revert changes without taking a snapshot of the sandbox, which is both time consuming and inefficient. For smaller projects, there’s either a huge number of different sandboxes (and the related ‘where did I do X?’ problem), or lots of code ends up being intermingled within the same sandbox, and lots of things have to be unpicked before patches can be sent upstream.
These actually end up being two different problems, and it looks like there are two different mercurial workflows that are best suited to handle them. For disconnection, what I really need is a way of tracking, and managing, my code changes, and I’m using mercurial as a normal SCM to achieve this. With the prototyping changes, what I really need are patch queues – I have a large number of changes which I’m trying to arrange into manageable chunks in order to send upstream. Depending on my testing schedule, I may have a large number of patches awaiting submission. In this case, mercurial’s patch queues seem like by far and a way the best fit.
I’m intending on making my mercurial repositories for both of these tasks publicly available. For now, I can offer a mercurial import of the OpenAFS ‘upstream’ CVS at http://lochranza.inf.ed.ac.uk/upstream/ Other repositories are likely to appear there over time.
Local users may be interested to note that they can get mercurial on a DICE machine by including dice/options/mercurial.h in their profile.
I shipped the OpenSSH package with cascading credentials support that we’ve been testing for the last year or so site wide today. It’ll appear in develop releases from tonight, and in the next stable release.
The cascading credential support isn’t enabled with this, however. Enabling cascading credentials requires a configuration file change which LCFG can’t sync with the package update – so the configuration will get changed in a subsequent release cycle (next weeks, if all goes according to plan).
More details on cascading credentials is available from the second part of my SSH talk at last year’s AFS & Kerberos Best Practices Workshop. I need to make a public release of this patch, too.