Schlagwort-Archive: Linux

Bash: History mit Zeitpunkten und unbegrenzter Größe & .bashrc vs. .bash_profile

Auch wenn es einige Alternativen zur gewöhnlichen Bash unter Linux gibt, zählt sie auch heute noch zu den beliebtesten Shells. Auch ich selbst nutze sie auf meinem Server noch rege. Die Z shell (zsh) sieht zwar ebenso vielversprechend aus, aber das ist ein Thema für ein anderes mal.

Unbegrenzte History
Kommen wir zurück zur Bash: etwas, dass ich lange vermisst habe, war die Größe der History so festzulegen, dass diese nicht begrenzt ist. Oftmals gibt es dann doch den einen Befehl, der nützlicherweise noch in der History schlummern könnte, wenn er nicht schon dem Größenlimit zum Opfer gefallen wäre. Festlegen lässt sich die Historygröße grundsätzlich über die beiden Variablen HISTSIZE sowie HISTFILESIZE. HISTSIZE legt dabei die maximale Anzahl von Befehlen bzw. Zeilen fest, die in der History im Hauptspeicher während einer Sitzung festgehalten bleiben. HISTFILESIZE legt dagegen die maximale Anzahl von Befehlen bzw. Zeilen in der Historydatei fest, die gespeichert bzw. beim Start der Bash geladen werden. Wichtig ist also, beide Werte entsprechend anzupassen. Bis zur Bash Version 4.3 gab es AFAIK keine Möglichkeit, beide Werte auf „unlimitiert“ zu setzen, sodass lediglich ein möglichst hoher Wert eine Alternative darstellte. Seit Version 4.3 führt ein Wert kleiner 0 zu einer unbegrenzten Größenfestlegung. Dazu sind folgende beiden Einträge in die Bashkonfiguration aufzunehmen:

HISTFILESIZE=-1
HISTSIZE=-1

History mit Zeitangaben
Doch auch wenn nun verwendete Befehle weit in der Vergangenheit nachgeschlagen werden können, bleibt manchmal die Frage offen, zu welchem Zeitpunkt ein Befehl ausgeführt wurde. Über HISTTIMEFORMAT lässt sich das Historyformat entsprechend anpassen, sodass die History künftig um eine Zeitangabe erweitert wird.  Ein mögliches Format kann beispielsweise so aussehen:

HISTTIMEFORMAT=“[%d.%m.%y] %T „

Dies resultiert in Historyeinträgen im folgenden Schema:
536 [12.02.18] 00:13:56 ls -lha

.bashrc vs .bash_profile
Bleibt noch die Frage offen, in welche der beiden Dateien die neuen Kofigurationszeilen aufzunehmen sind. Grundsätzlich lassen sich die Einträge in beide Dateien eintragen, sie werden allerdings zu unterschiedlichen Zeitpunkten Verwendung finden. Die .bashrc wird bei jedem Öffnen eines interaktiven Terminals automatisch geladen, während die .bash_profile beim Öffnen einer Login-Shell geladen wird. Um auf der sicheren Seite zu sein, müssten die Einträge also in beiden Dateien vorgenommen werden. Bei einem Server, der ohnehin grundsätzlich über SSH angesteuert wird, lässt sich die .bashrc aber auch automatisch mit der .bash_profile ausführen. Dazu ist lediglich folgendes kleine Snippet in die .bash_profile einzutragen:

if [ -f ~/.bashrc ]; then
source ~/.bashrc
fi

 

 

Winfsp & sshfs-win als Dokan & win-sshfs Ersatz

