Kategorie: Lust und Frust

16.September 2014

Shit happens

Einen etwas in die Jahre gekommenen invis-Server auf aktuellen Stand zu bringen ist eigentlich kein Hexenwerk.

Im Idealfall sichern Sie das “/etc” Verzeichnis, sämtliche Datenbanken und machen einen Snapshot des LDAP-Verzeichnisses. Ist der Server auf einem Software-RAID 1 aufgesetzt trennt man den Verbund auf und legt eine der beiden Festplatten erst mal auf die Seite.

Die verbleibende Festplatte ist mit den Smartmontools auf ihren Gesundheitszustand zu testen. Ist alles OK kann die Neuinstallation einer aktuellen openSUSE beginnen. Dabei wird die bestehende Partitionierung beibehalten und die Logical-Volumes “srv” und “home” ohne Formatierung aus der vorherigen Installation übernommen.

Danach “sine” durchlaufen lassen, ein paar Konfigurationen wie SMTP-Relayhost und die DDNS-Keys aus der alten Installation übernehmen. Etwas knifflig ist die Übernahme der bestehenden Benutzerkonten und DHCP/DNS Objekte aus dem alten LDAP-Verzeichnis ins Neue, sowie die Anpassung der Samba-Domain-SID. …aber auch das ist keine große Kunst.

So geschehen jüngst in Bochum. Nach getaner Arbeit ein gutes türkisches Essen im “Side” und ab ins Bett.

Der nächste Morgen beim Kunden begann mit einem “Ah Herr Schäfer, gut dass Sie kommen, es funktioniert gar nichts mehr.” Diesen Moment sollte jeder Admin in seinem Leben mindestens ein Mal erlebt haben.

Fehlersuche. Hmm, der Server läuft (scheinbar) normal, trotzdem erhalten die Clients keine IP vom DHCP-Dienst. Dienst neu gestartet, Kabel, geprüft, Switch zurück gesetzt, kein Erfolg. Na, dann “reboot tut gut”. Beim Neustart blieb der Server aufgrund schwerwiegender Dateisystemfehler im var-Volume hängen. Erste Schweissperlen auf der Stirn…

Es zeigte sich, dass ein Kurztest (smartctl -t short /dev/sda) und nachfolgende Überprüfung des Ergebnisses einfach keinen Surface-Scan ersetzen. Für letzteren ist nur meistens keine Zeit.

Wie weiter? Neuer Versuch mit der verbleibenden Platte der alten Installation? Kommt nicht in Frage, der doppelte Boden wird nicht aufgegeben. Der Weg zurück darf erst abgebrochen werden, wenn alles funktioniert!

