Netz - Rettung - Recht

Das Internet ist schon lange kein friedlicher Ort mehr, an dem jeder jedem trauen kann - und deshalb wurden die ursprünglichen, unverschlüsselten Kommunikationsprotokolle schon lange durch kryptograhpisch abgesicherte Variationen ersetzt. Telnet verwendet heute wohl niemand mehr offen im Netz, stattdessen gibt es SSH; auch im Mailverkehr pflegt man - hoffentlich - zumindest das Paßwort beim Abruf über POP3 via APOP und beim Versand via SMTP über eine SMTP-Aut-Variante mit Verschlüsselung zu sichern, wenn man nicht ohnehin die ganze Kommunikation SSL-verschlüsselt, und auch diejenigen, die FTP noch nicht durch SCP/SFTP ersetzt haben, nutzen hoffentlich wenigstens SSL, um die Paßwortübertragung zu verschlüsseln.

So weit, so gut, aber schon vor einer ganzen Weile fiel mir auf, daß diese Regel für Netnews (NNTP) offenbar nicht gilt (und für UUCP oft auch nicht …); denn zu seinem oder seinen Newsserver(n) verbindet man sich oft genug noch unverschlüsselt, obwohl auch dort ein Paßwort übertragen wird. So ging es zumindest mir, und ich habe mich am vergangenen Wochenende entschlossen, dagegen etwas zu unternehmen und auch die Verbindung zumindest zu meinem eigenen Newsserver zu verschlüsseln.

"INN und SSL/TLS (Debian Lenny)" vollständig lesen

Ich muß ja gestehen, daß ich Blumen, Pflanzen und alles, was sonst noch so grünt und blüht, manchmal ganz nett finde (besonders, wenn es sich um eßbare Pflanzen in bereits zubereiteter Form handelt), aber eigentlich bisher noch nicht das Bedürfnis verspürt habe, Wohnung oder gar Büro floristisch zu dekorieren.

Glücklicherweise stehe ich zwar mit dieser Ansicht alleine, wohne aber nicht alleine, und so wurde ich gestern über meinen Aktenstapeln - bestens mit Capuccino und Rhabarberkuchen versorgt - kurzfristig zugunsten weiterer Einkäufe von Blumenkästen und dazugehörigen Blumen verlassen. Und während ich heute einen mehrstündigen Abstecher ins Büro gemacht habe, wurden die letztgenannten unter Hinzunahme etlicher Blumenerde in die erstgenannten verpflanzt. Das Ergebnis kann sich sehen lassen, finde ich.

Ich überlege nur gerade, ob ich die Blumen wohl zukünftig gießen muß?

Die vergangene Woche war es sehr ruhig in diesem Blog; das liegt nicht daran, daß es nichts gäbe, über das es sich zu schreiben lohnt, sondern vielmehr an der an allen Ecken und Enden fehlenden Zeit. Leider ist aus der Woche auch noch genügend Arbeit für das Wochenende übrig geblieben - aber immerhin fällt es etwas leichter, wenn man sich mit Laptop und Aktenstapeln in die Sonne setzen kann, die heute ja reichlich geschienen hat.

Und, davon abgesehen: was wäre die Arbeit ohne Pausen mit Kuchen und Schlagsahne?

Heute habe ich - zufällig - am Frühstückstisch einmal einen Blick in die Sonntags-FAZ geworfen und bin natürlich direkt bei der Schlagzeile auf Seite 23 gelandet: ”Der Staatsanwalt in meinem Bett” (statistisch gesehen ist das vermutlich ein Erlebnis, das nachts gar nicht so wenige Frauen machen, denn auch Staatsanwälte sind ja ab und an verheiratet, aber darum soll es hier nicht gehen). Inhalt des Beitrags ist das Ermittlungsverfahren der Staatsanwaltschaft Darmstadt gegen die Sängerin Nadja B. wegen gefährlicher Körperverletzung durch ungeschützten Sexualverkehr trotz bekannter HIV-Infektion.

