Adam They just told you how to get past their front lines: Call their business support on the toll-free phone number she gave you. Here's my take at what happened:

• You entered a question on a web form which is intended for user support questions.
• A first-line technical support person called Irene (who, most likely, is not trained as a computer person; since 90% of all calls can be fixed by going with the customer through their connection and email settings, you can train anyone to be a first-line technical support person in one day, with most of the time spent in How do I handle the phone and How do I handle the ticket tracking system) had a look at your request, saw that you had problems with sending email from remote systems, and copied a standard text about mail bounces in her reply to you. Remember that there are many people out there who think they know a lot about computers because they know how to start regedit and know a few buzzwords; the presence os such words in a support request is not necessarily a sign that there's some clue at the other end of the line.
• You replied that no, this does not apply, and that yes, it's really a problem at your end, because lots of words Irene does not understand. She then decided you're totally out of her league, and redirected you to their second-line support; second-line supportlines do consist of people knowledgeable about computers, because at that point it's no longer a trivial problem. Since you happen to be an ISP, which is a company in her book, she referred you to the Business support line; such a Business support line usually consists of people even more knowledgeable about computers in general and the Internet specifically, because companies usually have rather specific needs that go a bit further than I have an ADSL modem and a Windows box.

Really. Call them. You'll find that you will be talking to someone knowledgeable about what SMTP is, and who is able to put a request with SMTP administrators to fix this issue if that is required. Take it from someone who used to work at one of Belgium's largest ISP's (at least, it was that when I used to work there—they've lost some market share since).

Debcamp was really stressing - It seemed we would not be able to get things to work for Debconf. And it would suck. I was quite down when I last wrote a blog entry - Not in mine, but in Debconf's. Things looked quite hellish, and I was _very_ annoyed - Well, I must say: Thanks to you all for the support. Mooch's request has been honored extensively, and it does help. Really.
Yesterday we had the Debian Day. About 50 Mexicans showed up, after we had to jump through some hoops with the Oaxtepec management people (thank you, thank you, you are great! Real dedication to your job, to make us feel welcome and important). The talks were interesting and well presented, and the people left happy - and some of them, left quite late. We had presence from at least one national newspaper (La Jornada and a magazine, Software Guru. Good.
Then, during the night, we were flooded by arriving foreigners. Boy, the hacklab was packed! Good thing we now will have both hacklabs running.
I have to thank most than to anybody else to my wife, Gaby a.k.a. Nadezhda - She has done all the ugly paperwork... Without her, we would all not be here. And later, I would probably be sitting in jail or something ;-)
Seems that the bugs are ironed out. Now I'll try to attend the "Sun and Debian: can we be friends?" round table.

I've been quiet for a couple of weeks now; I went home to my parents for just over a week at the start of May (more on that later), then last week was spent catching up with various bits after being away, and then the past few days I've had a cold (just in time for the weekend, yay!). Meh. Anyway, as such I haven't been fiddling a lot with the E3; still stuck at the point where I could get it to load my second stage loader from NAND, which would then load u-boot, which would then load the kernel, but not getting anything from the kernel after decompression. Whereas if I loaded the second stage loader over the serial port it all worked fine. Figuring that Amstrad's PBL must be doing something different depending on which method you use (NAND/serial) I had a look at the config registers to see if anything was different. Nothing obvious. I enable the low level kernel debug output and find it is booting ok, but that it freezes as soon as it tries mutex_lock in clk_register. Odd. So I disable CONFIG_DEBUG_MUTEXES and all of a sudden it works. My E3 boots into Linux unattended. Woooo. I think.

I’m not the first person with a story about the sad state of Comcast. Since I’m certain I’m never actually going to get a True Human to read my email at Comcast, I’ll just post my brief exchange regarding Comcast’s SMTP servers here. Maybe some future archaeologist of the Internet will point to this exchange as early evidence of the End of Email: I posted the following to Comcast’s website feedback form — apparently there is no publicly advertised email address for communicating with Comcast:

Please forward this email to an engineer responsible for Comcast’s SMTP service. I run an ISP. Email to @comcast.net addresses often bounces with a “556 null byte in data” rejection connecting to gateway-s.comcast. I use postfix from Debian Sarge. This is not a problem on my end. There are numerous reports of this problem in newsgroups (just google ‘556 null byte in data’ ‘comcast’). The problem is independent of mail user agent and ISP. Note that this is *not* an issue of my users attempting to connect to the Comcast SMTP server themselves—I understand there is some issue where Comcast only accepts SMTP/SSL/TLS now for its users. This is a *delivery* problem. I have seen some speculation that Comcast’s SMTP servers are rejecting email with this error because of either large attachments or attachments with long filenames. I have seen the problem occur where the attachments are very small (on the order of 10K), but I haven’t ruled out the latter explanation. Please let me know if there is anything I can do to fix this problem. My users would like to be able to email Comcast customers.

Comcast’s response:

Dear Adam KESSEL, Thank you for taking the time to write us. Comcast is aggressive about protecting its’ subscribers from unwanted and unauthorized emails. In keeping with industry standards and best practices some recent changes to our filters have been made.If you are attempting to send emails to legitimate recipients in the Comcast.net domain, and receive an error message there are 3 likely reasons: 1. Your mail server has been identified as a source of Spam. Our mail filters have been updated to reject all mail from your server until the administrator of your mail server contacts us to request the server be removed. 2. The source of your message has a dynamic email address. Anyone attempting to email into the Comcast domain directly from a Dynamic IP address will receive the following error message: Comcast does not support the direct connection to its mail servers from residential IPs. Your mail should be sent to comcast.net users through your ISP. Please contact your ISP or mail administrator for more information. 3. Your mail server has an invalid rDNS value. What this means is that our mail filters authenticate each message by checking the rDNS value to ensure its’ a legitimate domain and yours wasnot. The error or “bounce” message you receive will indicate which reason the message was rejected. Youwill either be given the address to request Blacklist removal or you will be directed to our rDNS FAQpage. If a domain administrator feels that their IP range has been blocked in error or they would like information on required steps to be removed from our black list, they can contact us at: blacklist_comcastnet@cable.comcast.com If you need assistance setting up email through your ISP?s mail servers please visit their support pages or contact their support group. If you need information on the rDNS block, please visit: http://www.comcast.net/help/faq/index.jsp?faq=Email118405 Thank you for the opportunity to assist you. If you need further assistance with any of your Comcast services please reply to this email and we will be happy to assist you. Thank you again for choosing Comcast we appreciate your business. To visit our local support page including links to contact us via Live Chat, as well as many downloadable forms,and FAQ pages, please visit: http://www.comcast.com/nesupport/ Did you know that Comcast offers its customers a variety of free benefits? These include McAfee Antivirus, Firewall and Privacy software as well the Comcast tool bar that lets you take Comcast.net with you while you surf, and the Desktop Doctor to help you restore lost settings…plus much more, please visit http://www.comcast.net/downloads/ to see all of the extras that we provide. Sincerely,
Irene Comcast Electronic Customer Care - New England You can email us anytime by replying to this email or by clicking the “Contact Comcast” link found on the bottom of all www.Comcast.net and www.Comcast.com webpages. Our Electronic Customer Support teams are available to assist you 24 hours a day 7 days a week. **************************************************
The response contained in this message is intended for the addressee only and may vary from other ponses depending on geography, promotional campaigns or other factors. If you are not the intended recipient of this response, please delete this message. Any unauthorized use or dissemination of the information contained in this message is prohibited.
**************************************************

The last bit about “unauthorized use” is a nice touch. My follow-up:

The 556 null byte SMTP error is *not* a spam or blocking related rejection. My mail server is (1) not a source of spam (2) does not have a dynamic IP address (I assume below whenyou wrote “dynamic email address” you meant “dynamic IP address”); it is not a residential IP but rather a commercial ISP that I run; and (3) the mail server has a valid reverse DNS lookup. To clarify: not every email is being rejected from the ISP’s IP address. In fact, the same sender can send from my ISP multiple times to a Comcast subscriber, and most messages will get through. There appears to be a bug in your SMTP delivery server whereby certain triggering events cause a 556 null byte error. There is at least some evidence that one such triggering event is an email with an attachment with a long filename. This is not a spam filter issue. This is a Comcast SMTP configuration issue. As you will see if you google “‘556 null byte in data’ comcast” this is awidespread problem that is entirely unrelated to Comcast’s zealous efforts to block unsolicited email. Please forward my email to an engineer or technician. Thanks,
Adam

Finally, Comcast’s witty retort:

Dear Adam Rosi-Kessel, Thank you for taking the time to write us. Commercial Email Accounts We have to apologize, but at this time you must contact our Commercial Business support team by calling one of the following toll free numbers 888-824-8105 or 888-824-8155, 1-888-737-8361 Thank you for the opportunity to assist you. If you need further assistance with any of your Comcastservices please reply to this email and we will be happy to assist you. Thank you again for choosingComcast we appreciate your business. To visit our local support page including links to contact us via Live Chat, as well as many downloadable forms,and FAQ pages, please visit: http://www.comcast.com/nesupport/ Did you know that Comcast offers its customers a variety of free benefits? These include McAfee Antivirus, Firewall and Privacy software as well the Comcast tool bar that lets you take Comcast.net with you while you surf, and the Desktop Doctor to help you restore lost settings…plus much more, please visit http://www.comcast.net/downloads/ to see all of the extras that we provide. Sincerely,
Ivonne Comcast Electronic Customer Care - New England You can email us anytime by replying to this email or by clicking the “Contact Comcast” link found onthe bottom of all www.Comcast.net and www.Comcast.com webpages. Our Electronic Customer Support teams are available to assist you 24 hours a day 7 days a week. **************************************************
The response contained in this message is intended for the addressee only and may vary from other responses depending on geography, promotional campaigns or other factors. If you are not the intended recipient of this response, please delete this message. Any unauthorized use or dissemination of the information contained in this message is prohibited.
**************************************************

If anyone has interesting ideas about how to get past Comcast’s front lines, I would like to know.

