Netz - Rettung - Recht

Mein DSL-Anbieter teilte gestern abend mit:

Aufgrund einiger Kundenanfragen wurden wir auf vereinzelte DSL-Einwahl-Probleme zu uns aufmerksam gemacht. Dies betraf allerdings nur einen kleinen Teil unserer DSL-Kunden (ca. 5%), so dass wir hier erst genauer analysieren mussten, da kein generelles Problem vorlag.

Laut derzeitigem Kenntnis- und Analysestand gab es im Laufe des gestrigen Abends und heutigen Tages eine Störung der Weiterleitung der DSL-Einwahl-Anfragen einiger (nicht aller) Kunden von der T-Com zu uns (was allerdings noch unbestätigt ist). Dies betraf jedoch nicht bestehende DSL-Sitzungen (sprich wenn Sie bereits eingewählt waren).

Ob Ihr Zugang betroffen war oder nicht, können wir leider technisch bedingt an dieser Stelle nicht zutreffend sagen, dieses Mailing erhalten Sie daher vorsorglich.

Doch, doch - das traf schon einen der Richtigen. Aber jetzt kann ich immerhin beruhigt festhalten, daß das Problem nicht bei der häuslichen Einwahltechnik lag - und das ganze Debugging für die Katz war.

Dieser Tage stellte ich fest, daß mein Newsserver offensichtlich keine Steuernachrichten mehr ausführt. Aber warum bloß?

Die Rücknahme einiger jüngerer Änderungen - die sicherstellen sollten, daß die Steuernachrichten nicht nur ausgeführt, sondern mir auch gemailt werden (mit Dank an den Widder!) - brachte keine Lösung. Also bin ich zu systematischen Debugging übergegangen; dank fehlenden Loggings anhand des Einstreuens von Ausgabeanweisungen in eine Kopie des zuständigen Scripts (controlchan). Stunden später[tm] stellte sich dann als Ursache … ein Bedienerfehler heraus (wie immer). Wenn man Steuernachrichten für eine bestimmte Hierarchie verwerfen will, dann sollte man den Namen der Hierarchie nicht nur als Kommentar in die control.ctl eintragen, sondern für den entsprechenden Eintrag auch ein Muster wie hierarchie.* verwenden. * alleine führt nicht zum erwünschten Ergebnis (sondern zum Verwerfen aller Steuernachrichten für alle Hierarchien).

Als wir vor einigen Jahren unsere neue Wohnung bezogen haben, fiel mir die Sorge um die Telekommunikationsanschlussfragen zu. Damals an einem Wohnort die spurtstarke Leistung eines DSL-1000-Anschlusses gewohnt und am anderen immerhin mit DSL-2000 verwöhnt stellte sich zu meiner großen Freude heraus, daß am neuen Wohnsitz neben VDSL in allen Arten auch DSL-6000 und DSL-16000 verfügbar waren. Nachdem ich ein Freund des Verbleibs beim rosa Riesen bin, war ein passender Tarif schnell gebucht (die inbegriffene Festnetzflatrate, mit der ich selbst wenig anfangen kann, hat sich mittlerweile übrigens auch als segensreich erwiesen … mehr sage ich dazu jetzt nicht ), und nach einigen kleineren Schwierigkeiten *räusper* war dann auch technisch und organisatorisch alles im grünen Bereich. Einziges Manko: Die nach der Online-Verfügbarkeitsprüfung angeblich bereitstehende 16.000er-Anbindung konnte man nicht schalten - aber 6.000 ist ja immer noch mehr als 2.000.

So genossen wir - beide keine großen "Sauger" - die letzten Jahre das stabile Surfvergnügen, bis ich dieser Tage einmal im Rahmen der diversen Erledigungen auch einen Abstecher zum Kundencenter machte, um mir einen Überblick über die zur Verfügung stehenden neuen Tarife und anderen Optionen zu machen. Höchst erfreut konnte ich dabei dann feststellen, daß es mittlerweile möglich ist, ohne Tarifänderung und ohne Aufpreis die (im Tarif enthaltene, aber bei Einzug nicht zur Verfügung stehende) 16.000er-Leitung zu schalten. Das habe ich dann auch direkt beauftragt, eine Auftragsbestätigung für einen Schalttermin in einigen Wochen erhalten, die kurz darauf auch schriftlich bestätigt wurde … und dann die Angelegenheit prompt wieder vergessen.

