debian

Debian-Hack: Intruder exploited known vulnerability - quick reaction and resolution, that's good. Kernel on a several-hundred-user system not updated in time, that's rather bad.

Shit hits Fan with Debian?

When Joey throws in the towel - and does so publicly - then the story must really be hitting the fan. Because normally he just quietly fades away ...

Ubuntu and Powerbook

Ok, since my Mac Mini is working hard and everything is functioning as it should, I took the opportunity to install Ubuntu on my Powerbook. I wanted to finally check out how well something like this works today - back in the day, notebooks were quite an adventure with Linux.

Overall, everything looks very good - just like the first impression from the Live DVD. Everything starts properly, the components are mostly well recognized, and the settings are mostly sensible - especially the simple installation (for a test drive, I like to use the DAU mode, just to see how well the people understand their job) leaves a well-set-up desktop system.

Unfortunately, I have a notebook. And not just any notebook, but a Powerbook.

Well, the software itself runs. The desktop is nicely set up, and the selection of software is very useful - even all the notebook features are mostly installed. What was missing?

Well, let's start with the simplest thing: a Powerbook has a fixed keyboard layout - the keys are labeled. I'm not planning to rub off the labeling and repaint it to match a PC. Why don't the Torfnasen provide a Powerbook keyboard layout? I did find something on the net, but to implement it, some major efforts are needed (either applying a not fully functional patch or adjusting the X start process - neither of which are particularly DAU-friendly). Why isn't something like this included with the system? After all, anyone who has seen a Mac keyboard up close knows that it's really not identical to PC keyboards. This is further complicated by the fact that there are quite a few Mac keyboard layouts included - but they only make sense with old ADB keyboards, as they have completely different keyboard codes.

Next up: power management. A lot of software is installed, most of which comes without useful documentation. That's fine - in theory, everything should just be set up. And for the most part, it is set up: when I close my display and open it again, the daemon.log properly records that pbbuttonsd was able to execute the appropriate script.

It would just be nice if the script actually did something...

People, power management is not just a nice-to-have feature for a notebook; it's essential. And everything necessary for it is actually present. Please include it and use it. The Ubuntu installation looks as if the part that would execute the actions was simply left out. And I haven't found out on the fly in which package this might be hidden.

Then there's Bluetooth. The system recognizes all sorts of things, and something is being done with someone - but how, what, and where you can now do something with Bluetooth, that's not really clear. Hey guys, Bluetooth is really not ultra-new anymore, and for Linux, there's been something for quite some time - how about at least some rudimentary tools that show the status?

WLAN still doesn't work - but that's not Ubuntu's fault, it's the stupid manufacturer of the cards. 3D acceleration of the graphics also doesn't work, which is why the desktop is a bit sluggish than it should be - same reason as with WLAN. It's really a shame that hardware manufacturers put extra obstacles in the way of a free operating system.

Minor annoyances: the trackpad is set to be ridiculously sensitive - almost unusable for people with motor problems. More conservative settings would be much more sensible. And Gnome is still quite wasteful with screen space - hey, my notebook only has 1024x768, I can't just add pixels!

All in all, Ubuntu confirms its good suitability as a desktop system - because the installed system itself is really useful. But notebooks are still the last adventure for the toughest.

And my notebook? Well, I'll probably just go back to Tiger.

Linux-Vserver on Debian Sarge - the title says it all. Bookmark for later - could be interesting for my server.

Ubuntu Breezy Badger

I pulled the Live+Installation DVD (hey, T-DSL 3000 rules!) and must say, I'm really surprised. Okay, there are a few issues: the keyboard layout is suggested as the default for the PC - but a Mac notebook can have different layouts (externally a PC keyboard, but internally always a Mac keyboard), so the selection should be a bit more clever. If you switch to the Macintosh keyboard in the selection, special characters like the pipe symbol and curly and square brackets and AT and such no longer work - with PC allocation, however, the labeling of the Mac keyboard does not match. And there is no allocation for the Mac special characters.

What also doesn't work is the second monitor - it is simply not detected and activated, not even initialized. Too bad, because Macs do have multi-monitor support by default, at least the PowerBooks and PowerMac models (the iBooks and iMacs only partially and then only with hacks). That should also be included in my opinion.

But otherwise - nice thing. That WLAN is not recognized is normal - or it is recognized, but not usable. Apple's WLAN chips are often not supported there. I also don't know where Bluetooth is configured - I probably need to install packages first. But that could also be done automatically in my opinion if a Bluetooth adapter is detected. Nevertheless, Ubuntu seems quite nice overall - it starts with usable defaults and already supports a lot of the computer. And the extensive translation of at least menus and dialogs in Gnome is very pleasant.

And that a Debian architecture is working underneath is of course particularly dear to me.

However, it is catastrophic that in the Live CD it seems that no terminal can be started anywhere ...

Sometimes the Debianistas Spin

From the response to a bug report by me about a completely wrong version of mod_perl 2:

I'm afraid you will be out of luck here, if I understand the issues correctly. The official release of mod_perl 2.0 never made it to Sarge, the 1.999.21-1 packages in Sarge is a pre-release. The problem was that shortly before mod perl2 went stable, the upstream developers decided to rename lots of things in the API, and Sarge shipped the old API. Thus, mod perl 2.0 as shipped with Sarge won't run in the rest of the world, and vice-versa. Also, the documentation will be confusing. [...] So, well, this isn't a good situation, but it is something we have to live with.

What? They must have lost their minds. Once again, for clarity: the mod_perl 2 version in Debian Sarge—the current stable Debian—is not compatible with the old mod_perl 1 version or the real mod_perl 2 version because it is a 1.99something with a quite different API. Applications based on it are not portable from the old version and not portable to the new version. Anyone who wants to work with Debian Sarge, Apache2, and mod_perl must first get a backport because the version included is simply completely wrong.

This is absurd. Sure, mod_perl 2 wasn't ready for release on time, but the version currently in Sarge is simply garbage. Instead of removing it, an intermediate version is included, making life difficult for anyone who wants to port mod_perl applications to Apache 2—and doubly so, because with the next release, they'll have to port again.

And then the knockout punch last night:

The only valid complaint in this bug report is the fact that we don't include pre-2.0 API docs in sarge. Debian makes absolutely no guarantees that the version of a package shipped in a stable release will match whatever the current API is on its upstream website.

Summary: we don't understand anything and insist on behaving like complete idiots. Instead of at least removing the junk release—which is also classified as "don't use" by upstream—the missing documentation is now listed as a wishlist bug.

Sooo cool!

BlackDog is a PowerPC computer with 64 MB of memory and a 512 MB flash disc in a mini case that you can plug into any PC with Windows or Linux via the USB port. The PowerPC processor then takes over the keyboard, mouse, and screen, and starts its Debian Linux, whose desktop you can then see on the PC.

The device runs solely on USB power and also has additional biometric access control via fingerprint. Wow. A nice little hacker kit for on the go, you just need to find a host computer.

And it is completely open and hackable in terms of architecture - there is even a hacking competition to develop interesting applications for it. Although I already know what I would put on it - all the necessary network tools. I think I need to motivate the boss at the company to take a closer look at what you can do with such a device. I haven't had such a strong desire to have something for a long time.

There are days when my computer hates me

For example, when I play with Flup and instead of the threaded server I want to use a forked server. And I realize that the latter requires the socketpair function, which unfortunately is only available from Python 2.4, which is available on Debian Sarge, but for Python 2.4 there is no Psycopg in Debian Sarge - which in turn is a prerequisite for Django and PostgreSQL, which is why I am dealing with FastCGI in the first place. Installing Psycopg itself is no fun, as you not only need the PostgreSQL headers that are normally installed, but also a few internal headers - so in principle a build tree. And then you also need the egenix-mx-base headers, which you can only get for Python 2.3, so you would have to install that yourself as well. Backports from the next Debian version don't work either, as they are just switching to PostgreSQL 8.0 and Sarge is still using 7.4 and I didn't want to upgrade the whole system right away. And so you go in circles and feel a bit cheated by all the dependencies and version conflicts.