I've been ill with flu the last few days, so I've been doing very little other than sitting huddled in my recliner, with a large, warm blanket over me, and my hot water bottle (AKA the laptop) to work on. As a result, I've been doing a fair amount of random coding, and I've come away with a larger-than-average amount of... weird shit. It maybe the flu, the strong drugs I've been taking to keep the symptoms under control, or maybe just the phase of the moon, but I haven't coded up this much madness in quite a while. Let me take you through them. The Proctologist I've been writing some software which has to talk to an XML-RPC server. Not so weird. However, because the system lacks any inherent security, the (strongly) preferred method of communicating with this server is via a Unix socket. That's right, I'm doing XML-RPC over HTTP over... a Unix socket. That, you may think, is weird. Well, it is, but it isn't the curious perversion in and of itself -- for a start, I didn't write that monster, and I'm only blowing my own trumpet in this article. No, the perversity is in how I wrote *my* software to deal with it. See, I'm using Ruby for this software, and the standard Ruby XML-RPC client uses the built-in Net::HTTP library that comes with Ruby (which is a killer little HTTP library, BTW). Because the authors of Net::HTTP were lacking in imagination (or crack pipes) they didn't think to include the native ability to talk to Unix sockets. I mean, really -- isn't that the most important feature in a HTTP library? I think we all know the answer to that. Anyway, despite the lack of forward planning (and crack pipes) on the part of the Net::HTTP authors, I needed to get it to talk to a Unix socket. I could have done the long-winded thing and spend a pile of time putting in handling of pipe:// (crack or otherwise) URLs, but then I would have also had to add support for it to the XML-RPC client library (which did URL validation before passing it on -- good for it). And really, I don't think I could have handled the guffaws of laughter when I attempted to submit the patch upstream. Instead, I put Ruby to it's perfectly-suited use. I simply created the XML-RPC client object (which created the Net::HTTP object internally), then inserted my gloved finger and replaced the default TCP socket object in the Net::HTTP object with a specially crafted Unix socket object pointing to the correct place. "Dear god almighty!" I hear the practitioners of good software engineering practice exclaim. "Doesn't Ruby have protection against such atrocities?" Why, yes, it does. All of the objects I had to play with are private instance variables of their parents, and I can't get access to them normally. However, classes in Ruby are never closed, so I just reopened them and added accessor methods (which, in Ruby, is as simple as attr_accessor :http) so I could do my nasty little thing. I'm quite happy to take the heat for doing what I did. It breaks encapsulation, and makes everything that little bit more complex. But, on the other hand, it let me get the job done -- the language gives you full protection until you say "may I?" and then it gets out of your way. Personally, I reckon that's a nice tradeoff between C-style full control (where even the best programmers blow their foot off on a regular basis) and B&D; languages where you'll never shoot yourself in the foot, but instead you'll gnaw your leg off in frustration. Russian Dolls I'm doing a bunch of interesting things with the Xen hypervisor for work. Of course, you need to have a way to test all this stuff, and despite a number of hints, work still hasn't gotten me that fully-kitted out dual-core Opteron that I want to test (and transcode all my video <grin>) on that I always wanted. So, instead I've installed Linux in a qemu image, and then put Xen on that. Surprisingly, it's worked really well -- I've got Xen running quite happily in the virtual machine, and I can create and run Xen domUs (the guest VMs) in the usual fashion. Now all I need to do is install UML in a Xen domU, and then run some vservers inside that UML, and I'll have the full collection...

A while ago, I read an article on The Register, written by a journo based in Mountain View of all places, which had a tagline at the bottom that said to email him if you wanted to "drink like a vulture" on some sort of corporate drinkies or something. Being in Mountain View and all, I could hardly resist. Said journalist actually emailed me back, after Googling me, and it turned out he was half Australian himself, so what better excuse to catch up for dinner? Tonight we had dinner with Ashlee Vance and his wife Melinda, at the Cantankerous Fish in downtown Mountain View, and had a really great time. It's cool when you meet the sort of people you can just chat with for hours and get along with, and they're complete strangers you've never met before. It was a good night out.

Erich, Windows is very often harmful but, moreover, bad Windows admins are even more harmful. What you reported is indeed a wrong setup for the Windows Automatic Update feature. This feature allows to automagically apply security updates to Windows machines (and everyone with a working brain certainly agree that this is mandatory and one should not rely on users for this). This is a very well documented feature and admins can set it up to avoid the behaviour you reported (allow users to delay automatic reboots or even never reboot). It just needs Windows admins to actually *read* documentation and understand it. *This* is where the Windows world sucks. Windows admins able to do this are a very rare resource. Update: and the location of nearly all stuff in Windows is known by the system, configurable and easy to access (well, registry...:-)...also system variables, though). Again, I know about 10% of Windows admin who really know how the location of the system files can be deduced safely. Bashing Windoze is certainly worth it but I really suggest doing it with the correct arguments and, indeed, when really knowing the system. In short, it's way better to really know what you're talking about. After all, I have very often heard that Unix systems suck because you never know where things are (/opt, /usr/local, /etc, /foo, /bar)...while we both know that only bad Unix systems administered by bad Unix admins suck this way...

So about two weeks ago I started playing with Kerberos. And I'm still not finished with it, kerberizing one service after the other. Really fun, that. Kerberizing a network protocol involves somehow sending the Kerberos ticket in-band with the rest of the conversation. This is not entirely defined by the Kerberos protocol, and indeed, different network protocols have come up with different ways of sending the Kerberos ticket to the service. So far, I've encountered SPNEGO for HTTP, GSSAPI for IMAP and SSH, and SASL for LDAP. It sounds like a complex mess, but it really isn't; in general, kerberizing a service involves three steps:

1. Installing the Kerberos plugin (if any) for both the server and the client;
2. Generating the service principal, and adding it to a/the keytab;
3. Configuring the service so that it knows it can do Kerberos, and so that it knows how to act when a Kerberos request is sent

