Weiterlesen »]]> Na sowas! Da gelingt es, via JMS einen Task zu parallelisieren, schon springt mir JAXB ins Kreuz mit einer seltsam anmutenden Fehlermeldung:

FWK005 parse may not be called while parsing

Laut java.net u.a. sieht es so aus, als wäre der XML Parser nicht so wirklich Thread-safe und damit für JMS mehr oder weniger schwierig einzusetzen.

Grund ist das folgende Stück Code für die Initialisierung und das Unmarshalling des XML-Fragments:

private static Unmarshaller unmarshaller;
 
static {
  try {
    JAXBContext ctx = JAXBContext.newInstance(MyObj.class);
    unmarshaller = ctx.createUnmarshaller();
  } catch (JAXBException ex) {
    throw new ExceptionInInitializerError(ex);
  }
}
 
public static MyObj unmarshal(byte[] data) throws IOException, JAXBException {
  ByteArrayInputStream bis = new ByteArrayInputStream(data);
  try {
    GZIPInputStream gzis = new GZIPInputStream(bis);
    try {
      return (MyObj) unmarshaller.unmarshal(gzis);
    } finally {
      gzis.close();
    }
  } finally {
    bis.close();
  }
}

Weil die Initialisierung so teuer ist, wurde eine Art Singleton umgesetzt um den Parser zwischen allen Instanzen der Klasse zu teilen. Klappt auf dem Desktop im Standalone-Betrieb auch wunderbar. Nur wenn mehrere parallel laufende Threads gleichzeitig darauf zugreifen, wird es hektisch (siehe Fehlermeldung oben). Was nun?

Eine Möglichkeit wäre natürlich, die JMS Message-driven Bean via @ActivationConfig auf nur eine Instanz zu beschränken:

@ActivationConfigProperty(propertyName = "maxSession", propertyValue = "1")

Das funktioniert prima und die Fehlermeldung taucht zunächst mal nicht mehr auf. Der Task kann damit zwar noch asynchron ausgeführt werden, leider aber nicht mehr parallel. Die Sache hat noch einen weiteren Haken: Gewöhnliche Session Beans laufen ggf. auch parallel und wenn nun beispielsweise zwei Threads gleichzeitig auf denselben JAXB Marshaller zugreifen wollen, knallts erneut.

Abhilfe scheint hier zunächst einmal nur ein synchronize() um den Marshaller-Zugriff herum zu machen. Als Schlüssel für das Nadelöhr wurde das Marshaller-Objekt selbst benutzt. Diese Lösung läßt für den Zugriff auf das Mashaller-Objekt zu jedem Zeitpunkt nur noch einen Thread zu:

synchronize( unmarshaller ) {
  return (MyObj) unmarshaller.unmarshal(gzis);
}

Übrigens: So richtig cool wäre hier eine Singleton-Implementierung mit einem Pool aus N Marshaller-Objekten. Damit werde ich mich zu gegebener Zeit einmal auseinandersetzen.

Weiterlesen »]]> Kirschen pflücken und Projektmanagement haben auf den ersten Blick natürlich nix gemein. Doch beim Pflücken hat man sehr viel Zeit, kommt etwas ins Grübeln und dabei erschließen sich einem gar revolutionäre Analogien. Aber lest selbst…

Verkorkster Projektstart

Läuft mir die Nachbarin, eine nette alte Dame, am Freitag Abend über den Weg. Sie meint, dass ihr Kirschbaum schon ganz schön unter der Last der Früchte ächzt, sie aber selbst zu alt sei, die Kirschen abzuernten. Ich denk mir nix weiter dabei – nur, dass es sicher eine nette Beschäftigung an der frischen Luft für mich und meine kleine Tochter wäre. Es wird sich an dem langen Wochenende sicher eine freie Lücke finden um das zu erledigen. Ich sage schließlich zu, mich darum zu kümmern.

Das Wochenende ist eigentlich schon seit einiger Zeit vollkommen verplant. Aber daran denkt in dem Augenblick des Gesprächs jedenfalls keiner.

Planung und Analyse

Ich höre mich noch fragen, ob genügend Körbe und eine große Leiter vor Ort sind. „Natürlich“, meint sie und ich geh meiner Wege. Kurz und knackig, so mag ich das. Bloß nicht zuviel drüber nachgrübeln und sich in stundenlangen Diskussionen ergehen (nix für ungut, aber die Gespräche mit der netten alten Dame ufern nur allzu leicht aus). Es geht doch nur ums Kirschen pflücken! Und schließlich ist auch Freitag Abend. Da hat man andere Dinge im Kopf als die vor einem liegende Arbeit.

Für die Durchführung wurde der Sonntag Vormittag reserviert. 3 Stunden sollten doch eigentlich genügen.

Entwurf

Da das Wochenende nun bis über beide Ohren mit Aufgaben vollgepackt war, blieb natürlich nicht viel Zeit um über die vor uns liegende Aufgabe zu reflektieren. Warum auch? Die Kirschen pflücken sich doch fast von alleine und so eine Arbeit hat man ja bereits als Knirps X-mal gemacht. Man kennt doch schließlich alle Anforderungen, Herausforderungen und Risiken. Also wozu sich den Kopf mit solchen Gedanken schwer machen?

Umsetzung und (Überraschung!) neue Anforderungen

Sonntag Vormittag – es ist soweit, also direkt an die Arbeit. Mit dem Töchterchen und 2 leeren Schüsseln (Frau und Schwiegermutter machten kurzfristig Eigenbedarf geltend) im Handgepäck ging es zum Garten der Nachbarin.

Beim Aufstellen der Stehleiter machte sich direkt Ernüchterung breit. Das Werkzeug war zwar brauchbar aber hatte so seine Ecken und Kanten. Mit anderen Worten: die Leiter war so alt wie der Baum, wankte und wackelte wie ein Lämmerschwanz. Anstatt nun mit beiden Händen die Früchte abzuernten, viel eine Hand aus um mir die nötige Stabilität zu verschaffen. Das wiederum verlangsamte die Arbeit nicht unwesentlich. Dem Krümelchen machte die Arbeit irre viel Spaß. Natürlich war sie nicht zu 100% für das Projekt einzusetzen. Es war viel Aufwand für die Einarbeitung nötig und nicht jede Kirsche fand ihren Weg in den Korb. Wir stellten dann auch sehr schnell fest, dass unsere Ausrüstung unvollständig war. Der Kleinen fiel ein, dass sie ebenfalls auf eine Leiter klettern wollte und so mußte kurzfristig noch eine weitere Stehleiter herbeigeschafft werden. Und die Körbe benötigten Haken, um sie an den Leitern befestigen zu können.

Projekt Abschluß und Review

Nach nunmehr 5 Stunden war die Arbeit getan. Etwas über der veranschlagten Zeit aber ganz zufrieden mit unserem Tagwerk waren wir dennoch. Nur der Kunde war aufgrund der Verspätung etwas ungehalten (weil das Mittagessen warten mußte).

Ein Review fand natürlich nicht statt!

Und die Moral der Geschichte ist…

Es ist sicher nur eine Frage der Zeit, bis Projektmanagement Seminare auf Kirschplantagen stattfinden.

Weiterlesen »]]> Vor kurzem war ich auf der Suche nach einer schnellen aber eleganten Debug-Lösung zum Testen des Email-Versands. Natürlich lässt sich so ein Dienst auch ganz fix von Hand schreiben (der Autor überlässt das kurzerhand dem Leser zur Übung). Aber wer will das schon? Insbesondere dann, wenn es mal wieder schnell gehen muss!

Hier springt Python in die Bresche. Mit der Klasse DebuggingServer aus dem Modul smtpd stellt es einen solchen Debugging-Mailserver in null-komma-nix auf die Beine. Host und Port lassen sich auf der Kommandozeile festlegen. Hier ein Beispielaufruf:

python -m smtpd -n -c DebuggingServer localhost:1025

Der Prozess lümmelt dann auf der Konsole herum bis er über Port 1025 eine Nachricht empfängt. Diese wird prompt auf der Konsole ausgegeben, was dann beispielsweise so aussieht:

---------- MESSAGE FOLLOWS ----------
Date: Mon, 30 May 2011 12:07:07 +0000 (GMT)
From: sender@myhost.de
Reply-To: sender@myhost.de
To: receiver@anotherhost.de
Message-ID: <145994206.01306757227256.JavaMail.user@hostname>
Subject: Hallo Welt
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Peer: 127.0.0.1 
 
Etwas Demo-Text...
------------ END MESSAGE ------------

Eigentlich alles, was das Debugger-Herz begehrt, oder? Weitere Infos dazu gibt die Python Dokumentation her.

Übrigens ist der SMTP Server nicht alleine unterwegs. Im Handgepäck von Python befindet sich u.a. auch noch ein minimaler HTTP Server, um auf die Schnelle ein lokales Verzeichnis für andere Nutzer verfügbar zu machen. Aufgerufen wird der Dienst wieder über die Konsole:

python -m SimpleHTTPServer

Das bindet den Prozess an die IP 0.0.0.0, Port 8000. Ruft man die URL über den Browser auf, mutet die Server-Antwort zwar etwas spartanisch an, erfüllt aber voll und ganz ihren Zweck:

Der Prozess gibt auf der Konsole das Access-Log des Servers aus. Wie schon vorhin sei auch in diesem Fall auf die Python Dokumentation verwiesen.

Weiterlesen »]]> Beim Basteln an der X-Server Konfiguration (/etc/X11/xorg.conf) ist an manchen Stellen der Herzinfarkt gewissermaßen vorprogrammiert. Bei einer fehlerhaften Einstellung genügt ein einfaches ‘startx’ und plötzlich geht nix mehr. Denjenigen, die nun das System wenigstens noch kontrolliert herunterfahren wollen, kann geholfen werden. Die Rettung erscheint in Form der ‘SysRq’ Taste. ‘Alt’ + ‘SysRq’ zusammen mit einer anderen Taste bietet die Möglichkeit, Kontrollsequenzen an den Kernel zu senden. Eine vollständige Liste dieser Sequenzen liefert u.a. die englische Wikipedia.

Die für einen sauberen Neustart notwendigen Tasten kann man sich leicht über die Eselsbrücke “Reboot Even If System Utterly Broken” einprägen. Diese Tasten lösen folgende Aktionen aus:

Damit das oben beschriebene funktionieren kann, muß das Feature allerdings erst noch im Kernel aktiviert sein. Dafür ist der Kernel mit der Option ‘CONFIG_MAGIC_SYSRQ’ zu kompilieren.

Weiterlesen »]]> Da liegt diese Datei herum und man weiß einfach nix vernünftiges damit anzufangen. Zur Erinnerung: sie wird bei jedem erfolgreichen User-Login auf der Konsole ausgegeben. Naja… Auf unseren Servern tummelt sich eine ganze Reihe von Leuten mit mehr oder weniger Erfahrung aber umso mehr administrativen Berechtigungen. Was liegt da näher, als den lieben User zu fortwährender Aufmerksamkeit bei seinem Tun zu ermahnen?!?

                                              ,-._.-._.-._.-._.-.
                                              `-.             ,-'
       .--------------------------------.       |             |
      |                                  |     ,';".________.-.
      |  great power always accompanies  |     ;';_'         )]
      |  with great responsibility       |    ;             `-|
      |                                  `.    `T-            |
       `--------------------------------._ \    |___          |
                                          `-;   |             |
                                                |..________..-|
                                               /\/ |________..|
                                          ,'`./  >,(           |
                                          \_.-|_/,-/   ii  |   |
                                           `."' `-/  .-"""||    |
                                            /`^"-;   |    ||____|
                                           /     /   `.__/  | ||
                                                /           | ||

Schick verpackt in etwas ASCII-Art sorgt die Mahnung nebenbei noch für etwas Frohsinn bei der Arbeit! Die Grafik hab ich mir übrigens bei chris.com ausgeliehen, wo es übrigens noch viel mehr derartige Kunst zu finden gibt. Heißen Dank an dieser Stelle!!!

Weiterlesen »]]> Wenn man weiß, an welchen Stellen man schrauben muß, ist der Austausch der Hypersonic DB durch eine PostgreSQL DB als DefaultDS des JBoss gar nicht so kompliziert. Leider kann man aber aufgrund der teils doch recht unübersichtlichen Konfigurations-Dateien des JBoss dabei einiges übersehen. Darum habe ich die wichtigsten Schritte hier nochmal zusammengefaßt.

JBROOT und JBSERVER

Für die Lesbarkeit wurden die Bezeichnungen des JBoss Installationsverzeichnis durch $JBROOT und der verwendeten JBoss Konfiguration durch $JBSERVER ersetzt. Ausgehend von einer JBoss-Installation in /opt/jboss-5.1.0.ga und der Verwendung der default-Konfiguration gilt also:

export JBROOT="/opt/jboss-5.1.0.ga"
export JBSERVER="$JBROOT/server/default"

Datasource anlegen

Natürlich muß die Datenbank erstmal angelegt werden. In der psql Shell ist das schnell getan:

CREATE DATABASE jboss WITH owner=jboss encoding='UTF-8' template=template0;

Hier ist jboss ein zuvor angelegter Datenbank User-Account für die Authentifizierung des JBoss Prozesses. Als nächstes sollte man diese Datenbank dem JBoss bekannt machen. Bisher residierte die HSQL Datasource Konfiguration in $JBSERVER/deploy/hsqldb-ds.xml. Diese Datei kann man ersetzen durch $JBSERVER/deploy/default-ds.xml:

<datasources>
  <local-tx-datasource>
    <!-- JNDI mapping name -->
    <jndi-name>DefaultDS</jndi-name>
    <!-- database connection info -->
    <connection-url>jdbc:postgresql://localhost:5432/jboss</connection-url>
    <driver-class>org.postgresql.ds.PGPoolingDataSource</driver-class>
    <user-name>jboss</user-name>
    <password>mypw</password>
    <!-- connection pool ranges -->
    <min-pool-size>20</min-pool-size>
    <max-pool-size>100</max-pool-size>
    <!-- time for a thread to wait for a requested DB-connection -->
    <blocking-timeout-millis>30000</blocking-timeout-millis>
    <!-- time to wait before freeing idle connections -->
    <idle-timeout-minutes>5</idle-timeout-minutes>
    <!-- prepared-statement cache config -->
    <prepared-statement-cache-size>20</prepared-statement-cache-size>
    <share-prepared-statements />
    <!-- SQL dialect -->
    <metadata>
      <type-mapping>PostgreSQL</type-mapping>
    </metadata>
  </local-tx-datasource>
</datasources>

Damit der JBoss mit dieser Datasource etwas anfangen kann, sollte man auch das Archiv mit dem passenden PostgreSQL JDBC Treiber nach $JBSERVER/lib kopieren.

JMS Persistence Provider einrichten

Nun ist es soweit, dem JBoss JMS Provider die neue Datasource etwas schmackhafter zu machen. Die bisherige, auf HSQL basierende, Konfiguration in $JBSERVER/deploy/messaging/hsqldb-persistence-service.xml kann durch eine Kopie des PostgreSQL Templates in $JBROOT/docs/examples/jms ersetzt werden:

cd $JBSERVER/deploy/messaging && \
    rm hsqldb-persistence-service.xml
cd $JBROOT/docs/examples/jms && \
    cp postgresql-persistence-service.xml $JBSERVER/deploy/messaging

Das Template ist schon recht gut auf unsere Bedürfnisse zugeschnitten. Lediglich zwei Anpassungen sind ggf. noch nötig insofern man bei seiner JMS Lösung noch nicht auf Clustering angewiesen ist: Das Flag ”Clustered” sollte den Wert ”false” haben und die Dependency zur ”ChannelFactory” ist zu entfernen/auszukommentieren:

<attribute name="Clustered">
  false
</attribute>
<!--
<depends
    optional-attribute-name="ChannelFactoryName">
  jboss.jgroups:service=ChannelFactory
</depends>
-->

Hintergrund

HSQL ist für die Dauer der Entwicklung ein feines und unkompliziertes Werkzeug. Für den Live-Betrieb des JBoss – insbesondere wenn JMS im Spiel ist – kann es dann aber doch ganz schön auf die Bremse drücken. Aufgrund der “guaranteed delivery” Zusicherung des JMS Providers werden alle zu übertragenen JMS Nachrichten vor ihrem Versand – gewöhnlich in der Default Datasource – gespeichert (neudeutsch “persistiert“). Dieser Ansatz skaliert nicht besonders gut. Ein Austausch des RDBMS im Live-Betrieb wird schon in der JBoss Dokumentation dringend ans Herz gelegt.

Weiterlesen »]]> Sicherst Du schon oder betest Du noch? Als vor einiger Zeit mein Rechner damit anfing, seltsame Geräusche von sich zu geben, mußte ich spontan daran oder an was ähnliches denken. Verdrängung vielleicht. Jedenfalls mußte schnellstens eine Backup-Strategie her… Irgendeine! Denn jedes noch so einfach gestrickte Backup ist besser als gar keins, gell? Für den denkbar einfachsten Fall, eine 1:1 Spiegelung der Daten, ist rsync ein ganz brauchbares Werkzeug.

Wie der Name (“remote synchronize“) schon sagt, kann es auch remote Kopien anlegen. Bei mir kommen allerdings nur ein via CIFS gemounteter Netzwerk-Share und eine mit Ext4 formatierte externe Platte zum Einsatz. Beide werden lokal eingebunden. Im Normalfall würde sich rsync genauso verhalten wie cp und nur eine Kopie aller Daten anlegen. Stattet man den Aufruf aber mit geeigneten Parametern aus, dann ist auch eine inkrementelle Sicherung basierend auf dem modification-timestamp der Dateien möglich. rsync ist sogar so tough, dass es nicht mal die ganze Datei überträgt. Es zerlegt sie in Blöcke, vergleicht die Prüfsummen jedes einzelnen Blocks und überträgt so ausschließlich die geänderten Bestandteile. Richtig groß zahlt sich das erst bei einer remote-Sicherung übers Internet aus. Lokal über USB 2.0 bringt es aber sicherlich auch etwas Performance.

Jetzt zum praktischen Teil. Ein paar Beispiele sind – wie fast immer – besser als tausend Worte.

Beispiel 1: Einfacher Dateitransfer

rsync -rt QUELLE ZIEL

Hierbei werden die Dateien aus QUELLE mit denen in ZIEL synchronisiert. Während -r (“recursive“) bewirkt, dass nicht nur das Verzeichnis QUELLE sondern auch dessen Inhalt in den Abgleich einbezogen wird, sorgt -t (“timestamp“) dafür, dass eine Aktualisierung der Dateien in ZIEL nur dann erfolgt, wenn die Datei in QUELLE einen neueren Änderungs-Zeitstempel hat.

Es spielt durchaus eine gewichtige Rolle, ob QUELLE mit oder ohne Slash am Ende angegeben wird. Ein Aufruf ohne Slash bewirkt, dass im ZIEL-Ordner ebenfalls das Verzeichnis QUELLE angelegt wird und die Dateien darin gespeichert werden. Kurz: Das Wurzelverzeichnis bleibt erhalten. Bei einem Slash am Ende von QUELLE wird stattdessen die Wurzel einfach weggelassen.

Beispiel 2: Datenarchivierung

rsync -av --stats QUELLE ZIEL

Der Parameter -a (“archive“) ist die Zusammenfassung weiterer üblicher Parameter für eine Archivierung der Inhalte von QUELLE:

• -r (“recursive“): QUELLE wird rekursiv gesichert
• -l (“links“): symbolische Links (keine Hardlinks !) werden als solche gespeichert
• -p (“permissions“): die in den Dateien und Verzeichnissen eingestellten Berechtigungen bleiben auch in der Kopie erhalten
• -t (“timestamp“): der Änderungs-Zeitstempel wird gesichert, so dass zukünftige Abgleiche nur seitdem geänderte Dateien übertragen
• -g (“group“): die GID (“group-ID“) bleibt erhalten
• -o (“owner“): die UID (“user-ID“) wird in der Kopie gespeichert
• -D (“devices“): Gerätedateien, Fifos u.a. sog. “special files” werden als solche in der Kopie abgelegt

Nach der ersparten Schreibarbeit wird rsync durch das -v (“verbose“) noch etwas gesprächiger und gibt eine Liste der übertragenen Dateien und Verzeichnisse auf STDOUT aus. Das abschließende –stats sorgt noch für ein Statistik-Summary am Ende der Übertragung.

Beispiel 3: Aufräumen, Teil 1 – die Axt-Variante

rsync -av --delete [-n] QUELLE ZIEL

Im Normalfall werden Dateien, die in QUELLE gelöscht wurden, nicht automatisch in ZIEL entfernt. Mit –delete erfolgt die Anweisung, eben genau das zu tun. Weil das Kommando aber mit Vorsicht zu genießen ist, sollte man vorher zur Sicherheit eine Trockenübung fahren: -n (“dry-run“) ist ein solcher Testlauf. In Verbindung mit -v sieht man eine Liste der Änderungen ohne das tatsächlich irgendwelche Dateien angefaßt werden. Ist man mit dem Ergebnis einverstanden, läßt man beim nächsten Aufruf einfach das -n weg.

Beispiel 4: Aufräumen, Teil 2 – die sanfte Tour

rsync -avz --delete -b --suffix=SFX --backup-dir=BKPDIR QUELLE ZIEL

Anstelle der oben beschriebenen Axt-Lösung, kann mit -b (“backup“) auch auf die sanftere Variante verfahren werden: eine Kopie der zu löschenden Dateien anstatt sie direkt von der Platte zu putzen. Per default werden die Dateien nun in ZIEL umbenannt und ein Tilde-Symbol (~) an den Dateinamen rangehängt. Mit –suffix kann ein alternativer Suffix gewählt werden. Über die Option –backup-dir ist es sogar möglich, eine Art Mülleimer-Funktion anzuwenden: die Dateien werden dann in diesen Ordner verschoben.

Beispiel 5: Unnötiges vom Backup ausschließen

rsync -av --exclude-from=FILENAME --stats QUELLE ZIEL

Über die Option –exclude-from kann eine Datei mit Dateinamens-Mustern angegeben werden, die vom Backup auszuschließen sind.

Weiterlesen »]]> Android ist weit verbreitet auf mobilen Geräten. Mit der ebenfalls bei Google gehosteten x86 Live-CD Live Android können nun auch Anwender ohne Android-Handy in den Genuß dieser Plattform kommen und sie nach Herzenslust ausprobieren. Freilich kann man das heruntergeladene Image auch auf CD brennen und damit den Rechner neustarten. Mit VirtualBox steht allerdings eine – wie ich finde – viel elegantere Alternative zur Verfügung.

Beginnen wir mit dem Download und dem Zusammenschrauben der zwei Teile des Images:

wget http://live-android.googlecode.com/files/liveandroidv0.3.iso.001
wget http://live-android.googlecode.com/files/liveandroidv0.3.iso.002
cat liveandroidv0.3.iso.001 liveandroidv0.3.iso.002 > liveandroidv0.3.iso

Alles übrige geht mit der VBoxManage-Schnittstelle von VirtualBox recht zügig von der Hand:

VBoxManage createvm --name AndroidOS --ostype Linux26 --register
VBoxManage createhd --filename AndroidOS.vdi --size 512 --variant Fixed
VBoxManage modifyvm AndroidOS \
    --memory 128 --vram 16 --hda AndroidOS.vdi \
    --dvd $HOME/liveandroidv0.3.iso
VBoxManage startvm AndroidOS --type sdl

Zur Erklärung: Android basiert auf einem Linux-Kern in der Version 2.6+. Für die HDD genügen eigentlich 512 MB und Hauptspeicher sowie Video-RAM sind mit 126 MB bzw. 16 MB auch ausreichend bestückt. Gebootet wird direkt vom Live-CD Image, das zuvor ins Home-Verzeichnis heruntergeladen wurde.

Im Projekt-eigenen Wiki finden sich noch mehr Informationen zum Thema Konfiguration, Installation von Apps usw..

Weiterlesen »]]> Einfach nicht zu fassen, was dieses Tool alles kann! Im Funktionsumfang der Bash enthalten sind auch 2 Pseudo-Devices für die Kommunikation via TCP oder UDP:

• /dev/tcp/HOSTNAME/PORT und
• /dev/udp/HOSTNAME/PORT

Beim Aufrufen der Devices sollte es sich bei HOSTNAME um einen validen (im Sinne von via DNS auflösbar) Hostnamen oder eine IP handeln. Klar eigentlich. Und PORT ist wohl auch selbsterklärend. Ausgestattet mit diesen Werkzeugen läßt sich daraus nun ein prima Portscanner, der für jeden gegebenen Port einen TCP connect scan durchführt, bauen:

HOSTNAME=${1:-localhost}
PSTART=${2:-1}
PEND=${3:-1023}
for PORT in `seq $PSTART $PEND`; do
 (echo >/dev/tcp/$HOSTNAME/$PORT) >/dev/null 2>&1 && echo "$PORT open"
done

Das Skript erwartet als Parameter (in der Reihenfolge ihrer Nennung) den Namen des zu scannenden Hosts oder seine IP, den Beginn und das Ende der zu scannenden Portrange. Alle Parameter sind optional und werden ggf. durch localhost und die Ports 1-1023 ersetzt.

Aber immer dran denken liebe Kinder: NUR IM EIGENEN HEIM UND NICHT AUF DER STRASSE SPIELEN!!!

Weiterlesen »]]> Beim Basteln auf der Tuxbox, und insbesondere während der Installation von Gentoo, sind detaillierte Informationen über die Hardware-Komponenten des Rechners absolut unerläßlich. Da führt der erste Weg natürlich zur Hersteller-Seite.

Zumindest was die Thinkpads angeht, bin ich da vor kurzem auf eine weitere interessante Informationsquelle gestoßen: ThinkWiki. Hier findet man eine Fülle an Infos zur Hardware-Spezifikation verschiedener Thinkpad-Modelle. Das wird ergänzt durch detaillierte Erfahrungsberichte über die Installation verschiedener Linux-Distributionen und eine Menge Beispiel-Skripte bzgl. Einrichtung, Start und Tweaking von diversen Komponenten, z.B. Thinklight, Fingerprint-Sensor und viele andere.