Bis mir heute morgen wieder einfiel, daß der Umschalttermin eigentlich schon um sein müßte. Und was soll ich sagen?

Wir sind jetzt im Geschwindigkeitsrausch.

 

Manche Dinge muß man nicht verstehen - und sie sind auch furchtbar schwer einzugrenzen.

Man stelle sich folgende Situation vor:

Ein Netzwerk, in dem ein Server (Debian Squeez) und ein Desktop (WinXP) stehen, außerdem ein WLAN-Accesspoint, über den zwei Laptops (einmal WinXP, einmal Win7) an das Netz angebunden sind. Auf dem Server läuft ein isc-dhcpd, also der DHCP-Server des ISC, der die Clients mit IP-Adressen versorgt. Beide Rechner, die unter Windows XP laufen, bekommen problemlos DHCP-Leases, und alles ist gut.

Jetzt kommt der Rechner unter Windows 7 hinzu - und nichts geht mehr. Nicht nur, daß der Rechner keine IP-Adresse zugewiesen bekommt; auch der andere, über WLAN angebundene Laptop verliert während dieser Versuche, per DHCP eine Adresse zu bekommen, reproduzierbar die Verbindung zum Server, so daß SSH-Verbindungen abbrechen und die DNS-Auflösung nicht mehr funktioniert. Andere bestehende Verbindungen von diesem XP-Laptop aus bleiben aber bestehen. Im Log des DHCP-Servers spielen der Win7-Client und der Server Pingpong mit DHCPDISCOVER und DHCPOFFER, kommen aber nie weiter zu DHCPREQUEST und DHCPACK, d.h. der Client fragt nach einer IP-Adresse, er bekommt eine angeboten, registriert das aber nicht und wiederholt seine Anfrage ad nauseam.

Nach langem Lesen und Probieren wird als Probe aufs Exempel ein weiterer Laptop mit Win7 ins Netz gebracht, um auszuschließen, daß das Problem beim Laptop liegt - und tatsächlich, auch dieser Rechner bekommt per DHCP keine IP-Adresse zugewiesen! Das Problem ist also offenbar ein generelles.

Googeln wird bei diesem Thema dadurch erschwert, daß es haufenweise Treffer gibt, die aber im wesentlichen alle mit diesem Problem nichts zu tun haben und oft nur die Unkenntnis der Beteiligten über DHCP, Windows und diverse andere Gegenstände erkennbar machen. *seufz*

Hätte jemand zu diesem Problem auf Anhieb einen Lösungsansatz gehabt? (Außer dem Mitschneiden des Netzwerkverkehrs zwischen dem Client und dem nicht-funktionsfähigen DHCP-Server im Vergleich zum Verkehr zwischen dem Client und einem funktionierenden Server.)

"isc-dhcpd, Windows-7-Clients und kein DHCP?" vollständig lesen

Für lokale Netze ist ein DHCP-Server eine nützliche Einrichtung, ermöglicht er doch die automatische Adreßvergabe. Die meisten Consumer-DSL-Router (und nicht nur diese) haben entsprechende Funktionalitäten eingebaut; noch schöner und flexibler ist es aber natürlich, selbst einen entsprechenden Dienst bereitzustellen, weil man ihn dann genau so konfigurieren kann, wie man ihn gerne hätte, um neben der automatischen Vergabe von IP-Adressen auch bestimmten Rechnern feste Adressen zuzuweisen und zugleich im internen Netz eine Namensauflösung zu organisieren.

Dafür bedarf es im Prinzip dreierlei:

• Zunächst benötigt man einen DHCP-Server (dhcpd), bspw. den des ISC, der dann so konfiguriert werden muß, daß er die erwünschten Adressen an die Clients zuweist.
• Dann benötigt man einen DNS-Server, bspw. den BIND des ISC, der dann so konfiguriert werden muß, daß er Namen im lokalen Netz zu IPs auflöst und umgekehrt lokale IPs zu den richtigen Namen.
• Und letztlich muß man in einem zweiten Schritt die beiden so miteinander verheiraten, daß der DHCP-Server dem DNS-Server erzählt, welche IPs er an welche Maschinen dynamisch vergeben hat.

All das ist vergleichsweise einfach unter Debian möglich.

Im folgenden Beispiel gehe ich davon aus, daß das lokale Netz den IP-Bereich von 10.0.0.1-10.0.0.254 (10.0.0.1/24) umfassen soll und die Domain example.org verwendet wird. Der Host, auf dem DHCP- und DNS-Server laufen, heißt server.example.org und hat die (fest konfigurierte) IP-Adresse 10.0.0.1.