Es existieren verschiedene Möglichkeiten, externe Linux Netzwerklaufwerke unter Windows einzubinden. Zuhause im LAN hat sich Samba, das auf SMB/CIFS setzt, bewährt. Auch über LAN-Grenzen hinweg lässt sich Samba nutzen, allerdings möchte ich Samba ungerne auf einer dedizierten Maschine – die für andere Dienste genutzt wird – rein für diesen Zweck betreiben. Aus diesem Grund habe ich in der Vergangenheit nach passenden Tools gesucht, die eine Einbindung über das SSHFS erlauben. Neben einigen kostenpflichtigen Lösungen (Mountain Duck, ExpanDrive, NetDrive, u.a.) bin ich damals auch auf Dokan und win-sshfs gestoßen. Die Dokan Library stellt dabei den Unterbau bereit, der die Einbindung von virtuellen Dateisystemen unter Windows ermöglicht. Über win-sshfs lässt sich dann das SSHFS über eine GUI einbinden. Beide Tools sind Open Source und auf GitHub zuhause. Dokan wird sehr aktiv weiterentwickelt, dies trifft auf win-sshfs leider – trotz Forks – nicht mehr zu. Die aktuelle Version ist dabei leider nicht mehr mit Dokan kompatibel, auch ein Workaround aus dem Issue Tracker hat bei mir keine Abhilfe gebracht. Also ging die Tage die Suche erneut los. Neben einem Blick auf die kommerziellen Lösungen bin ich durch Zufall auch auf ein noch relativ neues Projekt gestoßen: Winfsp. Winfsp ist dabei quasi das Äquivalent zu Dokan, zur Einbindung des SSHFS existiert mit sshfs-win eine Zusatzlösung vom gleichen Autor. Auch diese beiden Tools sind Open Source. Die Einbindung eines SSHFS nach der Installation beider Tools geschiet direkt über die gewohnte „Netzwerklaufwerk verbinden“ Oberfläche im Windows Explorer. Lediglich der Pfad sieht etwas anders aus:

\\sshfs\<benutzer>@<server>!<port>\\<pfad>
z,B, \\sshfs\root@example.local!22\\/var/www

Momentan werden SSH Keys zur Authentifizierung noch nicht nativ unterstützt, über Umwege scheint dies aber möglich zu sein.
Genauere Erfahrungswerte zu Winfsp/sshfs-win kann ich abschließend ich noch nicht mitteilen, allerdings laufen erste Tests unter Windows 10 x64 1709 bislang vielversprechend.

 

Von scheinbaren Backupproblemen und der nicht ganz unnützlichen Optimierung

Vor einer Woche staunte ich nicht schlecht als ich tagsüber den Server routinemäßig kontrollierte. Der Serverload lag bei 1.0 (das entspricht ungefähr der Auslastung eines Kerns, wobei eigentlich noch der I/O Wert zu beachten ist). Ein kurzer Blick in die Prozessliste förderte bzip2  als „Übeltäter“ zu Tage. Da konnte nur der Backupprozess in Frage kommen, doch eigentlich sollte dieser zu jener Tageszeit schon längst beendet worden sein. Wieso lief bzip2 also nicht rund? Eine schnelle Ursache konnte ich nicht finden und habe das ganze erst einmal weiter beobachtet. Doch auch in den Folgenächten besserte sich die Situation nicht. Es ging also ins Detail. Nebenbei untersuchte ich gleichzeitig Möglichkeiten, um den Backupprozess zu beschleunigen. Die weitere Ursachenforschung brachte letztendlich das wahre „Problem“ zum Vorschein: die Größe der zu sicherenden Daten belief sich auf über 250 GB – da konnte etwas nicht stimmen! Und siehe da, das Problem war ein hausgemachtes. Ich hatte bei der letzten Migration auf die neusten Softwareversionen der LAMP-Umgebung die MySQL Replikationslogs in ein zu sicherendes Verzeichnis mitverschoben und diese hatten nunmal einen Umfang von mehr 200 GB (was ohnehin unnütz ist, aber so leert sich nun auch ein weiterer Punkt auf der ToDo Liste..). Nach der Entfernung dieser Dateien gestaltete sich der Backupprozess auch wieder ähnlich flott wie zuvor. Die parallelen Optimierungsarbeiten am Backupscript hatten auch ihre gute Seite: bzip2 wird fortan durch pbzip2 ersetzt, das nun alle Kerne nutzt.

Schön zu sehen: der Backupprozess nutzt nun alle Kerne
Schön zu sehen: der Backupprozess nutzt nun alle Kerne

Gnome 3 – ein erster Eindruck

