| # bits | # hosts | Usable hosts |
netmask | Cisco mask | |
|---|---|---|---|---|---|
| /4 | 268435456 | 268435454 | 240.0.0.0 | 15.255.255.255 | |
| /5 | 134217728 | 134217726 | 248.0.0.0 | 7.255.255.255 | |
| /6 | 67108864 | 67108862 | 252.0.0.0 | 3.255.255.255 | |
| /7 | 33554432 | 33554430 | 254.0.0.0 | 1.255.255.255 | |
| /8 | 16777216 | 16777214 | 255.0.0.0 | class A network | 0.255.255.255 |
| /9 | 8388608 | 8388606 | 255.128.0.0 | 0.127.255.255 | |
| /10 | 4194304 | 4194302 | 255.192.0.0 | 0.63.255.255 | |
| /11 | 2097152 | 2097150 | 255.224.0.0 | 0.31.255.255 | |
| /12 | 1048576 | 1048574 | 255.240.0.0 | 0.15.255.255 | |
| /13 | 524288 | 524286 | 255.248.0.0 | 0.7.255.255 | |
| /14 | 262144 | 262142 | 255.252.0.0 | 0.3.255.255 | |
| /15 | 131072 | 131070 | 255.254.0.0 | 0.1.255.255 | |
| /16 | 65536 | 65534 | 255.255.0.0 | class B network | 0.0.255.255 |
| /17 | 32768 | 32766 | 255.255.128.0 | 0.0.127.255 | |
| /18 | 16384 | 16382 | 255.255.192.0 | 0.0.63.255 | |
| /19 | 8192 | 8190 | 255.255.224.0 | 0.0.31.255 | |
| /20 | 4096 | 4094 | 255.255.240.0 | 0.0.15.255 | |
| /21 | 2048 | 2046 | 255.255.248.0 | 0.0.7.255 | |
| /22 | 1024 | 1022 | 255.255.252.0 | 0.0.3.255 | |
| /23 | 512 | 510 | 255.255.254.0 | 0.0.1.255 | |
| /24 | 256 | 254 | 255.255.255.0 | class C network | 0.0.0.255 |
| /25 | 128 | 126 | 255.255.255.128 | 0.0.0.127 | |
| /26 | 64 | 62 | 255.255.255.192 | 0.0.0.63 | |
| /27 | 32 | 30 | 255.255.255.224 | 0.0.0.31 | |
| /28 | 16 | 14 | 255.255.255.240 | 0.0.0.15 | |
| /29 | 8 | 6 | 255.255.255.248 | 0.0.0.7 | |
| /30 | 4 | 2 | 255.255.255.252 | 0.0.0.3 | |
| /31 | point to point links only | ||||
| /32 | 1 | 1 | 255.255.255.255 | single IP address | use host notation |
Netmask Quick Reference
“net use” mit öffentlicher Freigabe
Wie man mit net use unter Windows umgeht, glaubte ich zu wissen… bis ich vor dem Problem stand, wie man denn eine (öffentliche) Freigabe einbindet, die keinen Benutzer/Passwort erfordert. Kurz und schmerzlos:
net use Z: \\server.domain\share /u:"" ""
Als Benutzername und Passwort übergibt man jeweils zwei Gänsefüßchen ohne Inhalt.
schneller packen mit pbzip2
Wenn man viel mit tar cvjf arbeitet, und das auf einem Rechner mit mehreren Kernen, dann ärgert man sich schnell über das fehlende Multithreading der zugrunde liegenden bzip2-Implementation. Da gibt es glücklicherweise Abhilfe: pbzip2 behebt genau diesen Misstand. Aber wie integriert man das vernünftig in seinen täglichen Arbeitsablauf? Da gibt es viele verschiedene Wege, ich habe mich für ein eigenes kleines Skript entschieden (ich schreib eh zu wenig Skripte
)
#!/bin/bash
#---[functions]---------------------------------
compress()
{
# check if two arguments have been supplied
if [[ -n "$1" && -n "$2" ]]; then
# yes, we're good to go
tar cv $1 | pbzip2 -m500 -c > $2.tar.bz2
fi
}
uncompress()
{
# check if one argument has been supplied
if [[ -n "$1" ]]; then
# yes, we're good to go
pbzip2 -m500 -d -c $1 | tar xv
fi
}
#---[main]--------------------------------------
# are the last 6 characters of my name "unpack"?
if [ ${0:${#0}-6} = "unpack" ]; then
uncompress $1
# are the last 4 characters of my name "pack"?
elif [ ${0:${#0}-4} = "pack" ]; then
compress $1 $2
else
echo "Something is wrong! My name is neither \"unpack\" nor \"pack\""
fi
Was passiert hier? Das Skript prüft zuerst, ob sein Name auf “pack” oder auf “unpack” endet. Anhand dessen wird unterschieden, ob die Funktion zum Packen oder die zum Entpacken aufgerufen wird. Das hat den Vorteil, dass ich nur ein einziges Skript brauche, welches alle Funktionen bündelt. Um auf die verschiedenen Funktionen zuzugreifen speichere ich es mit dem Namen “pack” ab und lege anschliessend einen Symlink namens “unpack” an, der auf “pack” zeigt – voilà!
Aufruf:
pack [Datenquelle] [Archivname (ohne .tar.bz2!)] unpack [Archivname.tar.bz2]
Mal abseits davon, dass ich zu wenig Skripte schreibe (und damit meine Bash-Kenntnisse schnell einrosten), gab es auch einen wirklichen Grund, der für ein Skript und gegen die Verwendung von z.B. zusätzlichen Optionen bei tar sprach, mit denen man dort ja auch direkt einen alternativen Packer angeben kann: man kann dort eben nur das Programm angeben, aber keine zusätzlichen Optionen für das Packprogramm, die ich aber brauchte (siehe den Hinweis zu Hyperthreading im folgenden).
Folgende Dinge sollte man über pbzip2 wissen:
CRONTAB: Kleines How-To
Um einen zeitgesteuerten Aufruf / Start eines Scriptes oder Programmes unter Linux auszulösen (unter Linux heisst dies dann cronjob), bedeint man sich der Crontab (so heißt im übrigen auch das Programm welches diese Crontabeinträge nachher abarbeitet). Jeder User hat so eine, mit die Wichtigste ist jene, welche sich unter /etc/crontab befindet. Hier schreibe ich fast alle Cronjob´s rein die auf meinem System laufen sollen, also genau solche Jobs wie SQL Datenbankdumps, Datensicherungen, Dienstneustarts, Benachrichtigungsscripts über Systemupdates, etc.
# m h dom mon dow user command 17 * * * * root /usr/local/cronjob1.sh 25 6 * * * root /usr/local/cronjob2.sh
Oben habe ich mal die ersten 3 Zeilen aus meiner Crontab eingestellt… Wie man erkennen kann, teil sich jeder Eintrag / Cronjob für eine Aufgabe in viele Spalten. In dem erstem 5 Spaltigen Bereich, welcher die Zeiten steuert, zu denen der Cronjob ausgeführt werden soll, stehen zuerst die Minute(n), dann die Stunde(n), der Tag, der Monat und der Wochentag. In der nächsten Spalte steht der Benutzer unter dem der Cronjob ausgeführt werden soll, gefolgt von dem Aufruf des zu startenden Programmes inklusive aller Optionen.
Die Crontab eines normalen Benutzers sieht etwas anders aus
# m h dom mon dow command 17 * * * * /usr/local/meinscript --optionen
Quasi das Gleiche, jedoch ohne die Spalte vom Benutzer / User, da normale Benutzer nur unter ihrem eigenem Namen Cronjob´s starten dürfen. Auch editiert der Benutzer seine Crontab nicht mit der /etc/crontab, sondern mit dem Kommando “crontab -e”. Ansehen kann man sich seine Cronjob´s mittels “crontab -l”. Dieser Weg ist dem meinem auch eindeutig zu bevorzugen!
Um diesen doch sehr gewöhnungsbedürftigen Sytax mal zu erklären, ein paar Beispiele dazu:
Um ein Script zum Beispiel jede Minute auszuführen müsste der Cronjob wie folgt aussehen:
* * * * * /usr/local/meinscript --optionen
Wenn das Script alle 15 Minuten laufen soll, also zu jeder 15ten Minute und jeder Stunde, sähe der Cronjob so aus:
*/15 * * * * /usr/local/meinscript --optionen
Cronjob für ein Script welches genau jeden morgen um 06:00 Uhr ausgeführt werden soll:
0 6 * * * /usr/local/meinscript --optionen
Cronjob um ein Script jeden morgen zwischen 6 Uhr und 9 Uhr alle 15 Minuten zu starten:
*/15 6-9 * * * /usr/local/meinscript --optionen
Cronjob f+r ein Script das genau am Heiligabend um 18 Uhr laufen soll:
0 18 24 12 * /usr/local/meinscript --optionen
Cronjob für ein Scriptdas welches jeden Montag morgen laufen soll:
* * * * 1 /usr/local/meinscript --optionen
Beim letztem Beispiel wird der Wochentag als Zahl angegeben. Gültig hierfür sind die Zahlen 0-7, wobei die 0 und die 7 für den Sonntag stehen
Disable Email:
Standardmäßig sendet ein Cron-Job eine Email nach Ausführung des Cronjobs. Ist dies nicht erforderlich Setzen Sie folgenden Befehl an das Ende der Cron- Job Zeile
>/dev/null 2>&1
Alte Kernel inkl. Header mit nur einem Befehl entfernen
Unter Ubuntu kann ein alter Kernel inkl. Header mit folgendem Befehl entfernt werden. dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d' | xargs sudo apt-get -y purge
von Lenny zu Squeeze: Samba und Snow Leopard
Beim Wechsel von Lenny zu Squeeze konnte ich anschliessend mit Snow Leopard (aktuell: 10.6.2) nicht mehr auf meine Samba-Freigaben zugreifen. Der berühmte erste Gedanke “Aber ich hab doch garnichts geändert…?” schlich sich ins Bewußtsein… ähem, na gut, zumindest nichts an der Konfiguration
. Ich hatte meine alte Konfigurationsdatei gesichert und auch testparm zeigte sich nach wie vor zufrieden damit. So war es dann an der Zeit, den Browser anzuschmeissen…
Eine kurze Recherche förderte zu Tage, dass Snow Leopard (im Gegensatz zu seinen Vorgängern) auf Passwortverschlüsselung besteht, was standardmässig in Samba nicht eingeschaltet ist und schon viele Snow Leopard-Umsteiger geärgert hat. Das alleine kann ich als Ursache aber nicht gelten lassen, schliesslich konnte ich bis gestern problemlos von Snow Leopard auf die Freigaben des Servers zugreifen – ganz ohne Verschlüsselung. Hier wird wohl eher eine Kombination aus Snow Leopard und Samba-Version für das Problem verantwortlich zeichnen.
Aber alles halb so wild, es gibt ja Abhilfe:
encrypt passwords = yesin die[global]-Sektion dersmb.confaufnehmen- mittels
smbpasswddas Passwort der Freigabe neu setzen
Anschliessend wollte der Schneeleopard wieder mit dem Pinguin spielen.
Windows 7 vom USB-Stick installieren
Microsoft bietet ein Tool an, mit dem man einen (entsprechend großen) USB-Stick in ein Windows 7-Installationsmedium verwandeln kann. Eine praktische Sache – aber wer aus seiner eigenen Windows 7 Installations-DVD ein ISO erzeugt, bekommt von dem Tool womöglich die Fehlermeldung “The selected file is not a valid ISO file. Please select a valid ISO file and try again.” präsentiert.
Ob dieses Problem auftritt oder nicht, liegt wohl daran, wie man das ISO erzeugt hat. Wer es wie ich einfach mit dd if=/dev/foo of=bar.iso erzeugt hat, wird vor diesem Problem stehen. Die technische Erklärung dafür hat mit dem internen Aufbau des ISOs zu tun und kann bei Rafael’s Within Windows nachgelesen werden. Dort gibt es auch gleich ein Tool, um das ISO so zu modifizieren, dass es vom MS-Tool “gefressen” wird.
Die nächste Hürde ist dann die, dass das MS-Tool die Datei bootsect.exe aus dem angegebenen ISO verwendet, um den USB-Stick bootbar zu machen. Wer jetzt unter einem 32bit-Windows einen Stick für ein 64bit-Windows präparieren möchte, steht jetzt schon wieder auf dem Schlauch. Abhilfe schafft hier nur die entsprechende 32bit-Version, die man aber leider nicht bei Microsoft herunterladen kann. Diese muss man stattdessem einer 32bit-Installations-DVD entnehmen, die man hoffentlich auch noch zur Verfügung hat. Anschliessend kopiert man diese Version dann ins Installationsverzeichnis des MS-Tools, wo sie fortan automatisch gefunden und benutzt wird.
Rsync über SSH-Tunnel auf einen nicht Standartport
Viele SSH-Server, verwenden inzwischen nicht mehr Port 22 als Standartport sondern, arbeiten auf einem verbogenen Port.
Da sich der Befehl Rsync idealer weise für Backups anbietet, aber selbst nicht die Möglichkeit, einen anderen SSH-Port anzugeben. Rsync bietet zwar eine Option zur Veränderung des Ports an, diese bezieht sich ausschließlich auf den Rsync-Server.
Mit diesem Trick, kann Rsync über SSH auf einem anderen Port konektieren.
rsync -avze 'ssh -p abcd' Username@entfernterSSHServer:/entfertner/pfad/auf/quell/server/ /pfad/ziel
Dabei steht abcd für den entsprechenden Port (z.B. 1234, anstatt 22 ). Der Prot wird entsprechend in der Datei /etc/sshd/sshd.conf eingestellt. Ob der SSH-Server die Quelle oder das Ziel ist spielt keine Rolle. In diesem Beispiel wird von einem SSH-Server auf ein lokales Verzeichnis kopiert. Die Rsync-Parameter sind bis auf -e austauschbar. Dabei muss -e als letzter Parameter vor ssh -p abcd stehen.
Wenn die SSH Anmeldung hängt …
Verbindet man sich per SSH mit einem Server macht dieser eine reverse DNS Abfrage um den Hostnamen zu der IP aufzulösen von der aus man sich verbindet.
Dies kann bei DNS Problemen oder bei vermehrten Traffic unter Umständen dafür sorgen, dass die SSH Verbindung ein paar Sekunden einfriert. Diese Reverse DNS Abfrage lässt sich jedoch in der /etc/ssh/sshd_config deaktivieren. Dazu muss folgender Eintrag in der Datein hinzugefügt werden.
UseDNS=no
Eine weitere Ursache kann auch ein ungültiger Eintrag in resolv.conf (reverse DNS-lookup) sein.
Unter Solaris sollten folgende Einträge in der /etc/ssh/sshd_config helfen.
LookupClientHostnames noVerifyReverseMapping no
Inkscape: copy & paste
Inkscape, derzeit in Version 0.47, gehört zu meinem Standard-Softwarerepertoire, auch wenn ich es nur selten brauche. Jetzt war es seit längerem mal wieder soweit und ich musste verwundert feststellen, dass auf meinem Mac (OS X 10.6.2) “copy & paste” nicht mehr funktionierte: ein Viereck zeichnen, [Strg][C], [Strg][V] – keine Reaktion. Ich habe mir dann kurzfristig geholfen, indem ich einfach unter Windows weitergearbeitet habe. Aber das kann ich ja nicht auf mir sitzen lassen…
Jetzt habe ich mal recherchiert und die Ursache bzw. Lösung ist eine Einstellung für X11: “Pasteboard aktualisieren, wenn CLIPBOARD geändert wird” darf nicht aktiv sein.

Interessant daran ist, dass ich die Lösung aus dem Inkscape Wiki habe, das dort beschriebene Problem aber “kopierte Vektorformen werden als Bitmaps eingefügt” lautet. Das dürfte wohl daran liegen, dass sich der beschriebene Fehler auf Xquartz-X11 bezieht, auf meinem Rechner aber noch das Apple-X11 läuft.