CBlog

Some weeks ago, someone asked on the opensuse-wiki mailinglist if it's acceptable to move documentation (in this case about Icecream) from the openSUSE wiki to the upstream repo on github. One of the arguments was:

I think I should store anything I do for the openSUSE project somewhere in the openSUSE.org domain, not in a RedHat.org or Canonical.org domain or a SourceForge.net or GitHub.com domain.

While this sounds like a valid argument and for sure shows good intentions, I wrote a longish reply:

You are overlooking an important point here - collaboration.

It doesn't make sense to think of "we" vs. "them" when it comes to other distributions or upstream projects. It's quite the opposite - everybody can save time by working together with other distributions, upstream projects etc. We have more important things to do than re-inventing the wheel just because we need a green one.

As an example: You might know that I maintain AppArmor in openSUSE and also contribute upstream (OMG, the upstream mailinglist is @lists.ubuntu.com, not at a "neutral" domain!)

Some not-so-known details:

• I implemented support for new AppArmor rule types (dbus, signal etc.) in aa-logprof, but those are not yet supported in the upstream kernel (and also not in openSUSE) - so currently only Ubuntu users benefit from that
• I always send patches upstream so that everybody can benefit (no, saying "use openSUSE, it's fixed there" is not a good idea ;-)
• In 2015, I visited DebConf (I'd guess I was the only one there who had never used Debian before) and even gave a talk.
• I closely follow AppArmor-related bugreports in Debian and Ubuntu, and help them to get things fixed - even if it's distro-specific

So, tell me - am I working for the enemy? ;-)

 

BTW: This isn't a one way road. Quite some AppArmor contributions done by Ubuntu (some other upstream developers work for Canonical) and Debian contributors end up in openSUSE ;-)

Needless to say that AppArmor is just an example. What I said is basically valid for every package, project, whatever. Either you collaborate (and everybody wins), or you "cook your own soup" and never find out that someone else has a receipe for a much more tasty soup ;-)

Since I talked a lot about AppArmor in the above text, let's see what's new there.

You might have noticed that there were some AppArmor releases recently:

• AppArmor 2.9.4 (with several bugfixes and profile updates) was already released as an update for openSUSE 13.2 shortly before it went out of support.
• AppArmor 2.10.2 (also with several bugfixes and profile updates) is already available in Tumbleweed, and updates for Leap 42.1 and 42.2 are under review
• AppArmor 2.11 (with lots of improvements and new features - for example, I rewrote the handling of file rules in aa-logprof etc.) is on its way to Tumbleweed (SR 453537), but it seems splitting off libapparmor into its own spec file (to fix a build loop) triggered a bug in the factory-auto review bot. Given my talent to find bugs, I'm not even surprised ;-)

The rewrite of the file rule handling resulted in a nice series of 42 patches which replace 1600 lines of code using a deeply nested array with 1200 lines with the more readable and easier maintainable FileRule and FileRuleset classes (a total of 530 lines) and functions using these classes. Even with 400 lines less code, I added some small features (for example, rules with leading permissions like "r /etc/fstab," are now supported) and fixed some bugs along the way.

The old code to handle file rules had very few unittests, which made this rewrite (and especially avoiding breakage and regressions) quite challenging. On the positive side, my patch series added full test coverage for the FileRule and FileRuleset classes, and also added unittests for most of the functions using FileRule and FileRuleset. (Unfortunately full test coverage isn't always easy, especially for the interactive parts of aa-logprof.) Those unittests add about 1400 lines of code, but as long as such additions happen in the tests directory, I'm more than happy about them ;-)

Oh, and the final challenge hit the other AppArmor developers. AppArmor has the policy that all patches have to be reviewed, and reviewing the whole patch series (which summed up to +2600 -1628 lines) took some time ;-)

That all said, let's not forget to answer where the documentation should live:

To come back to the origin of this discussion: I don't care too much where the Icecream developers host their documentation as long as

• it is complete and up to date (having it at the developers' favorite place makes this more likely)
• it can be easily found (also not a problem, it's linked from the wiki, and your favorite search engine will also find it)

I see the main purpose of the openSUSE wiki to provide openSUSE-specific information.

Information about upstream projects (even if a project is done by openSUSE) is "nice to have", but it's also ok if it lives upstream. It's better have one good upstream documentation than pages at 5 distro wikis that are all incomplete and out of date ;-)

BTW: The question "Am I working for the enemy?" was mostly meant as a rhetoric question - but if you want to answer nevertheless, please add a comment ;-)

Mit meinem "1001 Bugs"-Vortrag habe ich die openSUSE Conference überlebt, obwohl mancher Entwickler vermutlich nicht ganz glücklich war, dass ich einen seiner peinlichen Bugs entdeckt hatte ;-)

Daher hielt ich diesen Vortrag in leicht überarbeiteter Form und in deutsch auch auf dem LinuxTag. Den ca. 80-90 Zuhörern hat es scheinbar gefallen - neben einigen Lachern zwischendurch bekam die "spezielle Regel für openSUSE" sogar Szenenapplaus :-)

Wer den Vortrag auf dem LinuxTag verpasst hat oder sich die Folien (incl. Notitzen) nochmal ansehen will - bitte schön:

1001 Bugs - oder: die goldenen Regeln für schlechte Programmierung als PDF
(Die LibreOffice-Datei stelle ich auf Anfrage gern bereit.)

If you missed my talk at the openSUSE conference or want to see the slides (including notes) again - here we are:

1001 bugs - or: the golden rules of bad programming as PDF
(If you need an editable LibreOffice file, just drop me a note.)

1001 bugs - das ist eins der Ergebnisse meiner Mitarbeit bei (open)SUSE: Ich habe vorhin meinen 1001. Bugreport eingereicht. Außerdem werde ich unter dem Motto "1001 bugs - or: the golden rules of bad programming" einen Vortrag auf der openSUSE conference halten. Die genaue Beschreibung meines Vortrags steht unter dem englischen Text. Ich habe schon eine ganze Reihe von Ideen für den Vortrag, bin aber für Vorschläge in den Kommentaren offen.

Wer sich für meine Bugzilla-Statistik interessiert, findet unten den Screenshot. Man sieht deutlich, dass ich bei SUSE Linux 9.2 mit dem Betatesten angefangen habe und seitdem die Entwickler mit Bugreports zuschütte ;-)

1001 bugs - that's one of the results of my work on (open)SUSE: I just filed my 1001. bugreport. Besides that, I'll give a talk "1001 bugs - or: the golden rules of bad programming" at the openSUSE conference. I already have lots of ideas for my talk, however I'm open for proposals - just add a comment here.

If you are interested in my bugzilla statistics, have a look at the screenshot below. You can clearly see that I started beta-testing with SUSE Linux 9.2 and since then overwhelm the developers with bugreports ;-)

But first I'll give you the the detailed description of my talk:

1001 bugs - or: the golden rules of bad programming

You'll find lots of books telling you how to write good code. That's nice and maybe even useful, but boring ;-)

My talk will give you something more inspiring: the golden rules of bad programming. It also comes with some interesting[tm] things I've seen in bugzilla as topping.

Most examples will be in pseudocode to be understandable for everybody.

Bugzilla report for "reporter contains @cboltz.de"
(the reports for 9.x and some other products are non-public, which means you'll probably get a lower number)

Erstmal ein kleines Schnipsel aus meiner Konsole:

Let's start with a sniplet from my console:

cb@geeko:~/postfixadmin> svn help | head -n1
usage: svn <subcommand> [options] [args]
cb@geeko:~/postfixadmin> cd /home/cb/apparmor
cb@geeko:~/apparmor> svn help | head -n1
Bazaar 2.0.5 -- a free distributed version-control tool

Mein SVN ist nicht verrückt geworden ;-) - ich habe nur ein kleines Script vorgelagert, das man am Besten als Verzeichnis-abhängigen Alias bezeichnen könnte. Wenn ich im Verzeichnis ~/apparmor bin, wird aus "svn" wie durch Geisterhand ein "bzr"-Aufruf. Das Script ~/bin/svn ist nicht wirklich kompliziert:

My SVN didn't go crazy ;-) - I just prepended a small script you could best describe as directory-dependent alias. When I'm working in ~/apparmor, it magically replaces "svn" with a "bzr" call. The script ~/bin/svn is not really complicated:

#!/bin/bash
command=/usr/bin/svn  # use the full path. Just "svn" will result in an endless loop!
pwd | grep -q ^/home/cb/apparmor && command=/usr/bin/bzr
exec $command "$@"

Warum ich das Ganze brauche? Ich habe seit kurzem Commit-Rechte bei AppArmor, damit apparmor.vim endlich ein offizielles Zuhause hat. Außerdem habe ich schon ein paar Profil-Updates commited. (Keine Angst: vom C-Code werde ich mich fernhalten ;-)

AppArmor verwendet Bazaar für die Versionskontrolle, und das ist glücklicherweise Parameter-kompatibel zu SVN (zumindest bei dem, was ich brauche) und erspart mir so die Umgewöhnung an noch eine Versionsverwaltung.

Nebenbei: Für Bazaar musste ich mir einen Launchpad-Zugang einrichten, und habe natürlich[tm] auch gleich einen Bug in Launchpad gefunden ;-)

Why do I need this? Since a short while, I have commit access for AppArmor. This finally gives apparmor.vim an official home. I also commited some profile updates. (Don't worry - I'll stay away from the C code ;-)

AppArmor uses Bazaar as version control system, which is luckily parameter compatible to SVN (at least for the commands I use). This means I don't have to keep another version control system in mind.

BTW: For Bazaar I had to create a Launchpad account, and of course[tm] found a Launchpad bug instantly ;-)

Prosit Neujahr und alles Gute für 2010! Dieser Artikel enthält einiges, das ich schon 2009 bloggen wollte, und außerdem eine kleine Neujahrsüberraschung von SpamAssassin ;-)

Happy New Year! This article contains some things I wanted to blog about in 2009 already, and a little new year surprise from SpamAssassin ;-)

• PostfixAdmin 2.3 wurde im Oktober 2009 releast, RPMs gibt es natürlich im openSUSE Build Service
  PostfixAdmin 2.3 was released in october 2009, RPMs are available in the openSUSE Build Service


• Postfixadmin 2.4 (oder 3.0?) wird Smarty für die Templates verwenden
  PostfixAdmin 2.4 (or 3.0?) will use smarty for the templates


• PostfixAdmin 2.3.1 (alle Bugfixes seit dem 2.3-Release, aber ohne Smarty) ist in Arbeit
  PostfixAdmin 2.3.1 (with all bugfixes since 2.3 release, but without smarty) is under development


• openSUSE 11.2 wurde im November 2009 releast, und auch gleich von uns (Jan, Jan-Simon und mir) auf der Open Source Expo in Karlsruhe präsentiert
  openSUSE 11.2 was released in november 2009, and presented by us (Jan, Jan-Simon and me) at the Open Source Expo in Karlsruhe


• und die Neujahrsüberraschung von SpamAssassin: 2010 bekommt jede Mail erstmal 3.188 Punkte... - Bugreport
  and the new year surprise from SpamAssassin: every mail in 2010 gets 3.188 points... - Bugreport
  

Auf der Typo3-Website eines Kunden verwende ich th_mailformplus für ein Webformular mit Dateiupload. Funktioniert auch soweit, allerdings wurde die hochgeladene Datei (trotz entsprechender Konfiguration des Formulars) nicht an die Maill angehängt.

Seit vorhin kenne ich den Grund: Der Mail-Funktion wird nur der Dateiname ohne Pfad angegeben, und dadurch findet die Funktion natürlich die Datei nicht und kann sie auch nicht anhängen :-(  Außerdem endet der Dateiname noch mit \n.

Ich habe eben einen kleinen Patch in den Typo3-Bugtracker hochgeladen, der den Pfad beim Dateinamen einfügt und das \n per trim() entsorgt. Und schon werden Mails mit Anhang verschickt :-)

I use th_mailformplus for a mailform with file upload on a customer's typo3 website. Works mostly, but the uploaded file was not attached to the mail (even if the mailform config was correct).

Since a short while ago I know the reason: The mail function is called with the filename without path, and therefore obviously can't find the file :-(  Besides that, the filename ends with \n.

I just uploaded a small patch to the Typo3 bugtracker which inserts the path into the filename and removes the \n using trim(). Now mailformplus sends mails with attachments :-)

Schöner Titel zum Mitraten, oder? ;-)

Paste Search ist ein unspektakuläres PHP-Script, das aber die Usability von Konqueror (und anderen Webbrowsen) enorm verbessert. Konkret geht es um das Verhalten beim "Mittelklicken" des Browserfensters, das normalerweise eine Google-Suche auslöst und nach dem Begriff in der Zwischenablage sucht. Dieses Standardverhalten ist schonmal gut, aber oft habe ich andere Ziele - beispielsweise ein Bugreport auf bugzilla.novell.com oder im SourceForge Tracker.

Die Lösung ist relativ einfach: Das folgende PHP-Script wird auf einen Webserver hochgeladen und als Standard-Suchmaschine im Browser eingetragen. Ab diesem Zeitpunkt wird bei Zahlen automatisch im Bugtracker gesucht (die Unterscheidung erfolgt anhand der Nummer - alles bis 500000 geht an bugzilla.novell.com, der Rest an SourceForge), bei Text mit Google.

Nice title to guess on, right? ;-)

Paste Search is an unspectacular PHP script that greatly enhances the usability of Konqueror (and other web browsers). To be exact, it is about the behaviour when "middle-clicking" the browser window which usually starts a google search for the content of the clipboard. This default behaviour is not bad, but sometimes I have other targets - for example bugreports on bugzilla.novell.com or in the SourceForge trackers.

The solution is quite simple: Upload the following PHP script to a webserver and configure your browser to use it as default search engine. If you paste numbers to your browser now, it will go to the bugtracker automatically (the selection depends on the bug number - up to 500000 goes to bugzilla.novell.com, everything above to the SourceForge tracker). If you paste text, you will be redirected to Google.

<?php # cbPasteSearch.php
if (empty($_GET['q'])) {
    echo "Please run me with ?q=searchterm";
} else {
    $q = trim($_GET['q']);
    if (preg_match("/^[0-9]+$/", $q)) { # numeric
        if ($q < 500000) { # Novell bugzilla
            header("Location: https://bugzilla.novell.com/show_bug.cgi?id=$q");
        } else { # SF tracker
            header("Location: https://sourceforge.net/support/tracker.php?aid=$q");
        }
    } else { # not numeric - ask Google
            header("Location: http://www.google.de/search?q=$q");
    }
}
?>

Natürlich kann man sich das Script nach Bedarf durch zusätzliche if-Abfragen anpassen. Vorschläge dazu nehme ich in den Kommentaren gern entgegen ;-)

Of course you can customize the script as needed by adding additional if statements. Please add your ideas to the comment section ;-)

Muss ich dazu wirklich etwas sagen?

Na gut, für den Fall, dass jemand das Problem nicht sieht: Ein Passwort, das im Klartext angezeigt wird, kann niemals sicher sein. Dass direkt daneben Tipps für ein sicheres Passwort gegeben werden, würde ich als ironisch bis peinlich bezeichnen.

Beim Runterscrollen kommen übrigens noch bessere Tipps:

• Ändern Sie Ihr Passwort sofort, wenn Sie den Verdacht haben, dass es einer anderen Person bekannt sein könnte.

Hinter mir sitzen ein paar Leute, also: Waaaaa-aaaaas, alle 10 Sekunden Passwort ändern?!

• Notieren Sie sich niemals Ihr Passwort.

Dann brauche ich ganz, ganz dringend Tipp-Ex auf dem Bildschirm...

Lustigerweise ist das (im Vergleich zum Vertragspasswort) eher unwichtige Mail-Passwort besser geschützt - das kann man sich nicht anzeigen lassen, sondern nur ändern. Im Gegenzug wird das FTP-Passwort im Klartext angezeigt. Klar, das ist ja auch wertvoller als Mailpasswörter, warum sollte man das verstecken? *grummel*

Bevor sich jemand wundert, warum ich mich plötzlich bei 1&1 rumtreibe: Abschlussarbeiten einer Kündigung, die Domains habe ich gerade zu mir umgezogen :-)

packages.debian.org geht fremd ;-)

Leider gibt es immer wieder traurige Gegenbeispiele. fefe hat jetzt entdeckt, dass packages.debian.org die URL-Parameter ungeprüft übernimmt, inclusive der auf der Seite angezeigten MD5SUM des Pakets. Sowas ist ziemlich blauäugig ;-)

Vor ein paar Stunden konnte man noch beliebigen HTML-Code einschleußen (siehe Screenshot - ja, soviel Spaß muss sein), inzwischen wird "immerhin" die MD5SUM auf Länge und erlaubte Zeichen überprüft. Eine falsche MD5SUM ausgeben geht immer noch, solange die Länge stimmt.

Eine falsche MD5sum in Verbindung mit einem manipulierten FTP-Server heißt de facto, dass jemand ein gefaktes Paket mit beliebig bösem Inhalt anbieten kann und das nichtmal auffällt. Auf debian-www hält man sowas aber für "low risk". Es geht ja auch nur um potenziell gefakte Pakete mit bösen suid-root Programmen...

Was fefe übersehen hat: auch die anderen Parameter sind beliebig manipulierbar. Ich bin mal gespannt, wie lange Debian den Internet Explorer zum Download anbietet *eg*

Wie man sowas manipulationssicher programmiert? Eigentlich recht einfach - man packt die Nutzdaten (Paketnamen, MD5SUM usw.) in eine Datenbank und übergibt dem Script nur die ID als Parameter.

UPDATE: Inzwischen wurde die RegEx etwas verschärft und erlaubt nur noch [0-9a-f]. Ich habe die obigen Links etwas angepasst, damit sie weiterhin funktionieren. Falsche MD5SUMs kann man immer noch einschleußen...

Übersetzt? Soso...

Die schlimmsten Bugs, die ich entdeckt habe, sind zwei Probleme im Paketmanager. Der eine sorgt für einen Hänger, wenn eine (Online-)Installationsquelle nicht verfügbar ist (#221071), der andere für einen riesigen Stapel Fehlermeldungen, wenn eine Installationsquelle eine Apache-Fehlermeldung statt der Metadaten liefert (#218552). Als Workaround hilft es, nur funktionierende Installationsquellen zu verwenden ;-)

Falls sich jemand Sorgen um den Status des Paketmanagers macht: diesmal funktioniert er wirklich ;-) out of the box und muss nicht erst wie bei 10.1 zurechtgepatcht werden. Ach ja, und man kann zmd und zen-updater durch opensuse-watcher ersetzen, der direkt auf libzypp aufsetzt. Bleiben nur noch die kaputten Berechtigungen bei permissions.secure (#216485).

Der einzige Bug, der in der täglichen Arbeit nervt, ist ein hyperaktiver artsd, der den Prozessor unnötig beschäftigt (#178930) - naja, dafür gibt es killall -9...

Dazu kommen die üblichen Kleinigkeiten - ein paar verwirrende Schaltflächen (#218677), eine komische Übersetzung (#220668) oder auch ein fehlendes Leerzeichen (#220875).

Ach ja, das Syntax-Highlighting for AppArmor-Profile in vi funktioniert dank meiner Mithilfe wieder (#190084).

Am schönsten fand ich aber die Tipps beim KDE-Start (Screenshot rechts oben). Dort wird u. a. erklärt, dass KDE in viele Sprachen übersetzt ist - und genau dieser Text ist nicht übersetzt *g* (#221177 - hmmm, sollte ich den wegen Peinlichkeit zum Blocker machen?)

Zur Abwechslung biete ich "404 bugs found" ;-)

Ja, von SUSE Linux 9.2 beta bis heute hat sich einiges angesammelt. Darunter waren einige Dauerbrenner, z. B. der Dualhead-Betrieb auf meinem Laptop (#61858), der dem Blinker-Prinzip folgt (pro SUSE-Release: geht, geht nicht, geht, ...) und PHP open_basedir, das ich gern pro vHost setzen würde - dummerweise werden aber die Einstellungen der vHosts bunt durcheinandergemischt (#136651). Der letzte "Fix" vor einiger Zeit war leider wenig erfolgreich. Ich bin ja mal gespannt, ob der jetzt angekündigte Patch das Problem endlich behebt ;-)

Andere Bugs befassten sich mit Ausnahmesituationen (z. B. dass /var/lib ein Symlink ist ;-) - #181606) und wieder andere "nur" mit ungewohnten Tastenfolgen für Datei - Öffnen (#215576). Auch der Spaß kam nicht zu kurz, wie beispielsweise einige Kommentare in Bug #141107 oder Bug #180796 zeigen. Dazu kamen diverse Verbesserungsvorschläge, von denen manche sofort und manche nach deutlichem Nachhaken (#206414, #143648) umgesetzt wurden. Beim Betatest der 10.1 hatten insbesondere die Programmierer von YaST und der Paketverwaltung ihre Freude - in diesen Bereich fielen 64 meiner 152 Bugreports zur 10.1 (was mich nebenbei zum zweitaktivsten Bugreporter nach Andreas Jaeger (182 Bugreports) gemacht hat ;-)

Nicht nur die Programmierer, auch das Doku-Team hatte seinen Spaß mit mir (oder umgehehrt?), als ich im berühmt-berüchtigten Bug #65000 (#50000 zu Zeiten von bugs.suse.de; ich habe zwar trotz der runden Zahl nichts gewonnen, aber "lots of people here were annoyed by it - they wanted to file this magical number themselves ;))") diverse Fehler im Handbuch ("handbug?") der 9.2 berichtete. Jede Büroklammer im Handbuch markierte einen Fehler im Kapitel "Shell", das Foto ging vorab ans Doku-Team. Die erste Reaktion seitens Jana Jaeger auf meinen Bugreport war dann übrigens "@bugreporter: please do not ever touch a paperclip again ... :)"

Inzwischen helfe ich gelegentlich auch selbst bei der Fehlerbehebung, beispielsweise in pin und in apparmor.vim (vim Syntax-Highlighting für AppArmor-Profile).

Nur einen Bug konnte ich bis heute nicht beheben: der Tag hat leider nur 24 Stunden. Egal, nehme ich eben die Nacht dazu ;-)

Ach so: Die älteren Bugreports für SUSE <= 9.3 sind nur für alteingesessene Betatester zugänglich, daher sind nur rund 290 Bugs öffentlich sichtbar. Vermutlich erhöt sich die Zahl aber demnächst - ich will morgen openSUSE 10.2 beta1 installieren...