Skip to content

isc-dhcpd, Windows-7-Clients und kein DHCP?

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

Scanner + Drucker = Kopierer: iCopy

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.

Diagramm-Editoren und passende Iconbibliotheken

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:

Demo-Diagramm, erstellt mit yED.

 

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.

Was lange währt ... - Agent 6.0

Seit 1998 ist mein bevorzugter Newsreader für die Newsgroups des Usenets der Forté Agent - damals schon spitze, aber mit lange stagnierender Entwicklung, bis die Rechte an dem Programm 2001 an den ursprünglichen Hersteller zurückgingen und einige neue Versionen erschienen. Bis zur Version 2.0 anno 2004 bin ich den Updates dann auch gefolgt, habe danach aber den Anschluß verloren und krebste seitdem mit einem nunmehr gut 6 Jahre alten (und von der bis zur Version 2.0 im wesentlichen unveränderten Struktur noch deutlich älterem) Programm herum, das nicht nur sehr altbacken wirkte, sondern dessen fehlende Funktionalität mir trotz Unterstützung durch Hamster, Korrnews und Co. zunehmend schmerzhafter bewußt wurde. Zaghafte Versuche mit anderen Clients, aber auch Upgrade-Versuche auf eine aktuellere Version (zuletzt Agent 4.0 anno 2006) habe ich dennoch immer wieder fremdelnd abgebrochen - zu gewöhnt war ich an die Bedienphilosohpie und die in über 10 Jahren in Fleisch und Blut übergegangenen Shortcuts, zu groß erschienen mir die Defizite der Alternativen.

Endlos kann das aber so natürlich nicht weitergehen, und heute war dann der große Tag: ich habe eine aktuelle Agent-Version 6.0 installiert, die Daten aus der alten Version herübergezogen und, soweit ich sehe, alles wieder so eingerichtet, wie ich es haben möchte. Bei dieser Gelegenheit habe ich dann endlich auch mit dem Unsinn des Parallelbetriebs von 2-3 Agent-Instanzen auf mehreren Rechnern aufgehört: auf dem Laptop News und Mails lesen und beantworten, aber - um früher einmal die Installation schlank zu halten - nicht archivieren, sondern löschen, mit einer dazu passenden Ordnerstruktur, auf dem Desktoprechner alles noch einmal herunterladen und zum Archivieren sortieren sah mal wie eine gute Idee aus, führt aber unterm Strich zu einem immensen Aufwand und zugleich dazu, daß man sein Mailarchiv nie da hat, wenn man es mal braucht. Das gilt natürlich insbesondere dann, wenn der betreffende Desktoprechner an einem Ort steht, an dem man nur noch alle paar Wochen vorbeikommt … Ich glaube, insofern jetzt aber eine brauchbare neue Struktur gefunden zu haben. Der Feinschliff kommt dann in den folgenden Tagen und Wochen, immer dann, wenn es hakt. :-)

msysgit mit PLink, Pageant und SSH

Systemeigenschaften -> Erweitert

Was mich bei meiner Nutzung von git unter Windows noch etwas störte war vor allem, daß ich für den Zugriff auf externe Repositories bisher auf TortoiseGit angewiesen war, weil Git on Windows (msysgit) nicht recht zur Kommunikation über SSH bereit war; angeblich wurde nie der passende Schlüssel gefunden, obwohl eigentlich PLink und Pageant aus dem Putty-Paket installiert waren und mit TortoiseGit ihre Arbeit auch prima taten. Die Google-Recherche führte mich dann allerdings zu einem passenden Beitrag, und nach einigem ausprobieren kann ich bestätigen, daß die dort genannte Lösung funktioniert:

  • Git on Windows (msysgit) installieren
  • Putty installieren (soweit erforderlich)
  • Pageant konfigurieren (soweit war ich schon)
  • Umgebungsvariable GIT_SSH auf PLink setzen
  • GitBash und/oder GitGui neu starten (!)

Danach funktionierte die Sache bei mir wunderbar.

Umgebungsvariablen