Nun kann man zu der Sache stehen, wie man will - die rechtliche Würdigung als gefährliche Körperverletzung, in einem Fall vollendet, in mehreren Fällen versucht, ist unspannend, nicht neu und bereits ausjudiziert; der Erlass und Vollzug eines Haftbefehls ausgerechnet wegen "Wiederholungsgefahr" läßt in diesem Fall eher schlüpfrige Gedanken aufkommen und verwundert ein wenig, zumal mit dem Bekanntwerden des Vorwurfs die Wiederholungsgefahr zumindest stark eingeschränkt sein dürfte; und über die Pressearbeit kann man sicherlich diskutieren, wobei ich eher auf dem Standpunkt stehen würde, daß es durchaus Aufgabe und sogar Verpflichtung einer Behörde ist, die Öffentlichkeit - und damit in erster Linie die Presse - über vergleichsweise spektakuläre Ermittlungsverfahren gegen Personen des öffentlichen Lebens zu informieren. Wie gesagt, es gibt durchaus Diskussionspotential, und insofern habe ich den Beitrag auch mit Interesse zu lesen begonnen.

Dieses Interesse hat sich aber sehr schnell gelegt, ja in Verärgerung verwandelt. Wie gesagt, zu der Sache stehen kann man, wie man will; man sollte aber doch, wenn man über sie schreiben will, sich zumindest informieren oder wenigstens den Gedanken, den man zu Papier bringt, zu Ende denken - zumal dann, wenn man für ein Blatt wie die FAZ schreibt. Ich kann mich des Gedankens allerdings nicht erwehren, daß der Autor das nicht getan hat. Denn er bleibt nicht bei der Frage nach der Pressearbeit der Justiz und dem Umgang der Medien mit dem Thema stehen, sondern geht noch einen Schritt weiter und kritisiert, daß sich die Strafjustiz überhaupt mit solchen Themen beschäftigt:

In der ARD-Sendung „Brisant“ vom 14. April erklärte der Staatsanwalt Ger Neuber: „Wir haben festgestellt, dass die junge Frau, die selbst HIV-positiv ist, ungeschützten Geschlechtsverkehr mit mindestens drei Personen hatte.“

Aha. Wer ist wir? Die einzige Art, den Ablauf einer sexuellen Handlung festzustellen, ist, dabei zu sein. Fand das, wie die Ziehung der Lottozahlen, unter notarieller Aufsicht statt?

"”Der Staatsanwalt in meinem Bett”" vollständig lesen

Heute abend wurde ich einem künftigen Mitbewohner vorgestellt, den ich - in vermutlich typisch männlicher Ignoranz - bereits als Blume oder Pflanze vergleichbarer Art und damit als Teil der anstehenden Begrünungsaktion des Balkons fehlidentifiziert hatte. Er heißt allerdings "Tomaccio" und wird am Ende hoffentlich eßbar sein …

Dann auf gutes Gedeihen, und ich gehe jetzt erst einmal in die Ecke, mich schämen, und nehme vielleicht ein Buch "Pflanzenbestimmung für Anfänger - wie wir Bäume von Sträuchern unterscheiden" mit.

Die Titelzeile faßt es eigentlich schon zusammen: seit dem Upgrade meiner Mailman-Installation auf die aktuelle Version 2.1.12 mag das praktische Perlscript listadmin.pl, über das ich bereits berichtet hatte, seinen so hilfreichen Dienst nicht mehr versehen (auch nicht nach Update auf die aktuellste Version 2.40, die wohl aus dem Jahr 2007 datiert), offenbar deshalb, weil der Parser über geänderte Webseiten (geänderte Mailman-Templates) stolpert.

Solange keine administrativen Aufgaben zu erfüllen sind, läuft es problemlos durch (so soll es sein); wenn man es auf nicht mehr existente Listen losläßt, beschwert es sich und läßt die Liste aus (auch das ist vernünftig und akzeptabel):

