Archive for July, 2009

Linux defeats Samba

Wednesday, July 22nd, 2009 by hartmans

I hoped to come here and work on Samba4 with MIT Kerberos. Unfortunately the code for that project isn’t as far along as I had hoped. It definitely seems like individuals from Redhat, the MIT Kerberos team, and the Samba time are excited about progress on that front. Amusingly, everyone I’ve talked to is concerned about messy politics. However, I think I’ve talked to people involved in each team at this point. Everyone is very dedicated to the project but is concerned that others may raise political issues.

At this point, I think the only thing to be concerned about on that front is the fear of politics: the desire to do something hackish to avoid discussing something with some other group because they might disagree with it. Yes, we’re going to have design tradeoffs. Yes, we will have to convince each other of things. Yes, time-to-market will influence what solutions are possible and what is too expensive. Perfect may be the enemy of success. However I firmly believe everyone s open to change, open to listening to other parties, and everyone wants to make this happen. When people have brought up specific issues they are concerned other parties might not like, I’ve talked to those other parties and generally found that it won’t be a big deal.

With Jelmer’s help I tried to set up Samba4 and some Windows test environments. It took several days, and I was hugely frustrated. I eventually run out of the time I wanted to dedicate to it, although I did have some success. I may get back to it before returning to the US. Interestingly, Samba4 was not the big problem. I did find bugs—it’s alpha software—but also did get it up and running.

  • KVM proved quite frustrating. I wanted to find a simple way to bridge all my VMs onto the Debconf network along with the host. I found a way to do that, although I would not describe it as simple. (Create a bunch of tap interfaces, add the host to a bridge, add the taps to that bridge). Sadly, it didn’t work. The VMs cannot receive DHCP traffic.
  • I ran into a Debian specific kernel bug I have a thinkpad. In order to use my external drive bay, I really need to be using the ata_piix driver rather than the older piix driver. Unfortunately, Debian has decided that when a chipset supports both, we will disable the ata_piix support and force piix. (There is some concern about a race condition). Several people have proposed solutions that would address this, other distributions including Ubuntu have addressed the problem, but the only statement from the kernel team is a a statement that they won’t fix it. There has been no willingness to engage in dialogue.
  • Even when I get my DVD working, there is some interaction with KVM and the DVD where the system hangs consuming all CPU or IO in the DVD access. X, the VM, everything becomes unresponsive. It’s a soft hang; if I physically remove the DVD, it all turns into errors and I get the system back. However it makes it hard to install software.
  • Getting KVM to recognize my windows key is difficult. Works fine with VirtualBox, native applications, etc. The eventual solution (sendkey 0xdc-u for pressing Windows-u leaves something to be desired from a usability standpoint. (There seems to be no way to get the effect of windows-u at the login screen other than actually pressing that combination).
  • Of course, even once you manage to hit Windows-u, Vista’s implementation of Narrator is shall we say unresponsive. It’s fairly good at reading what you type. It often reads window titles. I’ve sometimes heard it read part of the contents of a Window. However it’s completely unusable on my system.
  • Subversion is slow. Setting up a build environment for the Debian Samba packages took a day.

A lot of people were very helpful in this mess. Joey Hess and Martin Krafft both helped keep me sane.

Redebconfiscation of krb5-config

Wednesday, July 22nd, 2009 by hartmans

I’ve been at Debcamp since July 16. The people have been great; the food is reasonable . I’m reminded how wonderful Debian is as a community. There are a huge variety of interests here: conversations have ranged from how to balance embedded system constraints against abstraction, security, computability and complexity of dependency management, sex, drinking and politics. I had been under the impression that the Debian community was very young. While there are a lot of young people here, there are definitely people older than I am, and the depth of experience is amazing. People have been very helpful bouncing ideas around, debugging, or just helping when things get too frustrating.

Yesterday, I redebconfiscated krb5-config package. The previous package had few heuristics for configuring Kerberos; it assumed that the Kerberos realm name mapped directly on the DNS domain name. It also assumed people generally wanted to specify Kerberos servers locally rather than relying on DNS. The new version will hopefully never interact with most users. It supports all the automated mechanisms I’m aware of for determining the Kerberos domain name . If the script can find a plausible realm and find KDCs for that realm, it will not bother most users. If it cannot find KDCs, then it is quite noisy until you help it along. There were a few tricks to the implementation:

  • It’s tricky to write a debconf script that reads a user config file to pre-populate debconf, allows the user to change things in debconf, and keeps the file and debconf in sync while giving preference to the file. One thing that makes this tricky is that the config script will be run twice between runs of the postinst script if preconfiguration is involved. The hardest situation to deal with correctly I’ve found is:
    1. Install the package at a relatively high debconf priority so you see few questions.
    2. Lower your debconf priority so that if the package were installed you’d see more questions.
    3. Wait for an upgrade of the package to come out and go through preconfiguration. Does the package behave correctly?
  • I ended up having to auto-generate the config script because I need a fair bit of static configuration data that won’t be available until the package is actually installed.
  • I think I may have over used the Perl ... operator.