Springe zum Inhalt

Monat: Dezember 2008

Veröffentlicht am

Wenn man den DHCP-Clients zusätzlich zum default Gateway auch noch andere Routen mitteilen möchte, kann man die DHCP-Option, welche in RFC3442 definiert ist, nutzen. Zuerst einmal ist eine neue Option für den dhcpd zu definieren:

option rfc3442-classless-static-routes code 121 = array of integer 8;

Die eigentliche zusätzliche Route kann man dann wie folgt definieren:

option rfc3442-classless-static-routes 24, 192, 168, 47, 192, 168, 47, 25;

Dabei bedeuten:

24
Länge der nachfolgenden Subnetzmaske in Bits
192, 168, 47
die signifikanten Bytes der Subnetzmaske
192, 168, 47, 25
das Gateway für das vorher angegebene Subnetz

Mit dem obigen Beispiel wird also eine Route für das Subnetz 192.168.47.0/24 über das Gateway 192.168.47.25 festgelegt. Soweit mir bekannt ist, wird dieses Verfahren vom Microsoft DHCP-Client unter Windows XP und Vista unterstützt.

Veröffentlicht am

Mit der Einführung von DNSSEC für verschiedene TLDs haben sich die Erfordernisse an die eingesetzte Firewall-Software erhöht. Da gleichzeitig im BIND9 die DNSSEC-Abfrage per Default eingeschaltet wurde, sollte getestet werden, ob die Firewall-Software für EDNS0-Anfragen richtig funktioniert. Hinweise für eine nicht richtig funktionierende EDNS0-Anfrage liefert eine BIND9-Meldung wie z.B.:

too many timeouts resolving 'ze.akamaitech.net/AAAA' (in 'akamaitech.net'?): disabling EDNS

EDNS0-Anfragen passen oft nicht in die (alten) UDP-Pakete mit einer Länge von 512 Bytes. Mit

dig +norec +dnssec example.com @a.root-servers.net

kann getestet werden, ob die Firewall UDP-Pakete mit einer Länge größer als 512 Bytes durchlässt. Mit

dig +dnssec +norec +ignore dnskey se @A.NS.se

kann getestet werden, ob IP Fragmente für UDP unterstützt werden.

Veröffentlicht am

Linux kennt für dieses Problem das Kommando "which". Unter Windows existiert solch ein Kommando leider nicht, kann aber leicht CMD-Mitteln nachgestellt werden.

Läuft ab Windows XP:

 @for %%e in (%PATHEXT%) do @for %%i in (%1%%e) do @if NOT "%%~$PATH:i"=="" echo %%~$PATH:i

Einfach im Pfad als z.B. which.bat speichern.

Quelle

Veröffentlicht am

Beim Absturz von NT-artigen Windows wird eine Speicherabbilddatei unter C:\WINDOWS\Minidump erstellt. Diese kann mit den durch Microsoft zur Verfügung gestellten Debugging Tools for Windows gelesen und analysiert werden.

Der Knowledgebase-Artikel 315263 beschreibt die Vorgehensweise ausführlich.

Laden der Symbole vom Microsoft-Symbolserver:

windbg.exe -y srv*c:\symbols*http://msdl.microsoft.com/download/symbols -i c:\windows\i386 -z c:\windows\minidump\minidumpXXXX.dmp

Vorraussetzung dafür ist, das der Inhalt des Ordners I386 von der Windows-Installations-CD in den Ordner C:\WINDOWS\I386 kopiert wurde.

Veröffentlicht am

Auf einer .NET-Informationsveranstaltung habe ich den Begriff DLL-Hell aufgeschnappt. Hier wollte die .NET-Entwicklungsumgebung eigentlich neue Maßstäbe setzen und die DLL-Flut weitgehend verhindern. Fakt ist jedoch, daß aus jedem einzelnen .NET-Projekt eine eigene Assembly (als DLL- oder EXE-Datei) resultiert. Das fehlende Utility ist ILMerge. Mit diesem Utility kann man die einzelnen zum Projekt hinzugehörenden DLL-Dateien in eine einzige Assembly verpacken.

ILMerge is a utility that can be used to merge multiple .NET assemblies into a single assembly. ILMerge takes a set of input assemblies and merges them into one target assembly. The first assembly in the list of input assemblies is the primary assembly. When the primary assembly is an executable, then the target assembly is created as an executable with the same entry point as the primary assembly. Also, if the primary assembly has a strong name, and a .snk file is provided, then the target assembly is re-signed with the specified key so that it also has a strong name.

ILMerge is packaged as a console application. But all of its functionality is also available programmatically. Note that Visual Studio 2005 does allow one to add an executable as a reference, so you can write a C# client that uses ILMerge as a library. If you are using Visual Studio 2003, you must use the v1.1 version of ILMerge and rename it to be a dll in order to use it as a reference.

There are several options that control the behavior of ILMerge. See the documentation that comes with the tool for details.

The v2.0 version of ILMerge runs in the v2.0 .NET Runtime, but it is also able to merge v1 or v1.1 assemblies. However it can merge PDB files only for v2 assemblies. The v1.1 version of ILMerge can only process assemblies built in the v1.1 runtime (but does merge PDB files for those assemblies).

Currently, ILMerge works only on Windows-based platforms. It does not yet support Rotor or Mono. It runs in the v2.0 .NET Runtime, but is also able to merge v1 or v1.1 assemblies. Quelle

Links: