No more NDA for events hosted at Google Zurich? //at 21:38 //by abe

I first heard about the Open Source Jam Zurich somewhere at BlogCampSwitzerland 2.0 (which was more a TechCrunch7 than a BlogCamp — why did the organisators call it BlogCamp?) and subscribed to its Google Group.

At Linuxday.at, hansmi (who seems to be assimilated bywork for Google) gave me a flyer about Open Source Jam Zurich. And while reading it, I noticed that it will be held at Google’s Zurich office. Remembering the need for early registration for one of the recent Webtuesdays because of signing an NDA being necessary to get into Google’s office, I asked him, if I need to sign an NDA if I want to take part at Open Source Jam Zurich. He acknowledge it and so I returned the flyer and forgot about the Open Source Jam Zurich.

Today Gürkan told me, he was at Open Source Jam Zurich at Google and he didn’t need to sign any NDA. He also told me that he knows other people which didn’t take part either because of the expected the need to sign an NDA. I was puzzled.

Did Google really started to realize that “Open Source” and “Free Software” doesn’t fit together with “Non-Disclosure Agreements”?

I hope so, because this would make it possible to come to all future Webtuesdays — my favourite local geek event — and not only to those not taking place at Google.

The usual suspects //at 18:08 //by abe

Click here

Thanks to Elmar Heeb for the idea.

Group packages by origin in aptitude //at 02:00 //by abe

I always wondered how others recognise non-Debian packages in the aptitude package tree. I also missed the additional priority level in the hierachy well-known from good old dselect.

For the last one, I quickly found out that you can set the priority as subsection — it’s straight forward after you’ve read the documentation: Just add ,priority at the end of the default grouping method for package views under “Options → UI Options” in the aptitude menu.

Getting the origin as given in the Release file of the repository a package originates from is a little bit more difficult. You need to use the pattern() group function with the appropriate search pattern: pattern(~O)

Since already the default default grouping method for package views doesn’t fit into the dialog, I nowadays just edit /etc/apt/apt.conf directly for changes on aptitude’s default grouping method for package views. It now looks like this on several of my machines:

Aptitude::UI {
  Default-Grouping "filter(missing),status,section(subdir,passthrough),pattern(~O),section(topdir),priority";
};

In aptitude this looks like this:

[...]
  --- text - Text processing utilities
  --\ utils - Various system utilities
    --- Debian
    --- Mowgli
    --- volatile.debian.org
  --\ web - Web browsers, servers, proxies, and other tools
    --- Debian
    --- Opera Software ASA
  --\ x11 - The X window system and related software
    --\ Debian
      --- contrib - Programs which depend on software not in Debian
      --\ main - The main Debian archive
        --- Priority optional
        --- Priority extra
      --- non-free - Programs which are not free software
    --- Mowgli
[...]

Unfortunately this doesn’t work with all non-Debian repositories since a few repository maintainer, e.g. those from Emdebian, arrogate to just keep “Debian” as their packages’ origin. This could be solved, if there’s a possibility to group by e.g. repository URL (host and/or path).

Another problem I haven’t solved yet is that grouping by origin does neither work with locally created nor virtual packages nor tasks — probably since all of them lack an origin. Those branches are just empty or don’t even show up anymore with this configuration. I probably have to dig a little bit more in the aptitude documentation to resolve this.

Now playing: E-Rotic — Max don’t have sex with your ex

Plugins in the Blosxom Project CVS //at 00:34 //by abe

Since yesterday, my Blosxom plugins are versioned in the Blosxom Project CVS repository together with those of most other Blosxom developers.

Cause for this is, that — besides first steps towards Blosxom v4 (we better forget about v3… ;-) and intergrating existing patches (e.g. the Debian config file patch) to Blosxom v2 — the Blosxom developers want to release a Collection of common Blosxom Plugins as a Plugin distribution so that no one needs to gather the often needed plugins from various sites on the net but get them from first hand and also in some kind of a supported way. A first release candidate is on it’s way.

And for those who thought good ol’ blosxom is dead: There never was so much traffic on the blosxom developer’s list like in the past two months — over 160 mails each!

Now playing: Eiffel 65 — Blue

.org registration rules arbitrariness //at 00:36 //by abe

For about nine years, my domain deuxchevaux.org was hosted (which means web, DNS and a catchall e-mail forward) by Internett at Saarbrücken. Although it was a sponsered hosting without much support I was quite happy with their service. But especially my ideas and demands regarding spam filtering grew out of the possibilities of a mass hosting solution. Since I run my own web, mail and name servers for a while now, it was no question that also deuxchevaux.org should become self-hosted.

Since I run a root-server at Hetzner and their “robot” also offers domain handling, I planned to transfer deuxchevaux.org to them. Therefore I first had to register my two DNS servers (sym.noone.org and virt.noone.org) with them. In the documentation there was a note that for .org domains, name servers in a .org domain have to be registered with the same registrar. And just a few hours after registering the name servers via their web interface I got a mail from Hetzner Support that the domain of my name servers are not registered with Hetzner and so I cannot use them form .org domains. Asking for the cause of this rule, I got the answer that this is a rule by Hetzner’s upstream registrar, Cronos AG.