Der Ansatz: Etappenweises Klonen bzw. Kopieren der einzelenen Volumes bzw. Verzeichnisstrukturen auf eine intakte Platte. Dabei habe ich die Partitionierung manuell vorgenommen, die RAID-Verbünde mit der “missing” Option erstellt und eine Volume-Group unter anderem Namen auf der neuen Platte angelegt. Das hat mit “ddrescue” und der letzen aktuellen Datensicherung alles in allem gut funktioniert. Allein die Installation des Bootmanagers Grub2 wollte nicht gelingen. Nach ein wenig Bastelei, fand Stage-1 auch seinen Platz im MBR der Platte, doch beim Start des Systems wurde die Volume-Group des
Root-Dateisystems nicht gefunden. Stimmt, ihr Name lautete ja jetzt “system2″ statt “system”, also kurzerhand mit Hilfe des openSUSE Rettungssystems umbenannt Reboot und Feierabend… Murphy lässt grüßen, “Volumegroup system nicht gefunden”. ;-(

OK, openSUSE arbeitet mit UUIDs zur Kennzeichnung von Datenträgern, die können ja nicht stimmen, ergo müssen die “grub.cfg”, sowie am besten auch gleich die “initrd” neu angelegt werden. Dazu wieder das Rettungssystem gestartet. Alle wichtigen Volumes zu einer chroot-Umgebung zusammen gebaut und dann noch “/proc”, “/dev” und “/sys” aus der
Rettungsumgebung in die chroot-Umgebung eingehängt, “grub2-mkconfig -o /boot/grub2/grub.cfg” ausgeführt und festgestellt, dass es wohl ein langer Tag wird.

Um es hier kurz zu machen: Das geht nicht mit dem openSUSE Rettungssystem, da darin wichtige Einträge in “/dev” mit Symlinks nach “/mounts” zeigen und genau das lässt sich nicht in die chroot-Umgebung übernehmen. Symbolische Links die aus der chroot-Umgebung führen, sind innerhalb derselben schlicht “broken”. Es resultiert darin, dass “/dev/mapper/console” fehlt. Sackgasse, zumindest, wenn man morgens um 4:00 Uhr von Stechmücken geweckt wurde und völlig übermüdet ist.

Mein Fehler war natürlich, dass ich “laaange” versucht habe das Problem zu beheben. Alle mit Google auffindbaren Beschreibungen, lieferten genau die Schritte zu Tage, die ich bereits versucht hatte. Es war die reine Verzweiflung (und Ines, die mir am Telefon mit Nachdruck Hilfe anbot), die mich dazu trieb statt des Rettungssystems eine openSUSE Live Umgebung zu verwenden. Genau das führte zum Erfolg, die Live-Systeme kommen beim Aufbau im Unterschied zum Rettungssystem ohne Links nach “/mounts” aus und die Sache funktioniert.

Eine Begründung für diesen nervenaufreibenden Unterschied hätte ich schon gerne.

Stefan

Ein Tag mit Vodafone. Beginnen wir mit besagtem Begleitschreiben:

Sehr geehrte Damen und Herren,

der Umzug findet trotz unterschiedlicher Adressen innerhalb eines Gebäudekomplexes statt. Sowohl die alten, als auch die neuen Räumlichkeiten werden am gleichen Hauptanschluss der Deutschen Telekom betrieben. Vom Hauptanschluss sind bereits Kabel in die neuen Räume verlegt. Es wird vor Ort lediglich ein Techniker der Telekom benötigt, der den Hauptanschlusskasten öffnet, die alten Leitungen ab- und die neuen Leitungen anklemmt. Eine Umschaltung in der Vermittlungsstelle ist nicht notwendig.

Wir bitten dringend um eine vorherige Terminabsprache mit unserem IT-Techniker Herrn Stefan Schäfer (0175/1xxxxxx).

Hintergrund des Schreibens ist der Umzug eines Büros mit zwei ISDN-Anschlüssen innerhalb eines Gebäudes. Haken an der Sache ist, dass sowohl der bisherige, als auch der neue Anschluss, trotz unterschiedlicher Adressen an einem Punkt im selben Gebäudekomplex zusammen laufen. Dieser gemeinsame Punkt ist ein Sammelanschlusskasten der Deutschen Telekom, noch dazu abgeschlossen. Inhaber des Büros und in diesem Fall unglücklicherweise Kunde der Vodafone GmbH, ist ein kleiner Bio-Supermarkt mit immerhin 32 Mitarbeitern. Der Markt ist extrem von Telefon, Fax und Internetzugang abhängig. Ohne Internetzugang, Telefon und Fax ist keine Kartenzahlung mehr möglich, das Bestellwesen kommt zum erliegen und selbst die Erfassung des Stromverbrauchs durch die örtlichen Stadtwerke ist nicht mehr möglich.

In Eigenleistung wurde vorbereitend ein Kabel vom neuen Büro zum Anschlusskasten gelegt, das alte Büro soll nach dem Umzug zu einem Bistro ohne Telefonanschluss umgebaut werden. D.h. einzig notwendig war die Anwesenheit eines Technikers der Telekom, der besagten Kasten aufschließt und insgesamt 4 Drähte ab, sowie 4 neue Drähte anklemmt. Eine Sache von etwa 5 Minuten Arbeitszeit.

Probleme ahnend, haben wir zunächst versucht die Sache ohne Einschaltung der Vodafone GmbH zu lösen und haben uns direkt an die Telekom gewendet. Leider ohne Erfolg, die Beauftragung eines Technikers kann nur durch Vodafone erfolgen. Ergo Kontaktaufnahme zu Vodafone. In einem ersten Gespräch wurde mir versichert, dass es sich beim gewünschten Vorgang um einen Umzug handelt. Meine Einsprüche dagegen wurden mit Hinweis auf interne Verfahrensweisen abgewiesen. Uns wurden Umzugsanträge zu gesendet. Diese wurden ausgefüllt und beide am oberen Rand mit dem Vermerk „Bitte Begleitschreiben beachten“ versehen an Vodafone gesendet.

Es wurde insofern beachtet, als das sich die Vodafone tatsächlich wenige Tage später zwecks Terminabsprache bei mir gemeldet hat. Vereinbart wurde Montag der 8.9.2014 zwischen 8:00 und 13:00 Uhr.

An besagtem Montag habe ich gegen 8:00 Uhr begonnen den Umzug der TK-Anlage ins neue Büro vorzubereiten. Ca. 15 Minuten später erschien der Inhaber des Supermarktes bei mir und sagte, dass soeben die „grünen Leuchtdioden“ an beiden NTBAs erloschen seien und seither weder Telefon noch Internetzugang funktionieren.

„Wie, abgeschaltet?“ „Ja, abgeschaltet!“

Kontaktaufnahme Vodafone:

Ich beschrieb den Vorgang, zugegeben nicht ganz frei von Emotionen (habe mich aber bei der netten Dame der Business Hotline entschuldigt). Sie entgegnete, dass das ja kein Umzug sei, sondern lediglich eine hausinterne Umverdrahtung.

„Ach was?“

Ich teilte Ihr mit, dass das genau das war, was ich Ihren Kollegen bei der Beauftragung erläutern wollte, man mir aber versicherte, dass dies einen Umzug darstelle. Darauf hin das Begleitschreiben. Ich erwähnte es gegenüber der netten Dame. Sie entgegnete, dass das dann wohl übersehen worden wäre.

„Ach was?“

Sie bestätigte allerdings den Erhalt des Schreibens, wie auch die Erwähnung desselben am oberen Rand der Umzugsaufträge. Die Frage, ob die Abschaltung denn rückgängig zu machen sei, wurde verneint. Die nette Dame verwies darauf, dass ja der Techniker zwischen 8:00 und 13:00 Uhr erscheinen würde. Er kann die wieder Zuschaltung initiieren. Wir mussten das akzeptieren.

Da mit der Abschaltung bereits der GAU eingetreten war, der verhindert werden sollte, habe ich mich mit dem Umzug der TK-Anlage sowie des lokalen Servers an den neuen Standort beschäftigt und so gut es ging alles für den erwarteten Telekom-Techniker vorbereitet.

13:00Uhr, kein Techniker erschienen, erneute Kontaktaufnahme mit Vodafone.

Diesmal ein jüngerer Herr am anderen Ende der Leitung. Jaaaa, der Techniker Termin wurde abgesagt.

 „Was????“

Er könne mir allerdings einen Alternativ-Termin am 18.09.2014 anbieten.

„Was????“

10 Tage ohne Telefon und Internetzugang? Aus dem GAU wurde ein Super-GAU.

„Das geht nicht, wir brauchen die Wiedereinschaltung umgehend und noch heute einen Techniker der Telekom.“

Er versucht es zu klären und versprach zurückzurufen.

Das wenigstens funktioniert bei der Business-Hotline der Vodafone, Sie rufen zurück. Leider ohne Ergebnis. Es bleibt dabei, frühest möglicher Termin in 10 Tagen. Wir können uns ja im Vodafone-Shop einen Surfstick besorgen und eine Rufumleitung auf ein Handy erwirken. Vodafone übernimmt dafür gerne die Kosten. Mehr zu erreichen wäre Ihm nicht möglich. An diesem Punkt habe ich das Gespräch an den Anschlussinhaber weiter gegeben. Resultat: Fassungslosigkeit, Wut, Verzweiflung und Gesprächsabbruch.

Ab diesem Zeitpunkt versuchten wir zweigleisig zu fahren. Einerseits der Vodafone-Shop, andererseits ein „mit Beziehungen gestützter“ Direktkontakt zur Telekom.

Im Shop konnten wir lediglich den versprochenen Surfstick, sowie ein Prepaid-Handy für die Rufumleitung organisieren. Beides natürlich „zunächst“ auf Rechnung des Kunden.

Der Kontakt zur Telekom lieferte nach einigen hausinternen Recherchen zu Tage, dass es vermutlich seitens Vodafone nicht einmal einen Versuch gegeben hat, einen Techniker der Telekom zu beauftragen. Man teilte uns mit, dass Vodafone das aber jederzeit, auch sehr kurzfristig tun könne. Von 1,5 Stunden war die Rede. Kosten für die Beauftragung belaufen sich pauschal auf 250,-€.

Rückfrage bei Vodafone: Nein das ist uns nicht möglich, genauso wenig wie das Rückgängig machen der Abschaltung. Genau genommen wurde gar nicht abgeschaltet, sondern, wie wir inzwischen in Erfahrung bringen konnten, lediglich der Anschluss auf einen anderen Port des selben Hauptanschlusskastens umgeschaltet. Jeder Versuch Kontakt zu einem Verantwortlichen bei Vodafone aufzunehmen, wurde rabiat am Prellbock „Business-Hotline“ gestoppt.

Status: Internetzugang via Prepaid-Surfstick, hierüber wird sogar die EC-Kartenzahlung im Supermarkt abgewickelt und anstatt luxuriöser Telefonanlage mit Ansage-System nur ein einzelnes Prepaid-Handy für alles. Fax ist derzeit nicht möglich, genauso wenig wie das Ablesen der Stromzählerstände durch die lokalen Stadtwerke. Ausgang der Geschichte ist ungewiss.

Bleibt als Fazit lediglich, dass man sich als Business-Kunde in Sachen TK-Anbieter möglichst das kleinste Übel auswählen sollte.

Die ganze Sache inklusive der Gespräche ist hier natürlich verkürzt, aber so wahrheitsgetreu wie es meine Erinnerung zulässt wiedergegeben.

Nach etwa 50 Commits in unser Github-Repository und nur geringfügig weniger Builds im openSUSE Buildservice, haben wir den Grundstein für einen Active Directory basierten invis-Server gelegt.

Noch haben wir zwar keine Hand an die entsprechenden Anpassungen des invis-Portals gelegt, es steht jetzt allerdings ein invis-Server Setup-RPM zur Verfügung, mit dem bereits ein Samba4 basiertes Active Directory realisiert werden kann,  inklusive einiger Schema-Erweiterungen im Active Directory. Diese werden es ermöglichen das AD-Verzeichnis beinahe auf die gleiche Weise zu nutzen, wie zuvor OpenLDAP.

Besonders stolz sind wir darauf, dass es uns gelungen ist den ISC-DHCP-Server so zu patchen, dass auch er seine Informationen aus dem AD beziehen kann.

Noch ist es ein langer Weg, bis ein AD-basierter invis-Server auf dem Stand der klassischen Installation ist, wir sind jedoch guter Dinge auch die noch anstehenden Probleme zu lösen. Hilfe ist dabei jedoch jederzeit willkommen. Der aktuelle Stand der Dinge kan im invis Wiki nachgelesen werden.

Stefan

Vor kurzem habe ich hier im invis-Blog einen Artikel zum Thema “Wie viele CPU-Kerne spende ich einer virtuellen Maschine?” veröffentlicht.

In der ersten Veröffentlichung wurde lediglich mit einem System auf Basis einer (wenn auch kleinen) Intel Hyperthreading CPU getestet. Inzwischen hatte ich die Zeit die gleichen Benchmarks mit einem Sytem durchzuführen, welches über 8 physische CPU-Kerne verfügt.

Das daraus resultierende, gänzlich andere Verhalten, möchte ich natürlich niemandem vorenthalten. Hier die Auswertung als PDF-Datei.

Ich hoffe es ist nützlich.

Stefan

Wir haben das Wiki zum invis-Server um die Rubrik “invis-Server Client Integration” erweitert. Darin werden unterschiedliche Wege der Client-Anbindung an einen invis-Server beschrieben. Neben einer Anleitung für einen Windows 7 Domänenbeitritt, die sich schon seit einer ganze Weile im Wiki befindet, haben wir aus aktuellem Anlass die Anbindung von Ubuntu Clients beschrieben.

Ausganspunkt war eine reale Umgebung in der ein invis-Server in eine reine Ubuntu-Umgebung integriert wurde. Dabei ging es nicht nur um lokale Clients, sondern auch um eine möglichst nahtlose Integration von Clients via OpenVPN. Nebenbei haben sich daraus einige Verbesserungen und Erweiterungen am invis-Setup ergeben, die bereits in unser RPM-Paket eingeflossen sind.

Die Integration von openSUSE-Clients verläuft sicherlich etwas glatter, es hat sich in der Praxis jedoch gezeigt, dass ein invis-Server auch abseits von openSUSE oder Windows, eine gut funktionierende Ergänzug einer IT-Landschaft ist.

Aus der “Zielgruppe für die Zielgruppe” ist ein Motto des invis-Server Projektes, welches hier sehr schön umgesetzt werden konnte. Die Situation beim Anwender erforderte einige Erweiterungen und Anpassungen, diese wurden unmittelbar ins Setup-Paket integriert und im Wiki dokumentiert.

Stefan

Ich durfte gerade feststellen, dass es pro IP Adresse lediglich möglich ist 3 Microsoft Konten pro Tag einzurichten. Muss man für einen Kunden 27 mal Microsoft Office 2013 (keine Volumen Lizenz und jeder ein eigenes MS Konto) installieren, bedeutet das, dass sich die Installation auf 9 Tage verteilt.

So lange wie das pro Installation dauert, sind drei Installationen pro Tag eine durchaus realistische Schätzung….

Wer Sarkasmus findet, darf ihn behalten. ;-)