ERROR: unexpected contents, please send /tmp/dump-0.144370685638027-list@domain.example.html to $address — skipping list

Wenn es aber etwas zu tun hätte, weil sich Anfragen in der Moderations-Queue befinden, dann bricht es leider einfach zusammen:

fetching data for list@domain.example … Died at ./listadmin.pl line 802.

Grund ist offensichtlich ein Stolpern des Parsers:

sub parse_subscription {
    my ($mmver, $config, $parse, $data) = @_;

    $parse->get_tag ("td") || die;
    my $address = $parse->get_trimmed_text ("/td") || die;
    my $tag = $parse->get_tag ("input") || die;
    my $id = $tag->[1]{"name"};
    $parse->get_tag ("/table") || die;
$parse->get_tag ("/tr") || die;
    $data->{$id} = { "subscription" => $address };
}

In der hervorgehobenen Zeile verlassen sie ihn. Offenbar sucht listadmin.pl erst nach zu genehmigenden oder abzulehnenden Beitrittsersuchen, bevor es die weiter unten auf der Seite folgenden zu moderierenden Beiträge abarbeitet, und erkennt letztere fehlerhaft als erstere, weshalb es die falsche Routine zum Parsen derselben aufruft, die dann aus dem Tritt gerät.

Allerdings ist mir der Parser auf Anhieb erstmal etwas zu hoch, daher meine Frage: Gibt es vielleicht schon eine aktuellere Version des Scripts? Oder hat sich schon jemand damit beschäftigt und einen Patch in der Hinterhand? Falls ja: Bitte melde Dich!

Nachdem ich in den letzten Tagen einige Maschinen - heimische und Mietserver, letztere mit und ohne serielle Konsole - von Debian Etch auf Lenny hochgezogen haben, sind mir dabei einige Gemeinsamkeiten aufgefallen. Zunächst vielleicht das wichtigste: die in den Release Notes angesprochenen Probleme mit neu nummerierten Devices oder gar Problemen beim Auffinden des Root-Filesystems beim Reboot (Device enumeration reordering, System boot hangs on Waiting for root file system) sind bei mir glücklicherweise in keinem Fall aufgetreten; das verlief vielmehr alles durchaus problemlos, sei es mit LILO als Bootloader (ggf. an Verkleinerung der RAM-Disk denken, Prepare initramfs for LILO!) oder mit grub. Das hat mich besonders erleichtert, weil, wie gesagt, nicht alle entfernten Maschinen über eine serielle Konsole und damit über die Möglichkeit eines einfachen Zugriffs bei Bootproblemen verfügen.

Auch ansonsten verliefen die Upgrades an und für sich - bei der in den Release Notes empfohlenen Vorgehensweise - erfreulich unproblematisch. Das gehört auch zu den Dingen, die ich an Debian besonders schätze: der Upgrade-Prozeß ist in der Regel schmerzlos, gut dokumentiert und getestet. Hilfreich insbesondere, wenn man sich in den eher zentralen und maschinennahen Bereichen nicht so besonders auskennt und/oder keinen unmittelbaren Zugriff auf das System hat.