Yes, in the cases I've seen it's really that simple. Although I'm skipping step 0 here–reading the documentation. But I've done that for you already ;-) The hardest part is the initial setup. But even that isn't very hard, because the process is very well documented. For starters, install the krb5-doc package, and read the excellent /usr/share/doc/krb5-doc/README.KDC which explains just enough of the system to get you started. The rest will be explained to you through debconf and the like; and if you want more, the krb5-doc package also contains three info files which explain concepts and usage very well. There's an alternative implentation called heimdal, which I presume works similar; but I haven't tried it, so I don't have much details on that one. The process of installing krb5 is very straightforward; the only thing I'll let you know is that you should ensure that any host you're going to kerberize should have reverse name lookups configured and working correctly; otherwise, you're going to run into a bunch of serious problems. After the initial setup, you'll have a Kerberos realm, usually your domain name in upper case (GREP.BE in my case). You'll now want to set up principals for your users and principals for your hosts. Now, let me show you how to configure Kerberos for LDAP, PAM, HTTP, IMAP, and SSH:

PAM

By installing and using the libpam-krb5 package, you'll log in to kerberos and receive your TGT immediately at login time; the alternative would be having to use kinit (in the krb5-user package) afterwards. pam_krb5.so also takes care of destroying your tickets when you log out, so that you don't have to worry about that. This is very handy, but not really required; you could just use kinit all the time. Of course, using pam_krb5.so also means you have only one password for everything—and that is a very good argument to use it.

Anyway; our three steps:

1. Installing the plugin
As you've guessed, libpam-krb5 is the package you'll need. That, or the heimdal implementation.
2. Generating and installing the service principal
In the case of any service such as PAM that will give you a shell (thus, as we'll see later on, also SSH), the principal is supposed to be host/<hostname>@<REALM>. For instance, on rock.grep.be, the principal PAM will use is host/rock.grep.be@GREP.BE. We'll create it with kadmin (which can be done on any kerberized host):

wouter@rock:~$ sudo kadmin
Password for root/admin@GREP.BE:
kadmin:  addprinc -randkey host/rock.grep.be@GREP.BE
WARNING: no policy specified for host/rock.grep.be@GREP.BE; defaulting to no policy
Principal "host/rock.grep.be@GREP.BE" created.
kadmin:  ktadd host/rock.grep.be@GREP.BE
Entry for principal host/rock.grep.be@GREP.BE with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/rock.grep.be@GREP.BE with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.
kadmin:  q

Generating the principal can really be done as any /admin user; but as the same isn't true for writing the keytab, I'm using sudo in the above example to become root.
3. Configuring

account	required	pam_krb5.so ignore_root
auth	sufficient	pam_krb5.so ignore_root forwardable
password optional	pam_krb5.so ignore_root
session	optional	pam_krb5.so ignore_root

After adding the above lines to the relevant files in /etc/pam.d, you should log off, then log on again, run 'klist', and marvel. If you add the lines to your passwd file as shown above, and don't remove the pam_unix.so lines, then local passwd-based authentication will still work. This can be nice if, for example, the Kerberos server is down, or you're working on a laptop that isn't always within reach of the Kerberos server. It doesn't do any harm; the worst that can happen is that at some point you happen to be on a network where there's a firewall which drops packets on the floor rather than sending you an ICMP port unreachable; in that case, you need to wait for the Kerberos login to time out, which takes half a minute or so (I haven't timed).

SSH

1. Installation
If you're running unstable, you don't need to do anything. The OpenSSH packages in unstable are all set to understand Kerberos. If, however, you're running stable, you'll want to replace your ssh package by the ssh-krb5 package, which is the regular SSH package plus some patches to enable GSSAPI (read: Kerberos) authentication.
2. Service principal
If you've done the PAM setup above, you're all set; SSH, being a service which gives you a shell, also uses the host/ service principal.
3. Configuration
Make sure both the server and the client have the GSSAPIAuthentication option enabled. After you've done so, restart the server.

IMAP

I'm using dovecot as my IMAP server, which has builtin support for GSSAPI authentication (at least in unstable; haven't checked stable in this regard).

1. Installation
As dovecot comes with everything compiled in, there is no need for installing extra packages.
2. Service principal
You'll need the imap/ principal (e.g., imap/rock.grep.be@GREP.BE). Note that the host name which is found by doing a reverse lookup on the ip of the server is what counts, not the name of the server as you're using it (so not, e.g., imap/imap.grep.be@GREP.BE)
3. Configuration
Edit your dovecot.conf, and find the line that starts with "mechanisms" in the auth default stanza. Make sure it contains at least the word gssapi. Restart dovecot. I haven't found a Free (as in speech) IMAP client that supports GSSAPI authentication. My client of choice, offlineimap, doesn't seem to support it; mutt doesn't either (unless I'm missing something); and while thunderbird in unstable is supposed to support it, I haven't been able to configure it correctly yet. Probably me. I have, however, been able to verify that it works by using a non-free software package. Obviously, this isn't good enough. In addition, I found that horde and imp don't like an IMAP server that has GSSAPI enabled if they don't, while enabling GSSAPI in horde requires a PHP extension that isn't packaged in Debian. So I've disabled it for the time being. Stay tuned.

LDAP

1. Installation
LDAP requires uses SASL for authentication, which doesn't have GSSAPI modules in the default package; for those, you need the libsasl2-modules-gssapi-heimdal package. Attentive readers will have noticed that this package contains the string heimdal in it, rather than krb5, and that this is not the same implementation that I've been using previously. Yes, true. But since there's no libsasl2-modules-gssapi-krb5, and since Kerberos is, after all, a well-defined protocol, this is not an issue—except in that you need a bit more diskspace for the additional libraries. Note that the modules have to be installed on both the client and the server.
2. Service principal
You need a service principal that starts with ldap/, obviously followed by the hostname and the realm.
3. Configuration
For those people whom you want to allow to authenticate themselves using Kerberos, make sure they have ' SASL <principal>' in their userPassword attribute set (e.g., I have userPassword: SASL wouter@GREP.BE). You can have that in addition to a regular encrypted password; the userPassword attribute is a multi-value attribute. Now if you use ldapsearch or anything similar, it will try to negotiate GSSAPI authentication as the SASL mechanism. If it doesn't do so, you can force it by adding -Y GSSAPI to the command line.