And what do you do as a solution, because the threaded server unfortunately only produces segfaults in Psycopg? You take the threaded server, forbid it to thread and start it via the spawn-fcgi from lighttpd, or directly from lighttpd. But that's somehow stupid again, because then there are always 3 threads per FCGI server, two of which just stand in the process list and do nothing. And all this just because mod python2 (which is needed for Django) requires Apache2, which in turn requires mod perl2, which is incompatible with the old mod perl, which is why a whole bunch of my sites wouldn't work anymore if I switched to Apache2. Which I don't want to do anyway, because Apache2 with mod python is damn slow. And once again I feel cheated. I really should have looked for a more meaningful job.

If you didn't understand anything: doesn't matter, it's technology, it's not important, I just wanted to say that.

First Django Tutorials Online

The Django programmers start with the tutorials. The first tutorial primarily deals with creating the database model and the basic code for the objects to be managed, and the second tutorial deals with the automatically generated administration interface. Very nice, all of it.

The system is of course strongly focused on content creation and management - but still general enough so that it can also be used for differently structured content. The entire administration is automatically created from the object model and some hints, so it always aligns with the real data in the system. And the default look is also quite appealing.

Server integration is done simply via mod python - so via Apache. Which is also an advantage, as mod python offers very high performance right out of the box. And for more demanding cases, there's the caching in Django. I must say, what I've seen of Django so far, I like it very much.

An important note is missing in the installation instructions: Apache2 is mandatory, and therefore also ModPython in the corresponding version. However, Mac OS X only provides Apache 1.3, and many other servers also only have the 1.3 Apache available, so Django still has a real drawback here.

By the way, if you want to upgrade from Apache to Apache2 on Debian: if mod perl is in use, forget it. The mod perl2 for Apache2 in Debian Sarge is complete garbage - as if the API changes in mod perl2 compared to the old mod perl weren't annoying enough. In principle, you can no longer get Perl modules to run so easily with it.

Update: By the way, there is currently a lot of activity in the Subversion for Django to eliminate the requirement for Apache. A simple development server is already included, so in the future you will no longer need Apache for initial experiments. And you could also set up the deployment on other legs in the long run - for example, FCGI behind lighttpd.

Update 2: The third tutorial is out and deals with the view for the visitor. They have a pretty intense pace right now with Django.

System upgrade on simon.bofh.ms

Since I need to upgrade a Debian 3.0 to 3.1 somewhere to gain some experience for the company, I'm just using my own server. So, it might be that things get a bit messy here in the next time or something might fly around your ears. You have been warned.

System Upgrade simon.bofh.ms Part 2

Ok, the system upgrade is basically done. The only losses so far are the mailing list system - although that's mainly because I simply have no interest in running it anymore. In principle, it was completely updated, I just threw it out because I don't want to do anything else with it - there was only one list in it. And otherwise, mainly old junk has been thrown out.

However, after two system upgrades, I have to say that I'm not really enthusiastic about this upgrade - it already shows the problem of the extremely long release cycle. The first upgrade went through quite smoothly - the machine in question was one that already ran Sarge, just an old version from Testing and not the current Stable. The upgrade caused no problems.

The second upgrade, however, was simon.bofh.ms - a machine that was still largely on Stable, with a whole range of backports (self-made and from the net). The latter is of course the real problem - because the release cycles are very long, it is often necessary to install packages yourself. The Debian upgrade mechanism should still handle this. But reality shows that packages from backports often refer to intermediate states in which bugs in testing packages are present or simply special features that were not taken into account. As a result, a whole range of package upgrades were very tricky and I would not want to subject any normal user to going through that.

