.LNX-WORLD

Ich hatte vor kurzem eine Windows 7 Workstation, welche mit einer alten 16Bit DOS Anwendung direkt auf einen Drucker, welcher per “net use” auf LPT2 gemappt war, drucken sollte (Der Rechner, welche die Freigabe des Druckers zur Verfügung stellt ist ein Windows Server 2008 SBS).

Unter XP lief das noch einwandfrei, unter Windows 7 (Vista haben wir im professionellen Umfeld direkt mal ausgelassen) ging nix mehr. Angeblich keine Berechtigung…

Nach langem suchen, sprich googlen, kam die Lösung -> Das Samba Protokoll ist “schuld”! XP beherrscht nur smb v1, sprich es wurde hier auch nur mit diesem Protokoll gearbeitet. Windows 7 kann nun aber auch smb v2 – ergo kam dies zum Einsatz. Die Version 2 hat aber nicht die Möglichkeit mehr 16Bit Anwendungen diesen Druckvorgang zu erlauben -> Problem!

Lösung: Dem Windows 7 Client manuell sagen, das er nur nach smb v1 benutzen soll, keinesfalls mehr v2.

sc config lanmanworkstation depend= bowser/mrxsmb10/nsi
sc config mrxsmb20 start= disabled

Das SMB v2 kann natürlich auch wieder aktiviert werden. Zur Reaktivierung reichen die beiden nun folgenden Kommandos:

sc config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
sc config mrxsmb20 start= auto

Bitte beachten: Nach dem “=” zeichen MUSS zwingend ein Leerzeichen folgen.
Diese Kommandos am besten wirklich genau so wie sie hier stehen eingeben, sonst gibt es Murks!

Viel Erfolg beim Drucken aus DOS!

P.S. Man kann nun auch ganz einfach Verzeichnislistings etc. auf den Drucker umleiten:

dir > lpt2

Netzwerklastenausgleich-Dienst konnte nicht gestartet werden
Diesen Fehler hatte ich gerade in den letzten Tagen vor der Nase. Allerdings nicht auf einem Windows Server 2000 System, sondern auf einem Windows 2003 Server! Nach dem Systemstart kam die Meldung das ein Dienst nicht gestartet werden konnte, im Ereignisprotokoll stand eben diese Fehlermeldung: “Der Dienst “Netzwerklastenausgleich” wurde aufgrund folgenden Fehlers nicht gestartet”

Ereignis-ID: 7000
Quelle: Dienststeuerungs-Manager
Beschreibung: Der Dienst "Netzwerklastenausgleich" wurde aufgrund folgenden Fehlers nicht gestartet:
Der angegebene Dienst kann nicht gestartet werden. Er ist deaktiviert oder nicht mit aktivierten Geräten verbunden.
"Netzwerklastenausgleich" ist auf diesem Computer nicht installiert.

Dabei ist auf dem Server garkein Netzwerklastenausgleich installiert oder aktiviert! Wenn man nach diesem Problem googelt, stößt man mit etwas Glück auf den unten stehenden Artikel aus der Microsoft Knowledge Database, welcher diese Fehler beschreibt, sich jedoch auf Windows Server 2000 bezieht. Es passt jedoch auf den Windows Server 2003, denn genau dort stritt exakt der gleiche Fehler auf.

Die Lösung besteht darin, das man einfach zwei Registry Einträge löschen muß:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\System\WLBS
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WLBS

Als .reg Datei schaut der Vorgang dann so aus:

1
2
3

Windows Registry Editor Version 5.00
[-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\System\WLBS]
[-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WLBS]

Weblink:
Microsoft Knowledge Database

[aartikel]B001H30QNU:left[/aartikel]
SSH absichern – ich sagte es schon in Teil 1 dieser Reihe – dies ist etwas, dass jeder der Linux Server betreibt (egal ob in einem Firmennetzwerk, direkt über das Web erreichbar, oder beides) mit als erstes in den Angriff nehmen sollte.

In diesem Teil 2 der Reihe “SSH absichern” gehe ich auf einen Punkt ein, welcher oftmals schlicht unterschätzt wird: Den SSH Port ändern! Wenn man im Mittelalter nicht wollte, dass jemand einen Schatz fand, bzw. einen geheimen Ort, dann wurde dieser versteckt. Genauso funktioniert das gute alte Kinderspiel des Versteckens.

Was damals funktionierte, tut auch heute noch seine Wirkung! Denn beim den simplen Portscans auf offene SSH Zugänge wird meist nur nach dem default Port von SSH gesucht, dem Port 22. Was nun wenn der Server bei Anfragen auf den SSH Port 22 ganz simpel nicht antwortet? Meist fliegt man aus der Liste der Server die per Script und Brute Force angegriffen werden sollen, zumindest ist dies mein Ergebniss aus den Erfahrungen der Vergangenheit. Mehr…

[aartikel]3897215233:left[/aartikel]
SSH absichern – dies ist etwas was jeder der Linux Server betreibt (egal ob in einem Firmennetzwerk, direkt über das Web erreichbar, oder beides) mit als erstes in den Angriff nehmen sollte. Linux hat einen Nachteil was Angriffe angeht: Der Benutzer auf den es alle zuerst abgesehen haben ist root und der heißt nunmal immer so.

Um root den direkten Login per SSH zu verbieten, muss nur eine Zeile in der /etc/ssh/sshd_config geändert werden:

PermitRootLogin yes
ändern zu
PermitRootLogin no

Diese Änderung in der SSH Konfiguration sorgt dafür das der direkte Login über SSH als Benutzer root untersagt wird, sprich unser SSH ist ein wenig mehr abgesichert. Mehr…

Über die letzten Wochenenden wollte ich prüfen, ob auch brav alle meine betreuten Server brav automatisch neu gestartet sind – am leichtestem fiel mir als Linuxianer das freilich mittels “uptime”.  Leider gibt es diesen befehl unter Windows nicht (mehr). Aber es gibt alternative Befehle:

net stats srv
net statistics server

Beide machen im Grunde exakt das Gleiche, der Zweite ist nur etwas länger – was uns Schreibfaulen also quasi gleich nur Befehl 1 benutzen lässt. In einer der oberen Zeilen bei der Befehlsausgabe (Output) steht je nach Sprache des Betriebssystems “Statistics since” oder “Statistik seit” – die Zeit und Datumsangabe dahinter ist der Zeitpunkt als Windows das letzte Mal erfolgreich gestartet war. Zwar hat man keine schöne Unixtimestamp Angabe der “Uptime” in Sekunden, aber immerhin konnte ich mit diesen Angaben exakt das herausfinden was ich wissen wollte!