Die Vorurteile über Gnome 3 waren  im Vorfeld ziemlich groß und gingen von der Unbedienbarkeit bis hin zu den sehr eingeschränkten Einstellmöglichkeiten. Diese Dinge haben mich so sehr abgeschreckt, dass ich Gnome 3 erst in Version 3.4 den Augenmerk gegeben habe. KDE 4 schien mir bis dato die deutlich bessere Umgebung zu sein, aber würde sich das in einem Testlauf so bewahrheiten? Auch KDE 4 ist nicht fehlerfrei, es hadert hin und wieder an der ein oder anderen Ecke, dafür stehen gefühlt tausend Konfigurationsmöglichkeiten zur Verfügung, um die Umgebung bis ins kleinste Detail den Vorlieben anzupassen – wenn man denn die Zeit und den Elan dazu hat. In der Praxis sieht das meist anders aus. Klar, die ein oder andere Option schätzt man durchaus, aber selbst ich wandere nicht durch jedes Optionsmenü. Im praktischen Einsatz zählt dann vielmehr, die Alltagsdinge möglichst intuitiv erledigen zu können. Und da springt Gnome 3 ein.
Nach der Installation von Gnome 3 unter Kubuntu (nicht unbedingt ein Widerspruch :-D) hatte ich erst einmal die Gnome Shell vergessen, deren Paket nicht automatisch mit dem Meta-Paket ausgewählt wurde. So musste ich mich nach dem ersten Start von Gnome wieder zu KDE raushangeln, um sie erst noch nach zu installieren. Der erste Start – mit Gnome Shell – sah dann vielversprechend aus. Zwar sind die Konzepte durchweg anders, aber wenn man etwas herumspielt und im Internet stöbert, ist der Anfang schnell gemacht. Neben Gnome 3 habe ich auch gleich Evolution und Empathy eine Chance gegeben und wurde nicht enttäuscht. Ganz im Gegenteil: das ganze wirkt ziemlich konsistent und übersichtlich. Diesen Gesamteindruck hatte ich durchweg bei der Nutzung von Gnome 3. Bzw. habe ich noch, dieser Blogeintrag entsteht momentan unter Gnome 3 – natürlich per Firefox 😉 Die fehlenden Einstellmöglichkeiten fallen zwar durchaus auf, aber fallen nur bedingt ins Gewicht. Ich kann zwar nicht abschätzen, inwiefern sich dies in der Alltagsnutzung niederschlagen würde, aber während des kurzen Testlaufs empfand ich die Schlichtheit eher als Vor- denn als Nachteil.
Das erste Fazit fällt ein wenig überraschend aus. Gnome 3 hat deutlich mehr Potential, als ich dieser Umgebung im Vorfeld zugestanden hätte. KDE 4 kann mehr, ist Windows-ähnlicher, aber auch komplexer. Gnome 3 hat sein eigenes Konzept und dieses wirkt erfreulich frisch. Noch blieb es bei einem kurzen Test, aber eine Fortsetzung ist sicher. Ob Gnome 3 oder KDE 4: in der momentanen Lage kann ich mir eine dauerhafte Nutzung von Linux auf dem Desktop immer besser vorstellen. Windows 8, zieh Dich warm an, diesmal könnte es ernst werden!

Die Sache mit der Schaltsekunde

Eben informierte auch Hetzner (vorbildlich!) über das Problem einer hohen CPU-Auslastung durch die am Wochenende eingefügte Schaltsekunde, die manche Linux Distributionen etwas aus dem Tritt brachte. Bemerkenswert dabei ist, dass dies zu einem Anstieg um einen ganzen Megawatt führte.

Sehr geehrter Herr Stauder,

in der Nacht vom 30.06.2012 auf den 01.07.2012 registrierten unsere internen
Überwachungssysteme einen Anstieg des IT-Stromverbrauchs um etwa ein Megawatt.