"DHCP-Server und automatische DNS-Zone-Updates" vollständig lesen

Bereits vor einiger Zeit hat mir das Bravszaf htop empfohlen, eine graphischefarbige Version des bekannten process viewers top, der die auf einem System laufenden Prozesse und weitere Informationen über die Ressourcenauslastung anzeigt. Inzwischen habe ich das auf mehreren Maschinen getestet und bin durchaus positiv beeindruckt.

Tip: Einfach mal ausprobieren.

Gestern schrieb ich schon, daß ich mal wieder wahrlich zu nichts komme (jedenfalls nicht zu den Sachen, die ich mir vorgenommen hatte) - daher mußte bislang auch die Einrichtung des neuen Rechners (die ich eigentlich in der ersten Woche des neuen Jahres abzuschließen hoffte) zurückstehen. Heute habe ich damit aber dann einmal - mit Unterstützung aus dem IRC - angefangen und ein Debian Squeeze (dessen Release ja unmittelbar bevorsteht) installiert. Da die Maschine per KVM-Switch an Monitor, Tastatur und Maus hängt, habe ich mich mittlerweile entschlossen, sie nicht nur als Server, sondern auch als Desktop zu nutzen, auch um einmal ein Gefühl dafür zu bekommen, wie sich ein Linux auf dem Desktop so anfühlt - denn obschon ich seit gut 10 Jahren mit Linux als Server-OS umgehen, arbeite ich auf dem Desktop immer noch unter Windows (zunehmend ergänzt um Tools aus der unixoiden Welt).

Aufgrund meiner bisher mangelnden Erfahrung mit der Installation eines Systems (ich kenne den Arbeitsgang in der Regel erst beginnend mit der Anpassung eines vom Provider aufgespielten Images und habe Erfahrung im wesentlichen mit dem Zugang via SSH, nicht mit der Arbeit an der Konsole …) und der Tatsache, daß Debian für das bevorstehende Release alle nicht-freie Firmware aus dem main-Archiv entfernt hat, befürchtete ich erhebliche Probleme, schließlich sind mir aus den vorgenannten Gründen im weitesten Sinne hardwarenahe Arbeiten (Treiber, Kernel, Partitionierung von Platten, Auswahl des Filesystems und Einrichtung von RAID, LVM und Co.) nicht wirklich vertraut. Der Ablauf erwies sich aber als angenehm einfach.

Nach dem Herunterladen eines Netinstall-Images aus den täglichen Snapshots und dessen Brennen auf CD wurde mir nach dem Boot angeboten, den graphischen oder den konsolenorientierten Installer zu starten, wobei ich mich für letzteres entschied; danach wurde ich durch die Ersteinrichtung geführt, bis … tatsächlich eine fehlende Firmware (rtl8168d-1.fw) gefunden wurde, sinnigerweise ausgerechnet für die (Realtek-)Netzwerkkarte (ohne die sich ein Netinstall dann vermutlich nicht so richtig erfolgreich gestalten dürfte). Glücklicherweise hatte ich mich bereits vorher informiert, wo Debian die nicht-freie Firmware jetzt versteckt hat, so daß ich den entsprechen Tarball herunterladen und via USB-Stick bereitstellen konnte. Das half aber nicht; weder der Tarball noch die ausgepackten Debs konnten den Installer glücklich machen. Weitere Suche mit dem Namen der vermißten Firmware führte dann zu einem Bugreport und dem entsprechenden Firmware-Paket mit Realtek-Firmware; ich habe dann entsprechend das dort verlinkte Tar-Archiv heruntergeladen, ausgepackt und - nach mehreren erfolglosen Versuchen - die Realtek-Firmware in das Root-Verzeichnis des USB-Sticks gepackt. Jetzt war der Installer glücklich.

Im weiteren Verlauf gelang es mir allerdings dennoch nicht, eine Netzwerkverbindung aufzubauen, was die weitere Installation etwas hinderte, insbesondere soweit Repositories eingebunden und Sicherheitsupdates geladen werden sollte; nach deren Abschluss und einem Reboot war jedoch eine Netzwerkverbindung vorhanden. Hilfreich für den absoluten Anfänger *hüstel* ist es übrigens in solchen Fällen zu wissen, daß man mit Alt-4 ein Terminal mit den Logs und Fehlermeldungen angezeigt bekommt, mit Alt-1 wieder zurückkomt und ggf. auf einem der anderen TTYs eine Shell starten kann. Dokumentiert ist das im Install-Manual.