Stefan

Vor wenigen Tagen flatterten uns, an drei unserer Kunden (Kunden meiner Firma FSP Computer & Netzwerke) gerichtete, Abuse Schreiben der Deutschen Telekom ins Haus. Alle Schreiben waren, sieht man von leicht differierenden Zeitangaben ab, absolut identisch.

Mit deutlichen Worten wird dort die mißbräuchliche Nutzung eines DSL-Anschlusses durch Spamversand angemahnt. Hier ein Auszug:

“Von Ihrem Zugang wurde seit dem 24.03.2014, 5:xy Uhr mehrfach eine missbräuchliche Nutzung durch Spamversand festgestellt und gemeldet. Falls Sie sich nicht erklären können, wie es zum Versand dieser E-Mails gekommen ist, nehmen sie unser Schreiben bitte zum Anlass Ihr Computersystem unverzüglich zu prüfen….”

Im weiteren Verlauf des Textes wird darauf hingewiesen, dass damit gegen die Allgemeinen Geschäftsbedingungen der Telekom verstoßen wird. Es wird selbstverständlich mit der Sperrung des Anschlusses gedroht.

Auch wenn die Kunden in völlig unterschiedlichen Regionen der Republick angesiedelt sind, ist Ihnen eines gemein: Sie verwenden einen invis-Server. Grund genug mir einen gewissen Schrecken einzujagen.

Eine direkte Rückfrage zu den Schreiben bei der Telekom erwies sich an diesem Tag aufgrund einer Betriebsversammlung als unmöglich und die Warteschlangenmusik hält einen auch nicht mit Freuden in der Leitung.

Also direkt zur Fehlersuche. Ich habe alle drei Server auf Hinweise zum vermeintlichen Spamversand untersucht und nichts gefunden. Dass PCs der Kunden durch Schädlingsbefall zu Spamschleudern mutierten, ist schon allein aufgrund der genannten Uhrzeiten nicht möglich, sämtliche PCs waren schlicht aus.

Am darauf folgenden Tag hatte ich mehr Glück bei der technischen Hotline. Eine durchaus freundliche und hilfsbereite Dame hat sich die Vorfälle angeschaut und geriet beim Vorlesen des Wortes “Amplifier” hörbar ins Stocken. Ich half Ihr bei der Aussprache und musste Ihr daraufhin noch erklären was eine NTP-Amplifier Attacke ist und dass das definitiv NICHTS mit Email oder gar Spamversand zu tun hat.

Meine Frage, warum in den Schreiben nicht der tatsächliche Grund für die Abuse-Meldung genannt wird, beantwortete Sie mir mit “Standardschreiben”.

Der Fehler war schnell behoben. Auf invis-Servern läuft ein NTP-Dienst und leider ist Port 123/UTP auch in Richtung Internet offen. Peinlicherweise schleppen wir diesen Faux Pas schon eine Weile mit und das ist inzwischen leider gefährlich. (Wird aber unverzüglich behoben!)