HTTP

1. Installation
You need the libapache-mod-auth-kerb or libapache2-mod-auth-kerb modules on the server. For the client, you need a browser which has SPNEGO support; Konqueror and Firefox are two examples of browsers that do.
2. Service principal.
The prefix here should be HTTP/. That's right, in upper case, contrary to previous examples where this wasn't the case. HTTP is also different in that apache usually isn't running as root. This is a good thing; however, it does mean that the kerberos authentication module is unable to read /etc/krb5.keytab. You'll have to write the service principal to a different keytab for apache; I've used the -k option to the ktadd command in kadmin to specify the keytab as /etc/apache2/keytab; I'll assume you do the same.
3. Configuration
Something like this, on the server:

<Location /some/URL>
	AuthType Kerberos
	KrbMethodNegotiate on
	Require valid-user
	Krb5Keytab /etc/apache2/keytab
</Location>

This will enable SPNEGO authentication; and if SPNEGO authentication fails for some reason (for example, because the used browser doesn't support SPNEGO, or because the user isn't logged in to Kerberos), it will fall back to Basic Authentication. While the latter is usually a good idea, it's less of a good idea if you're not using SSL, since then your password would be sent over the wire in cleartext. Luckily, the basic authentication can be switched off, by using KrbMethodK5Passwd off. If you go to my webserver logs, you'll see that you'll get a 401 right away, while the HTTPS version of the same allows you to try to log in by using basic authentication. On the client side, if you're using Firefox, you need to go to about:config, and set the option network.negotiate-auth.trusted-uris to a string that will identify the servers that may do SPNEGO authentication in your realm. In my case, I've set it to grep.be. For konqueror, doing something similar is not required—it'll do SPNEGO authentication out of the box.