[Update vom 23.01.2011: Offenbar handelt es sich bei dem Problem mit der Firmware für die Realtek-Netzwerkkarte noch um einen Bug, der mit dem ersten Point-Release behoben werden soll - sowohl hinsichtlich der Probleme des Installers, die Firmware auf dem USB-Stick zu finden, als auch hinsichtlich der fehlenden Netzwerkkonnektivität nach dem Finden der Firmware.]

Der Rest der Installation bis zum ersten Reboot verlief ereignislos, gut unterstützt und dokumentiert - es gelang mir auch auf Anhieb (naja, mit einigen Versuchen), aus meinen beiden Festplatten ein RAID 1 (mit gesonderter Bootpartition) zu erstellen, darüber LVM zu legen, die einzelnen Logical Volumes anzulegen und zu formatieren, ohne daß ich (abgesehen von Hinweisen zu der grundsätzlichen Auswahl des Filesystems und der Partitionierung) irgendeine Unterstützung via IRC gebraucht hätte.

"Installation von Debian Squeeze" vollständig lesen

Letztes Jahr hatte mich am Abend des letzten Urlaubstag ein Ausfall meines heimischen Servers erwischt; Ursache war ein Defekt des Netzwerkkabels, das vor Zeiten einmal der Einfachheit halber über den Dachboden verlegt worden war. Ursache unklar, obwohl aus meiner Sicht bereits damals schon viel für den Einzug eines Mitbewohners dort oben und dessen Verantwortlichkeit gesprochen hat. Danach ist die Sache etwas im Sande verlaufen.

Gelöst ist das Problem aber offensichtlich nicht, denn was auch immer die Ursache ist, sie breitet sich aus: seit heute hat auch mein dort noch vorhandener Desktoprechner kein Netz mehr. Auch dort liegt’s am Netzwerkkabel. Mag ja sein, daß die Kabel damals vor gut 10 Jahren einfach schlecht verlegt wurden und nun allmählich ausfallen, aber irgendwie mag ich daran als Ursache nicht so recht glauben … Ärgerlich ist’s ursachenunabhängig allemal, vor allem, weil dort oben auch die Telefonkabel verlegt sind. Nun denn, we’ll see.

Über die Einrichtung des Monitoring-Tools Munin habe ich bereits vor 2 Jahren geschrieben. Mittlerweile habe ich meine Installation aus den Debian-Backports auf die Version 1.4.5 geupdatet, die deutlich ressourcenhungriger zu sein scheint; überdies sind mittlerweile auch mehr Hosts durch Munin zu überwachen. Beides führte zu einer spürbaren Grundlast auf dem (älteren) System, das bislang den Munin-Server darstellte; daher habe ich Munin nunmehr auf eine andere Maschine umgezogen, was deutlich sichtbare Performance-Verbesserungen gebracht hat, die sich schon in einer Laufzeitverkürzung darstellen.

Bei dem Umzug sollten aber auf jeden Fall die bereits erstellten Statistiken aus den letzten beiden Jahren erhalten bleiben, um nicht komplett von vorne beginnen zu müssen. Eigentlich sollte ja nichts leichter als das sein: Munin auf dem neuen Rechner installieren, die Konfiguration des alten Systems übernehmen, das neue System auf allen Nodes für den Abruf freischalten, testen, dann die gesammelten Daten auf dem alten Rechner packen, auf den neuen transferieren und dort wieder auspacken, Munin auf dem alten Rechner anhalten, fertig. Ungefähr so geht das auch tatsächlich - wenn denn diebeiden Systeme dieselbe Architektur haben. Wenn aber der alte Rechner ein 32bit-System ist und der neue ein 64bit-System, dann sind die erzeugten RRD-Dateien nicht kompatibel. Autsch. Aber auch dafür gibt es glücklicherweise eine Lösung, die ich einem alten Eintrag aus dem Cacti-Forum abgeschaut habe.

"Munin auf einen anderen Host umziehen" vollständig lesen

Drucken ist eine Standardaufgabe - Scannen auch. Heutzutage gibt es dafür bereits Multifunktionsgeräte, die in der Regel Drucken und Scannen und in Kombination dieser beiden Funktionen auch kopieren können; teilweise beherrschen sie auch das Faxen.