Nicht so schnell konnte ich meinen Frust bezüglich der wirklich dämlichen Schreiben beseitigen. Jemanden bei der Telekom darauf ansprechen, nahezu unmöglich. Twittern, einfach!

Mein erster Tweet:

“Liebe #Telekom wenn sie #Abuse-Meldungen bez. Spam verschicken obwohl es sich um #ntp-Amplifier Att. handelt sind Sie Teil der DDOS Attacke.”

Die Überraschung war nicht schlecht als ich von “Telekom_hilft” eine direkte Antwort bekam:

Verstehe ich richtig, dass Sie ein Anschreiben von unserer Abuse-Abteilung erhalten haben? ^is”

Eine Reaktion macht Hoffnung, also Dialog aufnehmen:

@Telekom_hilft Drei unserer Kunden. Es wurde Spamversand angemahnt Ursache war aber eine NTP-Amplifier Attacke. Völlig Fehlerhafte Meldung”

@Telekom_hilft Sie können gerne direkt mit uns kommunizieren: http://bit.ly/1eeaX5Y

… und tatsächlich, eine weitere Reaktion:

Okay, wir unterscheiden das nicht so. Daher können wir uns nur für die Unannehmlichkeiten entschuldigen. ^ke”

Ein “wir unterscheiden das nicht so” kann man nicht unbeantwortet lassen:

Dürftige Haltung. Wenn Sie auf Ihren Schreiben einfach die Original Meldung weitergeben würden, wäre alles kein Problem.”

Bisher keine weitere Reaktion. Es bleibt festzustellen, dass die Telekom in “Social Media Marketing” investiert, vermutlich etwas mehr als in die fachliche Ausbildung der Hotline Mitarbeiter oder die Entwicklung sachlich korrekter Schreiben.

Sollte die Geschichte weiter gehen, werde ich hier die Fortsetzung liefern.

Stefan

27.August 2012

FrOSCon 2012

Trotz einem, aus meiner Sicht verhagelten Samstag (der Mailserver eines Kunden machte Probleme und ich konnte nicht eingreifen….) war die diesjährige FrOSCon ein ausgesprochen angenehmer Event. Nachdem der Serverstress erledigt war, war alles andere völlig entspannt.

Da wir inzwischen beinahe zum FrOSCon-Aussteller-Inventar zählen, ziehen wir zwar kaum noch neugierige Blicke von Besuchern, die uns noch nicht kennen auf uns. Trotzdem hatten wir viele nette und gute Gespräche bei denen der fachliche Austausch im Vordergrund stand. Das Ganze wird im positiven Sinne mehr und mehr zum Familientreffen ;-).

Spaß gemacht hat vor allem der Talk, den ich zum invis-Server und der dahinter stehenden Philosophie im Rahmen der Vortragsreihe “Open-Source in KMU und Verwaltung” halten durfte. Danke dafür an Michael Stehmann (http://rechtsanwalt-stehmann.de), ich hoffe diese Vortragsreihe macht auch auf anderen Events die Runde. Das Interesse des Publikums spricht für die Relevanz des Themenkomplexes. Die Folien zum Talk stehen übrigens hier zum Download bereit.

Etwas ruhig war es dieses Jahr an der Hotelbar. Schade war das besonders deshalb, weil man sich im Regina dieses Jahr wirklich auf den Abend vorbereitet hatte. …nur der üblich Ansturm blieb aus. Na ja, es wird auch nächstes Jahr eine FrOSCon geben!

Nebenbei hat die FrOSCon wieder mal ein weiteres Bugfix-Release unseres Setup-Paketes als Nebeneffekt hervor gebracht.

Schade, dass die OpenRheinRuhr dieses Jahr ausfällt, Michal Gisbers und sein Team haben aber schon für 2013 alles in trockenen Tüchern.

Unser nächster Event werden dann wohl wieder die Chemnitzer Linux Tage sein.

Stefan

vorbei und wir haben’s überlebt. ;-) Der schon nach einem Jahr “traditionelle” Whisky-Feldtest fiel ohne meinen geschätzten exLektor bedeutend harmloser aus als befürchtet. Aspirin wurde am Sonntag Morgen nicht benötigt. (Glück gehabt).