Grund für den enormen Anstieg ist die zusätzliche geschaltene Extrasekunde,
(http://www.heise.de/newsticker/meldung/Schaltsekunde-Verlaengertes-Wochenende-1629612.html)
die auf Linux-Rechnern zu dauerhafter CPU-Auslastung führen kann.

Laut heise.de sind diverse Linux-Distributionen davon betroffen. Nähere Infos
finden Sie dazu unter:
http://www.heise.de/newsticker/meldung/Schaltsekunde-Linux-kann-einfrieren-1629683.html

Um die CPU-Auslastung wieder auf ein normales Maß zu reduzieren ist in vielen
Fällen ein Neustart des gesamten Systems notwendig. Im ersten Schritt sollten
Sie dazu einen Soft-Reboot über die Kommandozeile versuchen. Sofern diese
Maßnahme nicht greift, steht Ihnen noch die Möglichkeit eines Hardware-Resets
über die Administrationsoberfläche Robot zur Verfügung. Wählen Sie dazu in der
Administrationsoberfläche den Menüpunkt „Server“ sowie den Reiter „Reset“
des jeweiligen Servers.

Bei Rückfragen stehen wir Ihnen gerne zur Verfügung.

Mit freundlichen Grüßen

Hetzner Online AG
Stuttgarter Str. 1
91710 Gunzenhausen
Tel: 09831 61006-1
Fax: 09831 61006-2
info@hetzner.de
http://www.hetzner.de

Registergericht Ansbach, HRB 3204
Vorstand: Dipl. Ing. (FH) Martin Hetzner
Aufsichtsratsvorsitzende: Diana Rothhan

Mein Server war davon nicht betroffen, auf die Heise Meldung bin ich bereits kurz nach erscheinen aufmerksam geworden. Zwar unterstützt wohl auch chrony in der in Debian Squeeze verwendeten Version  soweit ich das recherchieren konnte Schaltsekunden, allerdings könnte es sein, dass durch die sanftere Angleichung statt einem plötzlichen Sekundenwechsel der Worst Case auf meinem Server ausgeblieben ist. Chrony statt ntpd hat sich in diesem Fall bewährt 🙂

 

Windows 8 – eine spannende Angelegenheit

Die Welt besteht aus zwei Fraktionen. Die eine steht Neuerungen grundsätzlich offen gegenüber, die anderen lehnt sie partout ab. Doch ist die Sache wirklich so einfach? Nein, sicherlich nicht. Bei Windows 8 scheiden sich die Geister nicht ganz grundlos. Ich erinnere mich an Zeiten von Windows Vista, in denen die öffentliche Meinung irgendwie auch auf mich reflektierte und ich gar zum Wechsel zu Linux tendierte. Aber auch damals war nicht alles schlecht. Und so versuche ich nun auch bei Metro einen Mittelweg zu finden, auch wenn ich ehrlich gesagt meine Schwierigkeiten habe, das neue Konzept wirklich auf ganzer Linie begrüßen zu können. Ob Metro und Windows 8 ein Erfolg werden, das liegt nicht in meiner Hand und so lehne ich mich einfach zurück und schaue, was sich tut. Das der Inhalt zählt und sich das Design danach einordnet ist keineswegs ein schlechter Ansatz, im Web funktioniert das ausgesprochen gut. Aber ob das auch auf den Desktop zutrifft? Die Ribbons fand ich persönlich noch wirklich gelungen, bei Metro kann ich die Zweifel, die auch in einem aktuellen c’t Artikel hervorgebracht werden, dagegen absolut nachfühlen: verschmelzen hier zwei Welten (Mobil und Desktop), die so einfach nicht zueinander passen?
Persönlich gesehen werde ich ohne Vorbehalte weiterhin der Android-Schiene treu bleiben, doch wie es zukünftig auf dem Desktop aussehen wird, muss sich zeigen. Ich stelle mich gerne dem neuen Windows 8 und lasse mich überraschen, ohne Vorbehalte. Doch – und das ist völlig unabhängig davon – wird einmal mehr der Blick über den Tellerrand gewagt, denn mittlerweile kann ich mir einen Einsatz von Linux auf dem Desktop-PC wieder etwas mehr vorstellen. Das ist nicht Windows 8 geschuldet, keineswegs, sondern der tollen Entwicklung der KDE 4 Suite.

 

Alle Jahre wieder, kommt das Serverkind

Pünktlich zum 4. Oktober 2011 hat Hetzner kurz nach 0 Uhr die neue Serverreihe online gestellt, die insbesondere beim kleinsten Modell wieder einmal eine spürbare technische Verbesserung brachte. Der Vorabend bis zur Veröffentlichung der neuen Modelle fühlte sich in der Tat wie ein Silvesterabend an, auf den man sehr gespannt entgegenfieberte, um dann auch wirklich kurz vor 0 Uhr am Computer zu sein. Was des einen Apples Pressekonferenz ist, kann beim anderen durchaus auch der Release einer neuen Serverreihe sein 😉 Durchaus pünktlich gingen die Angebote dann auch online und der Nachfolger meines aktuellen Servers war – obwohl ich das eigentlich gar nicht vor hatte – bereits 23 Minuten später geordert. Ganze 3 Minuten dauerte es dann, bis die Zugangsdaten für den neuen Server auch schon eintrudelten. Wahnsinn wie automatisiert das mittlerweile ist. Kurzerhand gerieten die nächsten Stunden dementsprechend zur spontanen Serverwechselnacht. Spontan ist dabei durchaus wörtlich zu nehmen, eigentlich wollte ich die Angebote ursprünglich nur kurz inspizieren, der Freudendrang war dann aber letztendlich zu groß, sodass ich dann in einer Art Harakiri-Aktion ungeprobt den Wechsel vorantrieb. Gewohnterweise stellten sich einige Probleme in den Weg (3 TB HDDs = GPT, udev = eth0 zu eth1 durch das vKVM, grub2), die aber – und das ist nicht immer gewöhnlich – innerhalb der Nachtfrist gelöst werden konnten. Da ich erst Anfang des Jahres den Wechsel auf das aktuelle Squeeze System vorgenommen habe und vor allem den Mailserver schön eingerichtet habe (das ist leider immer wieder jede Menge Arbeit), habe ich bei diesem Serverwechsel einen Umzug per Image bevorzugt. Die Root-Partition des alten Servers wurde so per partimage gesichert und  dann auf eine größere Partition auf dem neuen Server zurückgespielt. Nach einer Vergrößerung des Dateisystems und einigen Anpassungen an das neue System (u.a. IP, UUIDs, usw.) bootete der neue Server nach einigen vKVM Sessions am Ende durch und die Umgebung präsentiert sich nun bis auf die leistungsmäßig bessere Hardware wie auf dem alten System. Der neue Server (Hetzner EX4) verfügt nun über einen Intel i7 2600 4x 3.4 Ghz, 16 GB DDR3 RAM und zwei 3 TB S-ATA 6G Festplatten. Damit dürfte sich die Zeit bis zur nächsten Angebotsaktualisierung locker überbrücken lassen. Auf ein neues, Fuchs! 🙂

Pakete oder Quellen? Pakete und Quellen!

Wären wir gerade beim Thema Essen, würden wir nun eine selbst zubereitende Speise mit einem Fertiggericht vergleichen. Das Thema wäre schnell vom Tisch: meine Single-Kochkünste haben mich selten wirklich überzeugt, bitte ein Fertiggericht!
Wir sprechen aber glücklicherweise nicht vom Essen, sondern – klar – von Linux! Dort gibt zwar noch keine essbaren Fertiggerichte, aber leicht installierbare Software über die Paketverwaltung. Mit wenigen Befehlen sind komplette Softwarebäume installierbar und auch wieder von der Platte. Und wenn sie schon mal auf der Platte landen, hält sie die Paketverwaltung fortan auch in Sachen Sicherheitsaktualisierungen aktuell. Ein regelmäßiges Update reicht aus, um unbeschwert schlafen zu können (okay, viele Anwender schlafen auch ohne Updates beunruhigend gut).
Doch Software kann auch über eine andere Möglichkeit ihren Weg auf das System finden: über die Quellen, eine der Hauptvorteile von Open Source. Allerdings müssen die Quellen – wenn wir nicht gerade auf ein PHP Skript blicken – auch noch zu einem Fertiggericht werden, dazu ist der Kompilierungsvorgang notwendig. Zudem kommt Software meist in Form vieler Komponenten daher, die je nach Bedarf integriert werden können. Oftmals benötigen neben der eigentlichen Software auch deren Komponenten zusätzliche Helfer in Form weiterer Software oder Bibliotheken. Nutzt man eine Paketverwaltung, so ist man fein raus: diese Systeme wissen einfach schon, dass man für das Kochen von Spaghetti Salz benötigt. Wenn man dagegen den manuellen Weg einschlägt und selbst kompiliert, muss man sich die nötigen Zutaten selbst zusammensuchen. Und das ist nicht immer ganz leicht. Ich selbst gehe da schonmal nach dem Trial & Error Verfahren vor: Software kompilieren, Fehler analysieren und auf zusätzliche Zutaten schließen. Dann steht schon das nächste Problem vor der Tür: nun kennen ich zwar die Zutat, weiß aber nicht, in welchem Paket diese Zutat steckt. Da hilft nur eine Recherche im Web oder in der Paketverwaltung selbst. Natürlich wären auch die Zutaten manuell beschaffbar, aber damit heimst man sich einen immensen Aufwand ein, wenn man Großteile des Systems am Schluss manuell pflegen darf. Nachdem das Trial & Error Verfahren einige Male in einer Schleife gelaufen ist, gelange ich dann irgendwann an den Punkt, an dem das ganze kompilierbar ist. Der Rest ist nur noch Dokumentationssache: die nötigen Zutaten und deren Paketfundort wird meistens noch kurz in einer Textdatei oder im privaten Wiki festgehalten. Schließlich möchte man ja nicht bei Systemwechseln wieder auf die Suche gehen (bei Distributionswechseln fängt der Spaß dagegen wieder an..).
Doch wann lohnt sich der Weg über die Paketverwaltung und wann darf man auch mal auf die Quellen zurückgreifen? Es mag manche geben, die gerne grundsätzlich Hand anlegen möchten und Großteile über die Quellen selbst zusammenkompilieren. Doch nicht alle können oder wollen Köche sein. Abends möchte man ja schließlich nach einem langen Arbeitstag auch nicht mehr Stunden in der Küche stehen, so sieht es auch beim eigenen System aus. Ich beziehe einen Großteil meiner Software über die Paketverwaltung und greife nur an jenen Stellen zu den Quellen, an denen mir die neuste Version einer Anwendung oder eine eigene Konfiguration wichtig ist. Dafür habe ich mich in meinem Fall bei Apache, PHP und MySQL entschieden, da ich diese Software für einen Großteil der Dienste und für eigens programmierte Scripte benötige und auch gerne mal auf neue Funktionen zurückgreife. Nützlich ist da auch, dass man sich mit dem Selbstkompilieren etwas genauer mit dem Hintergrund einer Software auseinandersetzt. Dinge wie den Mailserver beziehe ich dagegen gerne über die Paketverwaltung. Da muss es eben nur fluppen, die Konfiguration ist schon komplex genug.
Für die meisten Wünsche reicht die Paketverwaltung also völlig aus. Nur bei häufig verwendeter und individuell eingerichteter Software, über die ich  auch etwas mehr erfahren möchte, greife ich aber auch vereinzelt gerne zu den Quellen. Im Zweifelsfall für die Paketverwaltung.

Der „Fuchs“ geht wieder rum

9 Monate Abstinenz,  zwar keine völlige, aber doch eine ausreichende. Jedenfalls lange genug, um wieder auf das Thema dedizierter Server zu sprechen zu kommen. Nach einem wochenlangen hin und her habe ich dann gestern die vorerst finale Entscheidung gefällt – pro Server. In den nächsten Monaten erhoffe ich mir so im Livebetrieb die Erkenntnis, ob es doch ohne geht – oder ob gerade das mir gefehlt hat. Jedenfalls freue ich mich die Tage, wieder einmal selbst Hand an die Konfiguration anlegen zu dürfen. Der Umzug bleibt bis dahin noch etwas im Hintergrund, bis dahin stehen vorerst Planung und Installation der nötigen Dinge an. Die Möglichkeiten sind nun definitiv wieder größer geworden und mittlerweile entstandene Ideen werden in naher Zukunft sicherlich zumindest ausgetestet werden. Vielleicht war es auch das, was mir gefehlt hat. Nun denn, auf eine neue Zusammenarbeit, Fuchs (der Servername bleibt natürlich derselbe) 😀
In Sachen Hoster hat sich nichts geändert – ich vertraue weiterhin auf einen Hetzner Server, zumal die neuen echt klasse sind. Geworden ist es diesmal ein EQ4 (Core i7 920, 8 GB DDR3 RAM, 2x 750 GB S-ATA II).

Homserver: Fuchs läuft :-)

Am gestrigen Tage war soetwas wie die Geburtsstunde von Fuchs. Nein, kein Tier, sondern ein Server hat seinen Lebensweg begonnen 😉 Ausgestattet mit einem minimalen und frischen Debian Lenny 5.0 System, das erst letzten Samstag erschienen ist sowie einem SSH Server wird nun der Server per Fernzugriff im lokalen LAN seine Dienste verrichten. Und per Putty fühlt es sich tatsächlich wie bei einem dedizierten Server an – wobei er das ja grundsätzlich auch  ist-  abgesehen von der Tatsache, dass er seine Dienste nur noch LAN-lokal anbietet. Möge er lange, lange leben und seine Dienste in Ehren vertreten. Auf eine gute Zusammenarbeit, Fuchs 😀

Fuchs am Werk
Fuchs am Werk