Nicht immer aber hat man eines dieser Multifunktionsgeräte zur Verfügung, sondern hat nur Scanner und Drucker; oder man hat ein Multifunktionsgerät, aber es druckt nicht; oder man hat ein Multifunktionsgerät, will aber die Druckfunktion nicht nutzen, weil es sich bspw. um einen Tintenstrahldrucker handelt und der Ausdruck dort sowohl langsamer als auch teurer ist als auf dem gleichfalls vorhandenen Laserdrucker. In diesem Fall kann man dennoch Dokumente einscannen und danach dann ausdrucken. Sehr bequem ist es aber, wenn man dazu ein Tool hat, was das automatisiert.

iCopy ist ein solches Windows-Tool. Es erlaubt die Auswahl des zu verwendenden Scanners und Druckers und weitere Konfigurationseinstellungen - in der Regel genügt der Default -, und danach muß man nur noch auf den Kopierknopf klicken. Der Scanner scannt, und sobald das Bild eingescannt ist, druckt der Drucker es aus. Voilà. Selbst ohne automatischen Einzug am Scanner kann man so schnell und effizient einen ganzen Stapel Kopien anfertigen: Original einlegen, Abdeckung am Scanner schließen, Kopiertaste in iCopy anklicken, nach dem Scan das Original gegen das nächste tauschen, während der Drucker druckt, lather, rinse, repeat.

iCopy ist open source, aktuell ist derzeit Version 1.48 vom 05.01.2011.

Niemand will Backup. Alle wollen Restore.