Die Umgebungsvariable GIT_SSH setzt man unter Windows XP in den "Systemeigenschaften" (Rechtsklick auf "Arbeitsplatz" oder "My Computer" und dann "Eigenschaften") auf der Registerkarte "Erweitert" unter dem Button "Umgebungsvariablen" unter "Systemvariablen". Ein beherzter Klick auf "Neu" fördert ein Eingabefeld zutage, in dem man nunmehr "GIT_SSH" und den kompletten Pfad zur Datei "PLink.exe" - bspw. "C:\Programme\PuTTY\plink.exe" - eingibt. Neustart von msysgit nicht vergessen!

Voilà! Bei mir funktionierte die SSH-Übertragung dann ohne jedes Problem.

Sprachauswahl bei Git on Windows (msysgit)

Wie ich bereits im Februar beschrieben habe, benutze ich unter Windows msysgit bzw. "Git on Windows". Die GUI-Variante ermöglicht die meisten denkbaren Aktionen in sehr bequemer Weise durchzuführen; sie krankt allerdings - aus meiner Sicht - arg an ihrer Übersetzung, die sämtliche Menüeinträge und damit natürlich auch Fachbegriffe umfaßt und manchmal zu Rätselraten führt, was genau gemeint sein mag. "Zweig" ist ja noch klar, "Zusammenführen" für "Merge" auch, aber das "Version" für "Commit" steht erschließt sich nicht sofort. Und Menüpunkte unterhalb von "Zweig" wie "Erstellen", "Umstellen" oder "Zurücksetzen" sind auch alles andere als klar - "Erstellen" ist ohne Frage "Create", aber "Umstellen"? Gut, man kann vielleicht noch darauf kommen, daß das für "Checkout / Switch" steht … aber bedeutet "Zurücksetzen" jetzt "Reset" oder "Rebase"? Usw. usf. … Da wäre doch eine englische Bedienungsoberfläche eine tolle Sache, da weiß man wenigstens, welche Funktion jeweils gemeint ist, und kann die dann ggf. nachschlagen.

Es scheint leider derzeit noch keine Möglichkeit zur manuellen Auswahl einer Sprache zu geben, auch nicht durch Setzen von Environment-Variablen (zumindest hat Google sich insoweit ausgeschwiegen); es wird automatisch auf die Systemsprache abgehoben. Eine Lösung gibt es dennoch - wenn man dafür sorgt, daß die Programme ihre deutschen Sprachdateien nicht mehr finden, fallen sie auf den englischen Default zurück, und das ist ja genau das, was wir wollen. :-)

Die Sprachdateien liegen in %ProgramFiles%\Git\share\git-gui\lib\msgs bzw. %ProgramFiles%\Git\share\gitk\lib\msgs; dort muß jeweils nur die Datei "de.msg" entfernt - oder umbenannt - werden, und alles wird gut (bzw. in diesem Fall englischsprachig). Nach Updates ist dieser Schritt natürlich erneut erforderlich.

Git unter Windows

Bereits Anfang Januar hatte ich von Git berichtet und danach geschildert, wie man Git-Repositories mit gitosis und gitweb, offen wie auch paßwortgeschützt, aufsetzen kann. Seitdem habe ich eine ganze Reihe Projekte in Git-Repositories eingecheckt und gewöhne mich immer mehr an die Arbeit mit Git, zumeist allerdings unter Windows (weil ich auf Laptop wie auch Desktoprechnern unter Windows arbeite).

Dazu verwende ich TortoiseGit, eine Portierung des recht bekannten (und gelobten) TortoiseSVN, und zugleich Git on Windows (msysgit), das ohnehin als Voraussetzung für die Verwendung von TortoiseGit heruntergeladen werden muß. Beide ergänzen sich, wie ich finde, recht gut. TortoiseGit ermöglicht eine einfache Definition des Remote Repository und elegante Lösungen für die Darstellung von Diffs und Merges, ganz zu schweigen von der grafischen Darstellung des Dateistatus im Explorer; die Git-Bash und GitTk aus msysgit hingegen sind m.E. optimal für Branching und (inkrementielle) Commits sowie für die Darstellung der History. Störend allenfalls, daß die Tools teilweise - trotz der einigermaßen großzügigen Ausstattung an Rechenleistung und RAM - arg langsam wirken. Insgesamt aber, wie ich finde, eine sehr bequeme Lösung.

tweetbackcheck