Windows Key im Bios

Diese Ansicht hat fast ausgediehnt

Wir setzen bei unseren Lösungen für das Hosting zwar primär auf Open Source und Linux, aber ab und zu wird doch mal ein Windows Server für einen Kunden benötigt. Und da es seit einiger Zeit Änderungen an der Lizenz oder Install-Medium Mitgabe gab, wollen wir mit diesem Post auf die Besonderheiten in diesem Fall eingehen.

In den betreffenden Fällen (meist OEM Server) wird der Key im Bios hinterlegt und von Windows direkt ausgelesen. Gedanklich klingt dies alles gut und erspart sicher auch einigen Aufwand. Wer solch ein System aber besitzt, wird beim ersten Start und der Grundinstallation dann höflich auf die Generierung eines Recover-Mediums hingewiesen. Da man nicht ohne weiteres an den Key heran kommt oder im Fehlerfall keine CD/DVD mehr hat, raten wir jedem Nutzer/Admin dazu, diese Recover-Medien direkt nach der Grundinstallation anzulegen. Einige Vertreiber bestehen sogar darauf, bevor man das System nutzen kann.

Es sollte aber auch nicht vergessen werden, die Medien von Zeit zu Zeit einmal zu erneuern. Anhand der Größe wird oft ein USB Stick genutzt, und diese können ja auch mal Fehler haben. Soviel dazu für heute. Mögen Euch spätere Probleme damit erspart werden.

Ronny Biering

Autor: Ronny Biering

Vor NETWAYS arbeitete Ronny bei einem der großen deutschen Internet- und Hosting Provider. Hier betreut er zusammen mit seinen Kollegen aus dem Bereich Managed Services die Plattformen unserer Kunden. Im Gegensatz zu dem üblichen Admin-Cliche, gehört Fitness zu einer seiner Lieblingsfreizeitbeschäftigung.

Windows und Remote Verbindungen – die 2.

windows-mac-or-linuxVor langer, langer Zeit (zumindest im IT Wesen), hatte ich einmal über die Verwaltung verschiedener Remote Verbindungen unter Windows geschrieben und Achim hat im Gegenzug eine Erklärung für Linux zusammengetragen. Seit dem hat sich einiges geändert und es gibt auch immer was neues, aber im Bereich der Verbindungs-Verwaltung scheint der Trend zu stagnieren. Der Fork mRemoteNG oder Tools wie Terminals scheinen einen Punkt erreicht zu haben, wo alle Bedürfnisse erreicht sind. Letzte Aktivitäten/Updates sind zumindest länger her, aber sie laufen ohne Probleme. Alternativen unter Windows per SSH lassen sich z.B. via PowerShell derzeit realisieren, falls jemand nativ in der PS unterwegs ist.

Man muss und kann also gespannt in die Zukunft schauen und evtl. sogar hoffen, dass sich irgend wann einmal ein Protokoll auf allen Systemen durchsetzt. SSH z.B. kommt unter Windows auch immer stärker zum Einsatz und wäre ein Kandidat hierfür, lassen wir uns überraschen.

Ronny Biering

Autor: Ronny Biering

Vor NETWAYS arbeitete Ronny bei einem der großen deutschen Internet- und Hosting Provider. Hier betreut er zusammen mit seinen Kollegen aus dem Bereich Managed Services die Plattformen unserer Kunden. Im Gegensatz zu dem üblichen Admin-Cliche, gehört Fitness zu einer seiner Lieblingsfreizeitbeschäftigung.

Never ending Spam

nospamHeute halten wir uns schlicht und einfach und möchten die Allgemeinheit und die IT-Welt mal wieder vor den ganzen Spam-Wellen warnen. Derzeit kommen diese mit ZIP Files in unterschiedlichsten Zusammenhängen.

Beispiele sind Nachrichten von Ihrer freundlichen Apotheke, der Post/DHL wegen einer Sendung, dem Telefonbetreiber zwecks Rechnung oder Kündigung oder dem Klassiker der Bank. Wer bei seinem Filter Zip als Anhang durchlässt wird es aber auch schwer haben diese Spams derzeit zu filtern. Wieder ein Grund mehr ZIPs nicht als Anhang zuzulassen, E-Mails sind nicht zum File-Transfer entworfen worden 🙂

Es gibt sicher eine Person im Kreis der Verwandten von jedem, wo man sicher ist, das dieser derartige Nachrichten samt Anhang öffnet. Hier kann man nur noch einmal warnen, das z.B. die o.g. Absender einem nicht ohne weiteres eine Mail mit dubiosem Anhang schicken.

Daher bitte weitersagen, das man vor dem öffnen der Anhänge erst einmal die Nachrichten genau prüfen soll. Bin ich überhaupt Kunde, hat der Absender eigentlich die Adresse, wird man direkt angesprochen (Name, Vorname).

Und wer Hilfe bei Setup seines Mailservers braucht kann gern auf unsere Unterstützung zurückgreifen oder den Service direkt bei uns nutzen.

Ronny Biering

Autor: Ronny Biering

Vor NETWAYS arbeitete Ronny bei einem der großen deutschen Internet- und Hosting Provider. Hier betreut er zusammen mit seinen Kollegen aus dem Bereich Managed Services die Plattformen unserer Kunden. Im Gegensatz zu dem üblichen Admin-Cliche, gehört Fitness zu einer seiner Lieblingsfreizeitbeschäftigung.