Insgesamt hat die Veranstaltung viel Spaß gemacht, großes Lob auch für den PizzaProxy 2.0. Technik kann bisweilen auch funktionieren….

Im Gespräch mit Interessenten wurde mir selbst erst bewusst, was sich technisch am invis-Server im vergangenen Jahr so alles getan hat. Der uns entgegen gebrachte Zuspruch macht ein bisschen stolz.

Wie immer ist ein solcher Open-Source-Event auch ein Ort, um kleine Basteleien vorzunehmen. Entsprechend habe ich mit Version 6.9-R1-alpha11 ein weiteres kleines Bugfix-Release unseres Setup-Paketes zum Download bereitgestellt.

Im Vorfeld der ORR habe ich mir ein paar Gedanken um die zukünftigen Entwicklungen des Projektes gemacht. Dabei ging es weniger um technische Dinge, als viel mehr um Organisatorisches. Herausgekommen ist dabei eine Roadmap bzw. ein Strategieplan für zukünftige Entwicklungs und Maintenance -Zyklen des invis-Servers (Download-Link: invis-Server_Entwicklungszyklus). Ob sich die Strategie so umsetzen lässt wird die Praxis zeigen. Wir werden unser Möglichstes tun.

Stefan

 

<Selbstironie>Nach nur knapp 2 Monaten gibt es schon das nächste Update .</selbstironie>

Darin wurde ein paar nervige Fehler gefixt, so lässt sich jetzt auch Group-e wieder installieren, und ein paar neue Dinge hinzugefügt. Darunter dürfte wohl vor allem das kleine Tool dwdatasnapshot interessant sein. Es erstellt Snapshots des Dokuwiki-Datenverzeichnisses, etwas was längst überfällig war. Einmal wöchentlich wird es vom Cron-Daemon aufgerufen, ansonsten lässt es sich auch jederzeit ohne weitere Optionen auf der Kommandozeile ausführen.

Ebenfalls neu und direkt aus einem praktischen Anwendungsfall heraus entstanden ist das Tool scanleases. Es hilft dabei Ordnung im Netz zu schaffen, indem es die Leases-Datenbank des DHCP-Servers durchsucht und Informationen über, sich wild im Netz tummelnde, IP-Geräte sammelt.

Sorgen (und daher Grund für die “alpha” Bezeichnung der aktuellen Pakete) bereitet immer noch die Integration von OpenERP und Zarafa. Während Zarafa wenigstens in der Community-Variante, also ohne Outlook-Anbindung zur Verfügung steht, haben wir es bisher nicht geschafft OpenERP so zu installieren, dass sich damit produktiv arbeiten lässt. Zwar laufen die Daemons openerp-server und openerp-web inzwischen “out of the box”, allerdings weigert sich Firefox die zugehörigen Seiten in der richtigen Zeichenkodierung anzuzeigen. Bei diesem Thema wäre Hilfe nicht unerwünscht:

Python Cracks bitte melden!

Was Zarafa und die Outlook-Anbindung angeht scheint Besserung in Sicht. Gaaanz inoffiziell haben wir erfahren, dass openSUSE und fedora zukünftig wieder unterstützt werden. D.h. die für den invis-Server derzeit fehlenden Komponenten “License-Daemon” und “zarafa-backup” werden (hoffentlich bald) wieder zur Verfügung stehen.

Stefan