The highlight of all the problems was the PostgreSQL upgrade, which went through cleanly but then did not start due to an outdated option in the config. The messages were so cryptic that even I could not immediately see what it was - only digging in the logs and looking in the scripts confirmed to me that the upgrade was clean and really only the start had jammed.

However, I still have to say that the upgrade of a machine with partly up to 3 years old program versions went surprisingly well and 99% of the packages were updated completely problem-free - even things like my rather exotic Exim4 installation (a self-made backport with special features) went through quite smoothly - manual fixes were necessary, but I had caused them myself. The Apache and the whole PHP mess ran completely problem-free, the MySQL database also ran immediately. And one should also note that the whole upgrade - although described by me as suboptimal - only took 1:45 hours. And most of that was waiting for the packages to unpack ...

Well, in the next few days it will show what else has broken and which of the scripts no longer run that I have overlooked so far.

Debian GNU/Linux 3.1 released - wow. It took quite a while

Debian plans to reduce the number of architectures - I don't know if that's such a great idea. The many architectures were one of the pro-arguments for Debian. Of course, exotic architectures can cause problems - especially when they simply can't keep up during the recompile orgies that are due for a release (I'm thinking of the 68K architecture here). Nevertheless, it's a shame if this aspect of Debian is weakened.

Zyklische Dependencies

Debian hat ein wunderschönes Paketsystem. Und es hat eine ganze Reihe von sehr brauchbaren Werkzeugen um Backports einfacher zu machen - zum Beispiel in dem man mit debootstrap ein chroot-Environment zusammenstellt in dem man gefahrlos die Pakete zusammentragen kann die man für den Build braucht und dann ein entsprechendes Paket erstellt. Ich habe das ganze schon mehrfach benutzt, es ist wirklich klasse.

Allerdings kann einen das auch manchmal in den Wahnsinn treiben. Ich wollte die neuste SQLite aus der Debian Testing installieren. Dazu brauche ich erstmal die nötigen Tools um das Paket builden zu können. Da ich ein neues chroot Environment aufgesetzt hatte, war noch nicht alles da - zum Beispiel fehlte mir cdbs, ein sehr mächtiges (und mitlerweile viel benutztes) Tool zur einfachen Erstellung von Debian Paketen. Das hatte ich schon mal vorher portiert, aber ich dachte mir die Gelegenheit sei günstig da mal eine aktuelle Version zu bauen.

Dachte ich. Fing auch ganz harmlos an - es braucht für die Dokumentation springgraph - ein Tool zur Formatierung von Grafen. Das Tool selber hat eigentlich keine Builddependencies (ausser den obligatorischen Debhelpern). Fein. Baut auch sehr schnell. Bei der Installation meckert es dann über fehlende Perlmodule für die GD2 Einbindung. Ok, Perlmodule zu portieren ist oft nervig, aber dieses sah eigentlich ganz simpel aus. Eine Reihe von Buildabhängigkeiten, klar, aber sonst harmlos. Bis auf den Fakt, das es zum Builden cdbs braucht.

Aaaaarghl!!!!

Okok, ich weiss was man machen muss. Trotzdem. Manchmal hab ich das Gefühl die Debian-Maintainer setzen sich heimlich zusammen um mich in den Wahnsinn zu treiben

Debian Backports - Backports von Debian Paketen - die Antwort auf "stable ist veraltet"

Writing DVDs under Debian GNU/LINUX - DVDs unter Debian GNU/Linux benutzen - auch DVD-RW und +RW

Glibc-based Debian GNU/kFreeBSD - Debian auf dem FreeBSD Kernel

Index of /~erich/bricolage - Debian Pakete für Bricolage

Index of /~vorlon/d-i/xfs - Debian Sarge Netinst CD mit XFS Unterstützung