Schon allein ein Blick auf Munin zeigt aber einige Veränderungen, die sich aus den in den Beitrag eingestreuten Graphiken ergeben. Dass der Platzverbrauch im Rootverzeichnis - genauer wohl in /libs - gestiegen ist, hatte ich schon vorgestern nach dem Update der ersten Maschine berichtet. Das ist aber natürlich nicht die einzige Veränderung - es gibt auch positives zu berichten. So hatte ich zuerst den Eindruck gewonnen, daß die Speicherauslastung zurückgegangen ist, nicht nur, soweit sich die Buffer nach dem Reboot erst einmal wieder füllen müssen, sondern auch, soweit der von Applikationen in Anspruch genommene Speicher betroffen ist. Das scheint mir aber ein Irrtum gewesen zu sein; mit der Zeit steuert die Auslastung wieder dem bisherigen Wert zu. Was sich aber definitiv direkt um Größenordnungen erhöht und insoweit verbessert hat, ist die zur Verfügung stehende Entropie, wichtig für die Erzeugung von Zufallswerten, insbesondere auch im Zusammenhang mit der Verschlüsselung. Auf den meisten Maschinen ist die Erhöhung eine generelle, auf einer Maschine ist sie zumindest eine temporäre. Zumindest auf einer Maschine hat sich auch die Anzahl der MySQL-Queries spürbar verringert; das erscheint mir aber eher zufällig zu sein (oder steckt vielleicht irgendwo im neuen INN drin - denn der dürfte auf dieser Maschine für die SQL-Queries in erster Linie verantwortlich sein).

"Debian Lenny: erste Erfahrungen" vollständig lesen

Im Zusammenhang mit dem Update einer Maschine auf Debian Lenny bin ich auf das seltsame Phänomen einer - offensichtlich von PHP erzeugten - Fehlermedlung gestoßen: der Aufruf einer bestimmten Webseite (respektive des PHP-Scripts, das diese erzeugen sollte) ergibt nur die Meldung "No input file specified!". Google führt einen zu diversen Threads, die sich vor allem um die Konfiguration des richtigen Handlers für die Interpretation von PHP-Scripts und um hilflose Fragen von Benutzern, die eigentlich nur ein fertiges Paket installieren wollten und nun nicht mehr weiter wissen, drehen. Erst ein alter Blogeintrag in ixs’ Vodkamelone (nein, das hat nichts mit einem Kamel Nr. Eins zu tun!) von 2005 half mir auf die Sprünge.

Der Grund dieser Fehlermeldung ist offenbar ein ganz seltsames Zusammenspiel der Ausführung von PHP als mod_suphp, d.h. der CGI-Version von PHP in der Weise, daß Scripts unter den Rechten des jeweiligen Benutzers ausgeführt werden, mit der Vergabe von Datei- und Verzeichnisrechten. Die oben genannten Fehlermeldung tritt demnach genau dann auf, wenn zwar der Webserver auf die Datei bzw. ihr Verzeichnis zugreifen, sie also "finden" kann, der Benutzer selbst aber nicht. Dann findet der Webserver - unter der UID www-data - das Script, erkennt es, ruft den Handler auf, der als suid root installiert ist, sich Root-Rechte verschafft, damit auf die UID des Benutzers wechselt und dann mit diesen Rechten den PHP-Interpreter aufruft, um ihn das Script ausführen zu lassen. Dieser PHP-Prozess, der jetzt aber im Kontext des Benutzers läuft, kann dann selbst auf das entsprechende Verzeichnis nicht mehr zugreifen, das Script also auch nicht ausführen, und reagiert dann mit der obigen Fehlermeldung, denn er findet ja keine Datei, die er ausführen könnte.

Vielleicht hilfts ja jemanden, wenn ich ixs’ Analyse her noch einmal wiedergebe und verlinke.

Beim Upgrade eines Systems, auf dem ein Munin-Client läuft, von Debian Etch auf Debian Lenny sind ggf. einige Handgriffe nötig, damit Munin weiterhin ordnungsgemäß funktioniert.

Zum einen muß ggf. für die Apache-Statistiken der Konfigurationseintrag für mod\_status (wieder) ergänzt werden, weil er von der apache2.conf in die Modulkonfiguration in mods-available/status.conf umgezogen ist. "Allow from localhost 127.0.0.1" sollte sich dort finden, und ggf. "ExtendedStatus On".

