[ Home | Articles | Account | People | Projects | FAQ ] The Kerberization continues
It took a while, but I've now got Kerberos authentication working for most services.
Done:
Todo:
It's still a lot more work to set this sort of thing up then it should be. Mac OS X and Windows are way ahead of any of the Linux distributions in this area.
cp: Cynic - Veil of maya
Reconciling the Samba 3 and Samba 4 source code trees
While a few of us have been working very hard on Samba 4 to allow it to rock your socks off as an Active Directory Domain Controller, some of the other Samba developers have been working just as hard on improving the existing Samba 3 codebase and adding features to that. This situation has caused tension between developers as well as technical problems in the past - code with the same purpose is being developed in parallel, libraries diverge because features are only added in one branch and not in the other, one codebase is considered "obsolete" by some and the other is considered only a playground for experimental features by others.
As of yesterday, we now have the two codebases living in one and the same git branch. This should make it a lot easier for the two to use the same libraries. Better yet, it should allow us to reconcile the copies of various libraries that exist in both codebases, all of which have diverged to some degree in the last few years.
After a few problems came up merging the two branches the easy way (they both have a directory called "source" and git doesn't deal well with renaming them to "source3" and "source4" respectively), we decided to replay the history of both branches . This has the disadvantage that all existing branches that are based on the Samba 3 and Samba 4 branches will have to be rebased against the new master branch, but it also means we keep the ability to run "git log" inside of our source directories and having it work right.
Other than the fact that this makes it possible to share more code between the two codebases, one of the ideas we have is also to see if it is possible to provide an Active Directory DC by glueing the best bits of Samba 3 and Samba 4 together (aka "Franky") before they are eventually merged completely.
cp: Phideaux - Formaldehyde
Because KISS is the way to NIH
I wish SASL was more like GSSAPI. Sure, GSSAPI is horribly overengineered, way too generic and too complex but at least that scares people away from going NIH on it.
The fact that everybody has their own SASL implementation is not really a problem by itself, but most of the implementations only cover a few of the wide range of SASL mechanisms (PLAIN and DIGEST-MD5 usually) that are standardized. There's also tiny bugs that spring up because the implementations differ; for example, inserting whitespace between the elements in a DIGEST-MD5 challenge breaks some clients.
Oxegen '08
Oxegen was a bit expensive but awesome. Irish people rock.
bzr-svn push without file properties
Ever since bzr-svn started supporting "true push", people have been complaining about the extra file properties it sets.
The key thing about "true" push is that it preserves the exact revisions that were present in Subversion. This lets bzr behave on Subversion branches transparently using the same UI you also use for "native" Bazaar branches.
In other words, if I push to a Subversion branch from my machine, then that branch in Subversion contains enough information for somebody else to reconstruct the exact bzr branch I had.
Since some Bazaar metadata can not be represented in Subversion, it is stored in Bazaar-specific Subversion properties. Unfortunately, these file properties show up in email commit notifications and trac and so they tend to annoy people.
There are two ways around this:
Bazaar-specific metadata can be stored in in custom Subversion revision properties (these don't show up in commit notifications). Unfortunately, this requires Subversion 1.5 or newer to run on the server.
I hope to start setting revision properties instead of file properties when possible as of the next bzr-svn release.
It's also possible to throw away any data that can not be represented in Subversion. Since this means that the remote branch won't end up an exact same copy of the local revisions, this isn't true push. The two branches will have diverged (no matter how slightly) after such a push so it is necessary to rebase on the remote branch after pushing.
This is similar to the way git-svn pushes data into Subversion - it calls it "dcommit".
Since this uses rebase it has the usual disadvantages of rebases, which I won't get into right now.
As of a couple of days ago, bzr-svn now also supports this mode of pushing using the "dpush" command, by popular demand.
bzr-svn push without file properties
Ever since bzr-svn started supporting "true push", people have been complaining about the extra file properties it sets.
The key thing about "true" push is that it preserves the exact revisions that were present in Subversion. This lets bzr behave on Subversion branches transparently using the same UI you also use for "native" Bazaar branches.
In other words, if I push to a Subversion branch from my machine, then that branch in Subversion contains enough information for somebody else to reconstruct the exact bzr branch I had.
Since some Bazaar metadata can not be represented in Subversion, it is stored in Bazaar-specific Subversion properties. Unfortunately, these file properties show up in email commit notifications and trac and so they tend to annoy people.
There are two ways around this:
Bazaar-specific metadata can be stored in in custom Subversion revision properties (these don't show up in commit notifications). Unfortunately, this requires Subversion 1.5 or newer to run on the server.
I hope to start setting revision properties instead of file properties when possible as of the next bzr-svn release.
It's also possible to throw away any data that can not be represented in Subversion. Since this means that the remote branch won't end up an exact same copy of the local revisions, this isn't true push. The two branches will have diverged (no matter how slightly) after such a push so it is necessary to rebase on the remote branch after pushing.
This is similar to the way git-svn pushes data into Subversion - it calls it "dcommit".
Since this uses rebase it has the usual disadvantages of rebases, which I won't get into right now.
As of a couple of days ago, bzr-svn now also supports this mode of pushing using the "dpush" command, by popular demand.
cp: Brandi Carlile - The Story
bzr-svn: now with its own Subversion Python bindings
bzr-svn has always been using the standard Python bindings that were provided with Subversion itself. Unfortunately, I had to fix some issues in these bindings since they were incomplete or broken and thus bzr-svn has always depended on a development snapshot of Subversion.
As of today, bzr-svn is using its own Python bindings for Subversion.
There were several reasons for switching to our own bindings:
Since all of the patches that bzr-svn depended on previously were in the Python bindings for Subversion, it is now possible to use bzr-svn with any version of Subversion newer than 1.4.0. Of course, you do need to have the development headers installed as well.
cp: Kathleen Edwards - Independent Thief
Bazaar in the GNOME world
I was happy to see that John Carr has set up a Bazaar Mirror of all projects in GNOME Subversion, all created using bzr-svn. There's also a quick introduction to using Bazaar for GNOME developers on the GNOME wiki.
Wouter, long time Bazaar user and GNOME dude, recently blogged about pushing Bazaar branches into GNOME Subversion, working around the restrictions imposed by the pre-commit hooks in GNOME Subversion.
The problems John ran into with memory usage in the Python Subversion bindings encouraged me to continue the work on bzr-svn's own Python bindings, thus avoiding any dependency on unreleased versions of Subversion and several other issues.
Git cutting corners
My relationship with git is still one of love and hate. It cuts corners to increase performance in a couple of places and that can be really bloody annoying.
For example, jerry renamed one of the top-level directories in Samba 3 (revision 9f672c26d63955f613088489c6efbdc08b5b2d14). Git will skip rename detection in this revision because of the number of files it affects, thus causing the output of "git log <path>" of this particular directory to be useless.
I'm the first to admit "bzr log" on directories and files in large history projects is painfully slow, but at least it gets the output right.
cp: Brandi Carlile - The Story
SambaXP and other travel
It's been a busy two weeks. Wilco and I drove up to Göttingen on Sunday two weeks ago to spend some days hacking and meeting up with the other developers before the start of SambaXP. It was really nice to see everybody again after more than 7 months.
SambaXP was a bit different this year. There were three tracks during the second part of the conference this year, one more than previously and of course, there were several engineers from Microsoft attending this time! Some of the interesting talks this year included Julien's update on OpenChange, Tridge's talk on PFIF, the talk from the likewise folks and of course the talk from Microsofts' Wolfgang Grieskamp on SMB2. We also had some other informal discussions with the Microsoft folks about specific topics - very useful!
There are some photos up on the SambaXP homepage. And just to be ahead of the comments: yes, I know I need a haircut.
I did some initial work on several bits and pieces of code that I hope to expand over the next few months. Volker has started working on ncacn_ip_tcp support and I have been working on making the Samba 3 DCE/RPC library compatible with Samba 4. This should allow OpenChange to use Samba 3 in the future.
Guenther, Wilco and I made some initial progress on the policy library, allowing client-side manipulation of (group) policies in Samba. I worked with Simo on trying to get rid of an evil hack in Samba4's event subsystem.
David Holder blogged about some of the IPv6 development that we did during the conference: http://www.ipv6consultancy.com/ipv6blog/?p=34
And lots of other things I can't remember at the moment...
After the conference Andrew, Wilco and I drove back to the Netherlands and I played tour guide for a bit showing Andrew around the country during the afternoon and hacking Samba together in the morning. Later this week we took the train to Brussels, Eurostar to London and visited Sam's company
in the UK Midlands for a couple of days.
And in the midst of all this, it seems Ubuntu Hardy was released. Congratulations to all those involved!
cp: Brandi Carlile - Turpentine
FOAF updates: Trust rankings are now exported, making the data available to other users and websites. An external FOAF URI has been added, allowing users to link to an additional FOAF file.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!