So, that's what I've got set up on my network currently. Next on the list: NFS4 kerberos auth (requires updated nfs utilities, which aren't in Debian yet because of issues with NFS2, IIRC), PostgreSQL (it does seem to support it), and finding out if or how I can create principals can't be used for one authentication scheme or the other. Phew, that was a long post. I'll stop now.

On friday the 5th I started my trip to MX. I am assisting to Debconf 6 from the very first day, so that I can help the local team (at least with translations and such). I arrived to the airport early, so that I didnt have to suffer last minute stress if I see that the line is way too long and I have too little time to catch the plane. It all started fine (well, I forgot my keys at home when taking the dog for a walk, but I managed to reach my girlfriend and she came back to open the door for me). I must be the worst traveler in the world, since I seem to be causing only problems. Or maybe is that I question too many things that are the status quo and seem reasonable for other people. From the begining. It was check-in time, and the lady ask me about my hand luggage. I mentioned that since my friends were going to be waiting for me at the airport for almost 2 hours, I had prepared all my stuff so that I was not carrying anything dangerous in my two backpacks. Heck, I even left behind the regular tools that I carry with me, including the nail scissors,... The lady said it was not possible. "Sir, you can only carry 8 kilos of hand luggage". I looked around and saw people with lighter bags, but bulkier than mine. "Sorry, but, what is the reason? My luggage is smaller that the regular luggage, and I just need to get out asap". "Security reasons, sir". "Could you describe those reasons?". "... ... (surprise face) Security, sir. I would like to travel with my 20 kilos os luggage with me, sir". Yeah, sure. I am happy about that. I dont recall going away for such an extended period with such an small amount of things. When did all this madness start? Well, she did not manage to give me any reason why I could not take my things with me, but she got her sweet revenge. She put me on the back of the plane, with a guy who had at least 50k more on than I, although we both paid the same price for the ticket. I wonder where the security reasons are then, for those 50k... (Mental note: add to the travel checklist not to EVER forget deodorant and to take a shower before leaving home. Two showers. I had enough torture with the guy beside me...) The nice part of the flight was that for the first time i traveled on a Jet. Boy, is nice. Landed in Germany. The plane went to park on the backyard of the airport. We had a long 10min trip back to the terminal. The check-in for the plane to MX was a full hour set in advance, so that the HUGE amount of people that fits on one of those 747 had the time to show (for the 10th time) the passport. But looking aroung one wonders again where those security reasons not to let me carry my 8 kilos of luggage are: people around me had bought nearly their year salary on duty free stuff that wights more than 15k. Oh, boy, now I am confused. Is it so that someone has decided to add a rule in the name of security at some point after 11/9 and they forgot why? What difference does it make to get the luggage with 8 kilos from outside the terminal than from inside? As a side note, one can see that mexicans still keep much of the Spanish attitude. The speaker goes on, a man speaks in German and explains that people with children will board before anyone else. Nobody has understood anything, but they are already piling before the boarding gate. Once the man speaks in English, only the ones who dont understand English still await impatientily at the gate, mostly disturbing the check-in procedure for the flight, which will probably be delayed because of that. The second part of the trip was a bit more relaxed... I will skip the story about the looks-like-it-is-not-her-day flight attendant who could not understand a shit, and will only mention that when she served me a light coke and I handed her the empty can for dispossal, she gave me another full can with a face of "take-this-and-shut-up,dont-you-see-i-am-not-having-a-good-day?". I did not know Mexico was in the south hemisphere. At least that was the reason given for the satellite-linked internet only working the first three hours, although we were flying through Greenland, Canada, USA and Mexico's gulf for the 12h of flight, and Mexico IS on the (using the lonstanding critizised convention of not putting the map upside-down and say that is the right possition) north side. After landing it was a bit of rush, until I had to wait for my luggage, which of course came after waiting for almost 40min (Revenge of the Check-in Lady, take three... hi, if you read me). The people who create those inmigration forms MUST have short names. They have a big horizontal box with small vertical lines on the boxes to put your data trying to force you to put every character of your name in one small designated area. So there you go: "J E S U S _ D A N I E L _ C L I M E" That's right. Not even my first surname fits. Forget the second. This are the times that a friend of mine comes to mind: Enrique Garcia-Villarubia Gomez-Limon (Hi, if you read me). After all this I went out to find Amaya and h01ger waiting for me. We met Ganneff, Stockholm, Sam and Jeroen, and Damog, along with Agi, were coming right after picking up the van. We put Ganneff and Stockholm on a taxi and sent them to Oaxtepec, and left the airport for some dinner. Mexico is BIG, BIG, BIG. After driving for more than half an hour we got to a bridge from where you could see the city lights. And still, they were covering the horizon. HUGE. That realization is something I have not digested yet. Some local beers and tacos made the end of the night and we headed to Hector's place, where we were going to spend the night. From a not so negative point of view, the whole experience has been positive, and enlightening, to say it mildly. The food is mostly spicy. It could burn hell. Amaya is trying to get use to it by eating an insane amount of hot stuff but I refuse to do so. For the scared (hi, helix) I have not managed to get anything from the tap water. So nobody is dead, yet, although rumor has it that some are in comas. The net is here, although the roundtrip values are not very exciting. Mao has visited already the place, and said it is here to stay. Summary for the ones to come: this is HOT. I mean, really HOT. Forget your long jeans and bring shorts, even if you dont like to show your legs, sun screen cream, t-shirts, deodorant, swimming suit, and keep a bottle of water all the time with you. Food is served at a more sensible time than in Finland: 02:00h and 20:00h. See you in MX.

The Apple Public Source License is a GPL-incompatible file-level copyleft license. That's mostly irrelevant - what actually matters is that both the FSF and OSI regard it as free or open source. So no problem, right? Except that the APSL hasn't really caught on. Freshmean lists two whole pieces of APSL software. Both of them are derived from Apple code released under the APSL. That is, nobody other than Apple has chosen to start a project based on APSL code. It's actually worse than that. Section 12.1(c) of the license automatically terminates your right to use or distribute the software if you sue Apple for patent infringement. Any patent infringement. Apple have infringed your new chip process patent? Better hope you don't rely on any APSL code. Apple's new TFT design copies yours? Better work on a replacement for Howl. Apple have stolen your entire motherboard design? Bad luck - using this code made it awkward for you to defend your IP. As a result of this, the only significant APSL project (Howl) has effectively been entirely replaced by Avahi. Both Gnome and KDE adopted Avahi once it became stable. In other words, the only community projects using APSL code rejected it the moment there was an alternative - and the reason for developing Avahi in the first place was that several projects refused to ship APSLed code. It's hard to claim that the APSL is regarded as an adequately free or open source license if almost nobody is willing to depend on code under it. In other words, the community has rejected the idea that it's really an open source license. But both OSI and the FSF lack any obvious mechanism of discussing decisions they've made. Both OSI and the FSF have claims to representing the community. How does the community let them know that their views are at odds with it?

Amusing news yesterday, as it's revealed that Roger Knapman, the leader of UKIP (a single-issue party who dislikes the EU, and basically wants to reduce, or remove, immigration), hires Polish builders to work on his country mansion. The bonus punchline: the builders are hired through a Polish-registered company that specialises in hiring eastern Europeans to work in Britian, which is run by Mr Knapman's son.

Mr Knapman, an MEP and the UKIP's leader since 2002, recruited the workers through his son, whose company specialises in bringing foreign labour to Britain. The men have been at Mr Knapman's grade-II listed home in the village of Coryton, west Devon, for 11 months. They sleep dormitory-style in the attic. The company run by Mr Knapman's son claims that the imported labour costs up to 50 per cent less than British workers would. Mr Knapman, speaking to an undercover reporter from The Sunday Times, praised the men as "they work so much harder".

(from The Independent) NP: Boards of Pays-Bas, Poxfil

So, this should be the first blog post of the “DebConf6 Live Blog”, run by the DebConf6 Organizers, which appears on Planet Debian. Lets start with some pictures: I have put up some pictures from my flight (the food :) ), and then from today here in Oaxtepec online. You can find them at our gallery, below the DebConf6 album. Everyone else who takes picture: Feel free to register at the gallery, and then send a little mail to gallery-admins@debconf.org, then you can put all your pictures also online there. On the network side - well, we dont have network up in the Vacational Centre yet, Im sitting in a Internet Cafe down in the town, where some locals are building up Wifi Stuff to get Net to our events place. Lets see how that works out. For the rest: Its a very nice place, really.

It's now just one week until XTech 2006.This is the point that the whole of the last year has been leading up to for me. It's now I can let myself stop being stressed and start to let the excitement in.You know how sometimes you look back at stuff you've done, and go "wow!" -- that's pretty much where I am right now. I've run out of superlatives to apply to the speaker lineup. I've thrilled that we'll be joined by just about the entire Mozilla project, Paul Graham, Jeff Barr, Jeffrey McManus, huge chunks of the BBC brains trust, the smartest people in XML and the semantic web, Ajax pioneers and thinkers, top-class instructors and so much more.Last-minute XTech happenings of interest include:

• Google join the schedule line-up, talking about GData.
• We've put an advert for XTech on Ryan Carson's new magazine for web developers, Vitamin. I've been enjoying Ryan's straightforward approach to web business recently, so I hope this works out well.
• For your inner techie, web caching expert Mark Nottingham joins the XTech program, talking about what's needed to support fast delivery of today's more dynamic web applications.
• We've added a Developers' Corner to the exhibition, where anybody with a project and a laptop can set up to show off their stuff. With the calibre of people floating round, this is a great chance to find collaborators and maybe more.
• A downloadable iCal schedule so there's no excuse for missing anything.
  

Finally, just a note that it's never too late to come along. If you've not registered, just turn up on the day and pay on the door. It's an easy flight to Amsterdam, a short train ride to Centraal and a short walk to the hotel.See you there! 

Last year Black Cat decided they wanted to be more organised about offering dedicated servers. We already had a rackful but they were all in use. So we looked around for a suitable supplier. Originally Dell were the front runner; although they have a bad reputation we already had a bunch of machines from them and they'd been reasonable reliable, did serial BIOS properly and were competitively priced. Dom pointed out that having hotswap drive bays would be a really good plan; we'd already specced the machines with dual drives to enable RAID1, but if they were hotswap then we could easily move drives into a spare chassis in the event something went wrong, meaning the customer could be back up and running again quickly while we investigated the old machine. Good plan. This started to push Dell into ridiculous pricing, so we had a look around. We had some machines from Xinit, which again we hadn't had issues with. They were able to give us a price that wasn't that different to the non hotswap Dells, so we decided to go ahead with them. Bad move. On September 6th I informed them we wanted to go ahead. They'd quoted us a 10-14 working day lead time. As we didn't have a credit account already set up with them and it was likely to take a while to sort out we said we'd pay up front in the interest of getting things moving as quickly as possible. By September 22nd we still hadn't heard anything from them, like even confirmation that payment had been received and an ETA for delivery. So I contacted them, received confirmation they'd received full payment by September 13th and was told we should see systems by September 30th or October 3rd at worst. On September 26th they emailed to say there was a problem with their shipment and we'd be receiving a part shipment with the rest to follow. 4 servers were delivered on October 12th. It turned out none of them had been configured as requested (serial console, 9600 8n1, all set to auto power on after power failure), so I ended up having to plug a monitor and keyboard into each machine before connecting it up to the serial console server and power cycler. I chased Xinit again on 24th October. They'd claimed a 5th server was to be delivered before that and still hadn't told me anything about the remaining 15. I was not impressed. A new contact got back in touch and made all manner of apologies and promises about keeping in better contact and keeping me up to date with what was happening. Suffice to say this didn't happen, and calls to the main Xinit number were of no use as no one could help, and the mobile number I'd been given for this contact was unanswered more often than not. On 1st November we received another 11 machines. These were at least configured as requested, but during our testing we discovered they had been misassembled. 5 machines had CPU heatsinks put on incorrectly; visually misaligned and such that any load caused a machine crash. Very unimpressive from a company who supposedly does full burn in tests on machines before shipping them (and indeed used this as an excuse for not shipping us machines sooner on occasion). Further chasing didn't have much effect, but we eventually received the remaining servers on December 5th. Nearly 3 months after we initially placed the order. While Xinit have happily provided many platitudes they have failed to address the numerous failings in their organisation. They are appalling at responding to phone calls or email. They continuously fail to make good on any of the promises they make. They can't provide realistic delivery dates and don't have the decency to get in contact and let you know when they're going to miss them. They have proved unable to assembly machines to any level of competence; most of what they do is buy in chassis and fit parts to them - this is not complicated and yet they managed to get it wrong on several of the machines we ordered. We were promised a machine or two in compensation, but of course these never arrived. In addition, they're so badly organised that in the middle of March we received a spam from one of their sales people who was completely unaware we'd been customers of them! I cannot stress how much you should never consider using this company. I've spoken to others who've bought machines from them or had dealings with them and I know I'm not alone in this. Really. Don't do it. You'll regret it. I suspect it would have taken less of my time and energy to buy all the parts and assemble the machines myself. I wish I'd done so instead. This does leave me lacking a hardware supplier however. We're in the position of needing more machines, but given recent power pricing increases Xeon LVs (the new Sossaman cores) look like the way forward. Except no one appears to have any stock. And even if they do, how do I know I won't get my fingers burned again?

So about a month ago, I discovered that my driver's licence was stuck in bureaucratic hell. Well the temporary piece of paper licence was due to expire on May 10, and so I called up the DMV again yesterday, and was told it was still pending. So I made an appointment to renew it. Today, coincidentally, I received a brand new 120 day temporary piece of paper licence in the mail, with a note attached:

Your application for a California driver license cannot be completed. California law (Vehicle Code Section 12801.5) prohibits the issuance of a driver license until your legal presence, as authorized under federal law, has been verified. This information has not been received from the Immigration and Naturalization Service (INS). ... Your application will remain valid for 12 months from the date you applied for your driver license. Your license will be issued and mailed to you as soon as the information is received from INS. We regret any inconvenience this may cause you.

The process inconsistencies are incredible. I know of two other E-3 visa holders that have received their proper licences without significant delay. I seem to be cursed.

I've been investigating alternative system inits from time to time the last few years. With the advent of bootchart, there was quite a hype around improving boot times with parallelization and such. Recently this topic has manifested itself in the initscripts-ng group on alioth, and some to-be Google Summer of Code projects. I've been using a modified version of minit for a long time, just lately I was to lazy and switched back to regular init. Since I use suspend2, I don't really reboot my system often anyway. However, minit has more features than being parallel and small. It offers service monitoring and respawning. Which brings me to something missing totally from current linux init systems: service state tracking. Right now, when you start a service, e.g. the web server, you pretty much hope it will never die. Agreed, apache does a good job here. Others may or may not. Mysql uses a really hackish shell script to respawn. And then there are of course tools like monit that check your services and respawn them when needed. There are a couple of things wrong with starting services via SysVInit style scripts from the shell. For example, in order to start a service you need root rights. And then this will "leak" file descriptors from your shell to the daemon (thats why some apps need to be started with "nohup"). Which also causes extra errors with SELinux, for example. And this is just one of the differences from services being started by manually running their init script from the script being run by runlevel changes. Therefore, I think we should move to a new init that can offer full state tracking for services, and is actually used for all services (and not just initial start and getty respawning...) Here's a fairly extensive state diagram I came up with:
Some features I'd like to have in a new init:

• state tracking with interim states
• dependency management with virtual services (e.g. webserver)
• service monitoring and respawning
• control fifos for starting/stopping services through init
• init monitoring socket for e.g. DBUS connector and service failure notifications

Sorry, no comments on my blog, intentionally. Please use the initscripts-ng mailing list for discussion, thats what the list is for!

Wow! It’s out. The government has finally gained the courage to force Telecom to unbundle the local loop. Possibly the most interesting part of the whole announcement is the circumstances of it. Cabinet signed off on it this morning, by midday it had been leaked to Telecom and the Government was forced to scramble to announce it to everyone to avoid regulatory problems from the Sharemarket. No doubt whoever leaked it is feeling very very worried about their job security right now! The Cabinet briefing paper and minutes that accompanied the original press release are a bad quality scan and have obviously been prepared very quickly with hand written corrections to the page
numbers in the latter half of the document. The document has now been removed from the website, which I guess means that it is being touched up. Email me if you want a copy. [Update 1am: It’s now back, but has had information redacted presumably because it is meant to be commercially sensitive!] If you want the hard facts the following are good sources:

• David Farrar’s Analysis
• The Government Press Release and Summary

So, is this a good a thing? I think it is in the long term, but the best part of today’s announcement is what goes alongside the LLU decision, not the LLU itself. More on that in a minute. The Cabinet paper (60 pages) appears to be a very thorough summary of the detailed analysis that has obviously been performed over the previous months. What I think is a fairly reasonable argument is made for why the action is needed and why the chosen course of action is the best option. I’m very impressed with David Cunliffe’s handling of the portfolio and I hope that he continues to work to the high standard that he’s set himself in the few short months since the election. He’s certainly going to face some opposition now! One thing to keep in mind in reading the paper and analysing the information available is that the Government’s hand was forced and there is probably a lot of implementation detail that they would have planned to release with the offical announcement on the 18th. So theres not much point in nit-picking details at this stage. The meat of the announcement is that the Government has chosen a two-stage approach to increase the regulation in the sector. The two stages are basically short and long term actions designed to be complementary. The long term action is the LLU itself and promotion of investment in alternative infrastructure. Because this will not be completed and ready to use in any shape or form until 2008 at the earliest there are also a series of measures to beef up the current wholesale offerings to tide us over and improve the market in the interim. What we get in the short-term:

• UBS without the 512k upstream limitation
• UBS that can support real-time services (VoIP, Games, etc)
• Naked DSL - no Telecom phone service required

With prices and access terms for all these services to be set by the Commerce Commision, which is directed to ensure that the pricing is applied to protect investment incentives. There are a few juicy paragraphs that suggest the Government has considered opposition and is ready for it, such as 113 that warns that is Telecom does not invest quickly enough then full structural separation will be considered. However there are also suggestions (para 113) that Telecom is going to be thrown a bone in the form of a recalculated TSO that will provide higher levels of compensation to support the necessary network upgrades in rural areas. Rodney Hide and no doubt other right-wing groups are already bleating about the “stolen” property rights. But as I see it thats not the case. Telecom still owns the local loop. ISPs do not get to use the copper for free! They must pay Telecom a market rent. LLU is about regulating that price and forcing Telecom to offer the service where there is no incentive for Telecom to do otherwise given their vertically integrated monopoly. Secondly, Telecom was given a chance to avoid this scenario with the 2003 decision not to unbundle. At that point Telecom and its shareholders were warned that if they didn’t invest appropriately and provide a competitive wholesale market the situation would be reviewed. These warnings increased in frequency over the past year. Telecom cannot say that they were not warned. They may have massively misjudged the government, but they were warned. The simple fact is that over the last three years Telecom has played games and stalled as much as possible. In many ways I feel they are the authors of their own misfortune. Overall, I’m very happy and excited. Its a great time to be involved in the Internet industry in New Zealand. The government has churned out an excellent paper that shows that they have carefully analysed the issues and decide on a course of action that I think has an excellent chance of improving the state of broadband in New Zealand. LLU is not viewed as a magic bullet, other measures have been put in place to ease its introduction and investment incentives to build the next generation of access infrastructure are mentioned and regarded as important. The big risk to watch is how the Government goes with the implementation. It is a hugely complex peice of policy to implement, with lots of potential for mistake and they are fighting against a well resourced company with lots to loose. No doubt this will not be my last post on the issue.