Problematischer ist das Update von BIND auf Version 9.5.1; im Debian-Paket gibt es zwar ohnehin kein Plugin für den Nameserver, aber wer bisher das bind\_-Plugin von MuninExchange verwendet hat, stößt auf das Problem, das dieses nicht mit BIND 9.5.x kompatibel ist. Der Grund dafür liegt in dem unterschiedlichen Format der von BIND erzeugten Statistikdatei. Die neue Version ist da viel ausführlicher, hat aber eben auch ein ganz anderes Format.

Daher habe ich das Plugin quick’n’dirty auf das neue Format umgeschrieben. Ob es überhaupt noch möglich ist, die Statistiken nur für bestimmte Domains zu sammeln, wie es das bind\_-Plugin anbietet, weiß ich nicht; dieses Feature habe ich nicht benutzt. Jedenfalls kann man mit dem "neuen" Plugin nahtlos an die alten Munin-Graphiken anschließen; daher sammelt es auch nur (genau) die Daten, die auch das alte Plugin angeboten hat, auch wenn das neue Statistik-Format ggf. weitergehende Informationen bereit hält (mit einer Ausnahme: die Referrals scheinen nicht mehr geloggt zu werden). Meine Lösung ist nicht von der Perfektion weit entfernt, schon deshalb, weil sie teilweise Werte etwas willkürlich auf die alten Kategorien mappt (bspw. bei "failures"), aber es tut, und wie meine Graphen zeigen, sind die Werte von der Größenordnung her vergleichbar mit den früher erfassten. Dass BIND 9.5.x die Statistikdatei im übrigen nicht - wie offensichtlich früher der Fall - überschreibt, sondern die neuen Werte jeweils anhängt, stört gleichfalls nicht, weil das Plugin immer nur den letzten Match auswertet.

Wenn jemand Interesse daran hat - oder sich um eine Verbesserung kümmern möchte, für die mir momentan die Zeit fehlt, kann er sich das Plugin bind95 gerne herunterladen; Kommentare sind willkommen.

Wer seine bisherigen Munin-Graphen nahtlos weiterführen will, muß dafür sorgen, daß der symbolische Link - oder die Datei - in /etc/munin/plugins/ denselben Namen ("bind\_") wie bisher trägt, oder die Datensammlungen in /var/lib/munin/$DOMAIN/ entsprechend umbennen, d.h. von /var/lib/munin/$DOMAIN/$HOST-bind\_-\*.rrd nach /var/lib/munin/$DOMAIN/$HOST-bind95-\*.rrd. Und, wie immer: ein Backup schadet nicht …

Da war es doch die ganzen letzten Tage, seit dem Osterwochenende, ach was, schon seit den letzten Tagen davor, angenehm warm und schön sonnig, und kaum ist man wieder nach Hause zurückgekehrt, bemüht das Wetter sich direkt, möglichst unangenehm zu werden. Vor dem Rechner sitzend hatte ich zunächst die aufziehende Dunkelheit primär mit der fortgeschrittenen Tageszeit assoziiert, aber nein, es zieht tatsächlich ein richtiger Wolkenbruch auf! Brrrr! Hoffentlich bleibt das jetzt nicht so …

Das Upgrade meines heimischen Servers von Debian Etch auf Debian Lenny hat im großen und ganzen gut funktioniert; neben dem unvermeidlichen Abgleich geänderter Konfigurationsdateien ("nehme ich die neuen Defaults und Kommentare in meine bestehende Datei, oder übernehme ich die Datei und ziehe die lokalen Änderungen nach?") ergaben sich nur einige Kleinigkeiten (der selbst kompilierte Exim wollte nach Entfernen einiger "obsolote" Libraries neu kompiliert werden; locate war plötzlich verschwunden; die Apache-Konfiguration muß angepaßt werden), wenn man einmal davon absieht, daß /lib offenbar deutlich gewachsen ist, so daß es sich nun rächt, daß ich damals beim Partitionieren mit dem Platz für / etwas arg sparsam war. Daran wird sich allerdings, so fürchte ich, ohne weiteres nichts tun lassen.