Well, since I don’t understand such arbitrarily looking rules, I was looking around for another registrar with usable web interface. On the DaLUG mailing list, someone recommended eDNS. Since their single user account is free of setup and monthly fees, I signed up with them and started playing around with their web interface. When I tried to transfer deuxchevaux.org using the Auth-Code, I got the response that the transfer failed and when I clicked on “Details”, I got “$VAR1 = [];” as detailed information about the failure. Data::Dumper says hello. I wrote them and asked if they can tell me, what that should mean last Thursday and got no answer so far. I don’t think, I’ll register domains with them anymore.

So where to try it now? Someone recommended GoDaddy, but I neither like their website (way too much targeted on beginners and mainstream) nor do I want to apply for a credit card or a PayPal account to be able to pay their bills.

So a bill from my UML hoster Korypet (aka VD Server) caught my eye: They were lowering prices for registrations at some top level domains (and in comparison to the recent lowerings at eDNS the new prices also apply to existing contracts) including .at and .org (and I only have .at, .ch and .org domains). I didn’t knew they also do domains outside of selling them in packages with UML hosts. So I wrote to Korypet support, if they offer a web interface for domain handling and got a reply less than two hours later: Not yet, but they’re working on it. Until then, I can request domain handling tasks by e-mail to their support. Since I know their UML managing web interface – which works fine – and since I’m happy with their support, service and prices since years (I’m customer there since 2003), I replied with all the necessary data for the transfer.

Well, the transfer failed, too. But in comparsion to Hetzner or eDNS, they made the effort to exactly find out, what happened. So what did happen? The rule which the Hetzner support guy told me that it was from their upstream registrar wasn’t from there but from Public Internet Registry (PIR) itself. And the rule seems to match not that often, so that many people involved in domain registration don’t know about it (and usually neither understand its existence when they hear about it). Also I have no understanding for this harassment and so I felt the strong urge to get one over on them.

Korypet suggested several solutions fitting my needs (i.e. the usage of my DNS servers for my domains). They even offered A records under some of their PIR registrered domains pointing to the IP addresses of my DNS servers for no fee, but luckily some A records under my own .ch domain sufficed.

So the transfer was successful on Friday evening, 6pm local time, my own mail server (running Postfix) was happily rejecting a lot of spam to (and even from) non-existing users (which came in over the catch-all before) as well as hosts greeting with not fully qualified or invalid HELOs and greylisting others via David Schweikert’s Postgrey. The number of accepted mails and recognized spam sunk immediately by approximately factor four on the whole mail server, although deuxchevaux.org isn’t the only domain that receives mail there (but was the only one which had a catch-all before).

So in the long run, I’ll probably move all .org and .at domains over to Korypet since they have not only fair prices but also a competent and individual support. (And yes, this is a recommendation. ;-)

autossh vs TCP resetter //at 00:49 //by abe

LUG-Camp 2007 in Interlaken is nearly over, and I’m reading my mail as usual using ssh, screen and mutt on the server. But the ssh connection resets every few minutes. According to the LUSC people (who are running the gateway) some script kiddie is running a TCP resetter somewhere in the network.

I remembered that I read about autossh in the Debian package list once a while and that it sounded cool but I had no use for it yet. Until now.

I’m writing this over the same crashing ssh connection and I’m typing without taking big notice of the quite often occurring connection resets:

autossh noone.org -t 'screen -rd'

It just works. :-)

Goodbye Woody, Welcome Etch //at 00:53 //by abe

It finally happened. I installed Debian Etch on my last Woody box, a 400 MHz Pentium II with 576 MB RAM named gsa which is my home desktop since I bought it at LinuxTag 2003 in Karlsruhe.

And no I didn’t do a dist-upgrade, neither direct no via Sarge. As already planned I removed some no more necessary operating systems from that box and installed Etch on the freed disk space. Woody is still installed on that box in parallel and was recognized perfectly by Etch’s installer.

I took a few hours but also was big fun to go through Etch package list and to decide what to install. Overall the installation of 5 GB of software took about half a day.

In general everything went fine, the only thing I’m yet missing is sound. Etch didn’t seem to recognize my soundcard at all although it’s a well-known brand and defacto standard for many other soundcards: a Creative Labs Soundblaster. Well, the 16-Bit ISA version, needing the full length of the slot. Worked fine under Woody. Well, I hope I’ll get it working again manually.

What on the other hand is really nice with udev hell —eh— hal and all those new automatic bells and whistles: The desktop (well, at least GNOME Nautilus as well as XFCE, but probably also KDE) recognises when I insert a 3.5” floppy into the drive and shows me a nice floppy icon on the desktop. You think, that’s impossible? Floppy drives don’t inform the rest of the system when a floppy has been inserted without you polling the drive every few seconds? Well, USB floppy drives can. And they do. :-)

I still need time to migrate all the old settings from Woody to Etch. I’ll probably stick with FVWM, but perhaps will use the GNOME enabled version. What’s already done is the migration from tcsh to zsh. On all new or dist-upgraded systems after Etch I’ve chosen zsh so with my last Woody installation retiring I’ve also fully migrated to zsh.

So I’ve got now most of my active private boxes running Etch. Only the noone.org web and mail server “sym” (an amd64 box) as well as my 133 MHz ThinkPad “bijou” are still running Sarge, both with 2.6 kernels.

So with switching to Etch on gsa, I also got no more Debian box running a 2.4 kernel. The only 2.4 kernel I run is on my FreeWRT WLAN router named pluriel, which runs 2.4.33.3. But I expect that 2.6.18 will be as stable and long lasting as the famous and rock-solid 2.4.18 from Woody. 18 seems to be Debian’s favourite kernel minor version recently. ;-)