Tools und ihre Begeisterung

AmbitionsbarometerHeute möchte ich mal einen kleinen Rückblick über die von uns genutzten Tools geben und wie der Enthusiasmus sich im laufe der Zeit geändert hat. Denn wer kennt es nicht, kaum gibt es ein neues Tool oder eine Erweiterung und schon denkt man sich “Man, das hätte ich schon immer gebrauchen können. Warum erst jetzt?” oder anders gesagt “Cool” 🙂 Und schon beginnen dann auch die ersten Tests, man setzt sich damit auseinander und versucht den Rest der Belegschaft davon zu überzeugen es auch zu mögen.

Als kleines Beispiel einmal die Tätigkeit des Admins die Server und deren Logs zu prüfen. Fangen wir damit an einzelne Logs zu prüfen und ggf. mit eigenen Checks auf bestimmte Inhalte zu prüfen. Das ganze kommt dann in der nächsten Stufe per Remote-Log schon mal auf einen zentralen Server, wo dies leichter ‘durchgegrast’ werden kann. Immer wieder denkt man sich “Ja, so geht es besser”, aber in der heutigen Zeit steht am Ende ELK und ist wohl auch noch auf längere Sicht das muss dafür.

Oder die Installation und Pflege der Systeme. Ich denke das ‘golden image’ den meisten ein Begriff ist und er durchaus auch heute noch seine Berechtigung hat. Aufgesetzt dazu konnte man mit Verwaltungen wie ClusterShell und Updian schon mal etwas weiter kommen und sich die Arbeit erleichtern. Einen Schub bekam das ganze dann mit Automatisierungen wie Puppet und aktuell lernen die Server mit OpenNebula und Foreman schon das laufen und überrennen uns bald 😀

Kurzum, im Laufe der Zeit wird sich das Barometer der Begeisterung zu den genutzten Tools immer wieder ändern, das hängt von den Anforderungen und Innovationen im Netz ab. Aber es ist interessant sich mal den Wandel dann rückwirkend anzuschauen.

Ronny Biering

Autor: Ronny Biering

Vor NETWAYS arbeitete Ronny bei einem der großen deutschen Internet- und Hosting Provider. Hier betreut er zusammen mit seinen Kollegen aus dem Bereich Managed Services die Plattformen unserer Kunden. Im Gegensatz zu dem üblichen Admin-Cliche, gehört Fitness zu einer seiner Lieblingsfreizeitbeschäftigung.

SSH-Agent Forward und Screen

Ich glaube, dass wir Screen und SSH Agent Forwarding nicht weiter im Detail selbst besprechen müssen, aber mit diesem Post möchten wir auf ein Problem hinweisen, welches beim Einsatz von beidem zusammen aufkommt. Hintergrund ist folgender: SSH legt beim Connect mehrere ENV-Variablen an, welche auch den AUTH_SOCK enthalten. Dies ist ein Socket, der für die Kommunikation mit dem lokalen Agent verantwortlich ist und somit die Weiterleitung der Keys ermöglicht.

Unglücklicherweise werden diese EVN Informationen nur beim Start der Screen Session eingelesen, d.h. wenn man sich detached und dann mit einer neuen Verbindung wieder einhängt, enthält die Variable immer noch den alten Pfad, welche dann nicht mehr aktuell ist ( z.B. /tmp/ssh-hYQhk6Nrhq/agent.32462 ). Somit würde eine Verbindung innerhalb vom Screen zu einem Server dann keine Key Authentifizierung mehr durchführen und ein Passwort verlangen, was im ersten Moment dann sehr verwirrend ist.

Man kann sich aber mit einem kleinen Tricken helfen, welcher diesen Socket auf einen generischen Pfad legt. Dazu erstellt man sich eine SSH-RC Datei, die bei jeder Verbindung ausgeführt wird. ( SSH1 ~/.ssh/.rc | SSH2 ~/.ssh/rc )

#!/bin/bash
if test "$SSH_AUTH_SOCK" ; then
    ln -sf $SSH_AUTH_SOCK ~/.ssh/ssh_auth_sock
fi

Somit wird ein Link zum jeweiligen Pfad des Socket erstellt, welcher bei jeder Anmeldung dann auch überschrieben wird. Schon haben wir einen festen Namen. Nun geht es nur noch darum, diesen Pfad auch im Screen mit anzuziehen. Dazu erstellt/ändert man nur die .screenrc im Home-Verzeichnis wie folgt:

setenv SSH_AUTH_SOCK $HOME/.ssh/ssh_auth_sock

Als letztes muss die Screen Sitzung nur noch einmal neu gestartet werden, damit die Einstellung greift. Und schon wird bei jeder Neueinwahl auf den Server und ins Screen die korrekte Verbindung zum lokalen SSH Agent hergestellt.

Ronny Biering

Autor: Ronny Biering

Vor NETWAYS arbeitete Ronny bei einem der großen deutschen Internet- und Hosting Provider. Hier betreut er zusammen mit seinen Kollegen aus dem Bereich Managed Services die Plattformen unserer Kunden. Im Gegensatz zu dem üblichen Admin-Cliche, gehört Fitness zu einer seiner Lieblingsfreizeitbeschäftigung.