Darüber hinaus stellte sich - ebenfalls Munin sei Dank - bei genauerer Betrachtung aber auch heraus, daß sich die Systemauslastung spürbar erhöht hatte. Außerdem war die Anzahl der Timer-Interrupts geradezu explodiert. Nun, es hätte ja sein können, daß das einfach eine Folge des Upgrades ist - andere Software, mehr Software, wer weiß? Eine nähere Untersuchung der Angelegenheit ergab dann aber, daß der mutmaßliche Verursacher mit hoher Prozessorauslastung in top der Task upsd war, der für die Ansteuerung der USV sorgt (wobei Ansteuerung wohl etwas übertrieben ist; im wesentlichen soll er eine Handvoll Signale auswerten und loggen, bspw. "zu heiß", "zu kalt", "Batterie wird alt", "Störung" oder eben vor allem "Netzausfall" und "Batterieladung niedrig", und im letzteren Fall das System herunterfahren, was er in jüngerer Vergangenheit auch schon einmal erfolgreich getan hat).

upsd gehört zum Belkin Sentry Bulldog, einer vom Hersteller der USV ausgelieferten Software, die daneben auch noch den Netzwerkbetrieb erlaubt, insbesondere die Abfrage des Daemons über das Netz von einem entfernten Client aus und theoretisch auch eine Weboberfläche, die allerdings bestenfalls minimalistisch gehalten ist. Ich hatte damals bei Installation der USV mit einigem Aufwand eine alte Linux-Version für Redhat installiert und angepaßt, so daß sie lauffähig war, die ihren Dienst bis heute problemlos versehen hat. Ganz offensichtlich kann sie sich aber an die neuen Zeiten nicht so recht gewöhnen; also ist Abhilfe geboten, denn mit einer solch unnötig hohen Last wollte ich das System dann doch nicht auf Dauer laufen lassen.

Eine aktuelle Version des Herstellers war nicht in Sicht, aber wie man schon an den eingestellten Graphiken sieht, habe ich eine andere Lösung gefunden, und die heißt nut.

"Debian Lenny und Belkin Sentry Bulldog" vollständig lesen

root@xerxes:~# cat /etc/debian_version
5.0.1

One done, (at least) four to go.

Die sog. "History" ist beim INN die zentrale Tabelle, die Message-IDs (also die eindeutige Kennung jedes Newspostings) mit ihrem Speicherort verbindet, so daß man ein über eine Message-ID referenziertes Posting auch im Speicher-Backend wiederfinden kann; zugleich wird vor der Annahme von Postings über die History geprüft, dass das entsprechende Posting noch nicht vorhanden ist. Es sammeln sich also große Datenmengen an, auf die zudem ständig zugegriffen werden muß; ein effizientes Handling derselben ist daher Pflicht. INN unterstützt deshalb zur Verkürzung von Zugriffszeiten einen Cache für die History, der die letzten Zugriffe zwischenspeichert.

Seit Jahren betreibe ich meinen Newsserver, seit Jahren stolpere ich in den täglichen Reports des Servers darüber, daß mein Cache offenbar nicht (richtig) funktioniert, und seit Jahren plane ich, daß "bei Gelegenheit" einmal zu überprüfen. Allerdings kommt so eine "Gelegenheit" normalerweise spät oder nie …

Dieser Tage bin ich dann tatsächlich einmal dazu gekommen, das anzugehen und mich zu erkundigen, wo für das schlechte Abschneiden des Caches wohl die Ursachel liegen könne. Diese Werte erscheinen schließlich wirklich nicht berauschend:

History cache:
Reason                      Count     %Count
Cache misses               190461      66.9%
Do not exist                94182      33.1%
Positive hits                   0       0.0%
Negative hits                   0       0.0%

Entscheidend für das (Nicht-)Funktionieren des Caches ist, wie ich dann erfuhr, dessen Größe, die durch den Parameter hiscachesize in der inn.conf gesteuert wird. Empfohlen wurde, ihn auf mindestens 1 kB zu setzen, ggf. auch höher; bei mir stand er, wie ich dann sah, auf 0 … was einiges erklären dürfte.

Nach Erhöhung der Cachegröße auf 5 kB sieht die Sache jetzt doch deutlich besser aus:

Reason                 Count     %Count
Positive hits         183728      65.9%
Negative hits          59022      21.2%
Do not exist           35762      12.8%
Cache misses              81       0.0%

Kleine Ursache, große Wirkung, man kennt das ja.

Vor dem Weg ins Osterwochenende stand uns noch einmal ein Besuch beim schwedischen Möbelelch zwecks Komplettierung des Balkonmöbelbestandes bevor, der sich allerdings erfreulich schnell erledigen ließ (trotz eigenwilliger Suche des Rückwegs - aber wüßten wir sonst jetzt, wo in Sindelfingen die Feuerwehr ist?). Interessant fand ich die - nach Google-Recherche nicht mehr wirklich neuen, aber mir bisher noch nie begegneten - Expresskassen, an denen die Kunden selbst die Ware scannen und bezahlen können, ohne daß dafür Personal erforderlich ist.

Zunächst schreckten wir vor dieser neuen Erfahrung eher zurück und standen in einer der langen Schlangen vor einer der verbliebenen "konventionellen" Kassen, ließen uns dann aber überzeugen, an eine dieser Selbstverbucherkassen zu wechseln, die aus je einem "umzäunten" Bereich mit jeweils vier Scan- und Zahlterminals bestehen. An diesen Terminals kann - und muß - man dann die Waren selbst scannen; wenn man fertig ist, wählt man die Zahlweis aus, zieht ggf. die IKEA-Familiy-Karte durch einen Magnetstreifenleser und wählt dann die Zahlungsweise aus. Eine EC-Karte kann man in das neben der Scanstation befindliche Electronic-Cash-Terminal stecken, dann auf einem Touchscreen seine Unterschrift leisten - diese beleglose Art der Unterschriftsleistung ist auch an den bedienten Kassen eingeführt -, bestätigen, bekommt seinen Beleg und ist fertig. Das ganze geschieht unter den wachsamen (oder hilfreichen?) Augen eines Mitarbeiters, der alle vier Stationen "überwacht" und den mit der neuen Technik noch nicht so vertrauten Kunden ggf. hilfreich zur Seite steht (und vermutlich auch ein Auge darauf hat, daß auch wirklich alle Teile gescannt werden).

Eine ganz nette Sache, vor allem, weil man nur von seiner eigenen Arbeitsgeschwindigkeit abhängig ist und an den Platz von bisher ~ zwei Kassen eine Viererstation paßt; außerdem macht das Scannen Spaß (wenn man denn einmal verstanden hat, daß der richtige Abstand entscheidend ist, aber dafür hatte ich ja einen Scan-Profi dabei ). Wirklich schneller als an der Kasse kann es allerdings kaum gehen, denn die wenigstens Kunden dürften mit dem Scannen so schnell sein wie die Mitarbeiter. Außerdem besteht m.E. doch eine erhebliche Gefahr von Verlusten für IKEA, noch nicht einmal durch Böswilligkeit und kriminelle Energie, sondern schlicht durch Verwirrung der Kunden, die in einem vollen Wagen schnell mal einzelne Teile übersehen können; zudem haben die einzelnen Waren in einem Möbelhaus im Durchschnitt doch eher einen höheren Wert als im Supermarkt, was die Verluste weiter erhöht. Ob das die Personaleinsparung ausgleichen kann? Wer weiß.

Jedenfalls kann ich nunmehr beruhigt vermerken, daß die neue Technik gut funktioniert und einfach zu bedienen ist - und sie hat uns vielleicht Diskussionen wegen der unverpackten Sitzkissen erspart (verpackte gab’s nicht mehr, und eine Nachlieferung war erst für die kommende Woche angekündigt …).