(Kristian Köhntopp zitiert einen Vertriebler - Fachbegriffe der Informatik #125)

Regelmäßige Backups sind wichtig und auch durch redundante Systeme wie RAIDs nicht zu ersetzen; ganz abgesehen davon, daß bei einem RAID 1 gerne die - meistens ja zum selben Zeitpunkt wie die erste in Betrieb genommene - zweite Platte beim notwendigen Rebuild zusammenbricht, schützt ein RAID auch nur gegen Datenverlust durch Ausfall einer Festplatte, aber weder gegen versehentliches oder böswilliges Löschen, Überschreiben oder Verändern von Daten, noch kann es gegen einen fatalen Schaden des gesamten Systems (Brand, Diebstahl, …) schützen. Backups sollten daher

• regelmäßig durchgeführt werden,
• versioniert sein (so daß man einen längeren Zeitraum zurückgehen kann) und
  
• off-site transferiert werden können.

Zumindest dann, wenn man keine Kontrolle über die Infrastruktur hat, auf der die Backups gespeichert und über die sie transportiert werden, sollten Backups auch verschlüsselt sein. Diese letzte Anforderung ist typisch für sog. "Rootserver", also Mietserver, zu denen bei üblichen Angeboten auch ein sog. "Backupspace", also Speicherplatz auf einem Storage gehört, auf den zumeist nur per (unverschlüsseltem) FTP zugegriffen werden kann. Selbst wenn man dem Provider und seinen Mitarbeitern vertraut, kann man nicht ausschließen, daß auch Dritte - andere Kunden, … - zumindest den unverschlüsselten Datenverkehr zwischen dem zu sichernden Server und dem Storage "belauschen" können. Wenn man seine Backups also unverschlüsselt überspielt, kann die gesamte Konfiguration samt aller Paßworte usw. usf. mitgelesen werden.

Schließlich gibt es eine letzte Anforderung für sinnvolle Backups: sie sollten, einmal eingerichtet, möglichst wenig Aufwand bedeuten, optimalerweise automatisiert sein, denn nur dann werden sie auch wirklich regelmäßig durchgeführt.

Alle zuvor genannten Anforderungen erfüllt das Tool duplicity, für das die c’t bereits anno 2006 ein Frontend namens ftplicity entwickelt hat, das nunmehr unter dem Namen duply weiterentwickelt wird. duply unterscheidet sich u.a. dadurch von ftplicity, daß es nicht nur die Konfiguration der Übertragung via FTP unterstützt, sondern auch auf anderem Weg (was dann auch die Namensänderung erklärt).

duplicity sichert Dateien und Verzeichnisse in (nicht gepackte!) tar-Archive, verschlüsselt diese vermittels GnuPG und überträgt die Sicherungen in kleinen Häppchen auf verschiedenen Wegen (lokal, FTP, SCP, rsync, …) auf das Sicherungsmedium; dabei werden inkrementielle Backups über den rsync-Algorithmus erstellt, d.h. nicht alle veränderten Dateien gesichert, sondern ggf. nur ein diff, was wiederum Platz und Bandbreite spart. duplicity dürfte in den meisten Distributionen paketiert sein, duply ist es in Debian ab Squeeze, kann aber in jedem Fall trivial installiert werden.

"Backup mit duply und duplicity" vollständig lesen

Auf der Suche nach einem Tool zur Erstellung von Diagrammen (bspw. Netzwerkdiagrammen etc. pp.) unter Windows, das nicht Visio heißt und vor allem nicht in dessen preislichen Regionen rangiert, bin ich auf das Freeware-Programm yED gestoßen, das mir schon recht gut gefällt. Was mir noch etwas fehlt sind passende Symbole (Shapes), derzeit namentlich für Netzwerkdiagramme und am besten optisch passend zu den bereits vorhandenen. Ein Musterdiagramm könnte bspw. so aussehen:

 

Das Symbol für den Router ist aber schon nicht so richtig passend, Laptops hat’s bisher auch nicht, usw. usf.

Wenn jemand noch bessere Software im Angebot hat, nehme ich natürlich auch Hinweise darauf gerne entgegen.

Bei meiner Arbeit mit git stehe ich immer wieder vor der Frage, ob man dieses oder jenes damit nicht einfach machen können müßte. Meistens lautet die Antwort auf diese Frage "ja", aber teilweise muß man schon etwas googeln, um diese Antwort zu finden. Daher möchte ich ab und an kleine ergoogelte Wissensschnippsel mit der Leserschaft teilen; vielleicht steht ja noch einmal jemand anderes vor demelben Problem (und überdies sind deutschsprachige Informationen zu git nicht so wirklich umfänglich vorhanden).

Git über SSH und mehrere SSH-Keys pro Host

Mehr eine allgemeine SSH-Frage, aber da sie sich mir im Zusammenhang mit git gestellt hat …

Ein beliebter Zugriffsweg auf Git-Repositories ist der über SSH, insbesondere, wenn es auch um einen schreibenden Zugang geht und man diesen authentifizieren will. Zu diesem Zweck kann man sich den passenden SSH-Schlüssel für den Zugriff auf das Git-Repository über die SSH-Konfiguration definieren, bspw. durch einen Eintrag in ~/.ssh/config wie den folgenden:

Host git.example.org
Port 2022
IdentityFile ~/.ssh/gitkey

SSH-Zugriffe auf den Server "git.example.org"  erfolgen also auf Port 2022 (statt 22) und unter Verwendung des Schlüssels "gitkey". Der Git-Zugriff via SSH berücksichtigt diese Einstellungen dann automatisch.

Was aber tun, wenn man von demselben Client mit mehreren verschiedenen SSH-Schlüsseln auf denselben Server zugreifen muß, wie es insbesondere bei der Verwendung von Tools wie gitosis auf der Serverseite vorkommen kann? Dieselbe Frage stellt sich natürlich, wenn man sich neben dem Zugriff auf ein Git-Repository auch ganz normal per SSH auf dem Server einloggen können will. Auf die obige Art und Weise läßt sich nur ein Key für den Zugriff auf "git.example.org" vordefinieren - und will man wirklich immer einen abweichenden Schlüssel per Option angeben? Eine Lösung wäre die Vergabe von weiteren CNAMEs im DNS für git.example.org, aber das skaliert auf die Dauer auch nicht.

Die einfachste Lösung dafür bieten Aliase direkt in der SSH-Konfiguration, wie das Git-Wiki empfiehlt:

Host private.example.com
    User myname
    Hostname git.example.com
    IdentityFile ~/.ssh/private-identity
Host public.example.com
    User groupname
    Hostname git.example.com
    IdentityFile ~/.ssh/public-identity

Auf diese Art und Weise kann man denselben Server mit zwei verschiedenen Konfigurationen ansprechen.

"Tips und Tricks für den Umgang mit git" vollständig lesen

Als Hobby-Admin *räusper* lernt man ständig dazu. Bekannt und bewußt war mir schon, daß nach (Sicherheits-)Updates von Bibliotheken, die von verschiedenen Programmen genutzt werden (man denken an OpenSSL), die entsprechenden laufenden Prozesse neu gestartet werden müssen, weil sie nur dann die dynamisch geladenen Bibliotheken neu laden und zuvor mit der alten Version arbeiten, was insbesondere bei sicherheitsrelevanten Updates nicht besonders hilfreich ist. Bisher ging ich allerdings (blauäugig) davon aus, daß die Paketverwaltung das schon richten wird. Durch einen Beitrag von Paul Wise in der Debian-Developer-Mailingliste wurde mir nun bewußt, daß das - jedenfalls / auch unter Debian - nicht der Fall ist, die betreffenden Dienste also manuell neu gestartet werden müssen.

Hilfreich ist in diesem Zusammenhang das im Paket debian-goodies enthaltene Tool checkrestart, das überprüft, welche laufenden Prozesse noch auf Dateien zugreifen, die mittlerweile gelöscht wurden, und diese auflistet (zusammen mit ggf. vorhandenen init-Scripts, um die Dienste neu zu starten).

Wer (digitale) Fotos - in welcher Menge, Häufigkeit und Qualität auch immer - macht, der kennt das Problem, sie online verfügbar zu machen. Gut, das eigentliche Problem ist die Überwindung der eigenen Faulheit und das Auswählen, Sortieren, Umbenennen und ggf. Kommentieren einmal wirklich anzugehen, aber man möchte dazu auch die entsprechende, möglichst einfach verwendbare, aber alle notwendigen Funktionen bietende Software haben.

Man kann dazu Web-2.0-Dienste wie flickr nutzen, aber nicht jeder möchte das, sei es, daß man solchen Diensten generell nicht traut und/oder die Software lieber selbst installieren möchte, sei es, daß man am "Sharing" von Fotos gar nicht interessiert ist, sondern den Zugriff potentiell nur wenigen ermöglichen möchte. Insoweit habe ich dann schon einiges durch: mehr schlecht als recht selbst gebaute Implementationen für die Webseiten meiner Hilfsorganisation oder einer Newsgroup (seit ~ 2002), dann für meine private Homepage (ebenfalls seit ~ 2002) mig, ein sehr einfaches Script (auch deshalb, weil man von den Platzhirschen wie Gallery nicht viel Gutes über die Sicherheit hörte), und seit Anfang 2008 (nach dem Erhalt meiner neuen Kamera Weihnachten 2007) auch eine Gallery-2-Instanz, mit der ich allerdings nie so recht angefreundet hatte (zumal bis zu einem Kurzurlaub 2008 zurück noch Bilder zum Sortieren und Hochladen im Backlog liegen - siehe die einleitenden Worte zu diesem Artikel ). Während ich jetzt darüber nachdachte, ob sich nicht ein Update auf Gallery 3 anbietet, bekam ich den weisen Rat, mir doch einmal piwigo anzusehen.

Und das hat mich überzeugt. Zumindest dann, wenn man eine Fotogalerie-Applikation nur für sich selbst ohne ausgefeiltes Benutzermanagement für mehrere Fotografen braucht (und wie oft teilt man sich eine Galerie wirklich zu mehreren?), ist piwigo eine tolle Lösung. Installation und Konfiguration sind einfach (Voraussetzungen: PHP und mySQL), wenn man das Prinzip einmal begriffen hat, der Upload ist übers Web wie auch einfach per FTP möglich, Thumbnails werden erstellt, Benutzer können in vorgegebene Rechtegruppen (Gast, Bekannter, Freund, Familie, …) oder in Nutzergruppen eingeteilt werden, und für Alben bzw. Fotos lassen sich dann die entsprechenden Zugriffsrechte setzen. Fotos lassen sich nicht nur in Alben, sondern in Kategorien zusammenfassen und zugleich noch beliebig taggen; der Benutzer kann sich die Fotos nach Kategorien oder Tags oder nach dem Kalender oder sonstwie anzeigen lassen, bekommt dabei aber immer nur die Fotos oder Kategorien zu sehen, für die er entsprechende Rechte hat. Außerdem gibt es eine Reihe vorgefertigter, recht ansehnlicher Skins.

Mir gefällt’s jedenfalls, und ich habe den heutigen Tag dann im wesentlichen dazu genutzt, aus den drei oder vier vorgenannten Quellen der letzten 10 Jahre die dort vorhandenen Fotos in einer Galerie zusammenzuführen und dann den Rest zu löschen. So gesehen also wie gestern ein weiterer Tag des Räumens und Sortierens.