Der Blog auf tn.genano.de

DIY Dual Screen Monitorhalter

tw — Mon, 13 Feb 2012 10:00:52 +0000

Ich hatte es satt meine zwei LG Monitore mit runden Rahmen an zwei VESA-Halterungen über meinen Schreibtisch zu haben. Deswegen habe ich mich dazu entschlossen mir einen Rahmen zu bauen in dem ich beide Monitore optimal nebeneinander platzieren kann.

Wichtig ist, falls das jemand nachmachen will:

Immer den Netzstecker ziehen!
Nicht alle Monitore sind so aufgebaut, daß es funktioniert.
Ihr verliert jede Garantie des Herstellers (zu recht).
Ich kann nix dafür wenn ich euch oder eure Panels, Katzen, Frauen, Schreibtische etc. Umbringt, kaputt macht, zum Lachen bringt …
In manchen Monitoren ist die Schirmung der Komponenten im Gehäuse untergebracht. Dann ist es keine gute Idee so einen Umbau zu machen.
Macht das Teil ja passend, die Panels sind Druckempfindlich, man kann die beim “reinpressen” schnell beschädigen.
Ja, ich weiß man kann sowas kaufen, aber ich mag das Basteln und mir ging es einfach ums selbst machen.
Mir fällt nix mehr ein, aber es gibt ne menge Fallstricke, macht das nur wenn Ihr euch das zutraut, für Monitore mit geradem Rahmen gibt es im übrigen super Lösungen zum kaufen.

Hiezu habe ich mir auf Leisten 40x15mm zwei entsprechende Rahmen gebaut. Diese sind verzapft und in der Mitte um jeweils 5° angeschrägt, damit ich insgesamt 10° Neigung erhalte. Ein Rahmen ohne Neigung wäre natürlich erheblich einfacher zu konstruieren, allerdings empfinde ich das als sehr unangenehm. Im Hintergrund sieht man noch einen der beiden Monitore welche integriert werden sollen. Diese hatte ich eh schon mal zerlegt um den Standfuß ab zu bekommen. Die Leisten in der mitte stabilisieren den Rahmen. An der Vorderseite sind oben jeweils 10mm Leisten angebracht, an der Seite 5mm, welche die eigentlichen Panels nach vorne halten sollen. Die mitte wird nach diesem Bild mit jeweils 3 Zapfen verleimt und gepresst. Alle Rahmenteile sind zusätzlich mit einer Schraube gesichert (im nachhinein Überflüssig).

Hier sieht man einen ersten Testlauf um zu schauen ob beide Panels auch optimal passen:

Als Anforderung hatte ich den ganzen Rahmen an einer VESA-Halterung zu befestigen. Auf dem oberen Bild sieht man die ja im Hintergrund. Auf dem nächsten Bild sieht man den Rahmen, mit der Hinten angesetzten VESA-Auf nahme. Dazu habe ich passende Keile geschnitten und entsprechenden Verzapft. Zur Stabilisierung habe ich dann noch die vertikalen Leisten Horizontal verzapft, was zusätzlich Last von der mittleren Verbindung abträgt und noch mehr Stabilität bringt.

Auf dem Bild ist der Rahmen schon gespachtelt und geschliffen und damit bereit zum Lackieren.

Auf diesem Bild fehlen eigentlich nur noch die Bedienelemente und jemand der Aufräumt.

Hier sieht man das ganze mal von hinten. Der zweite Vesahalter wird nicht benötigt, auch wenn es so aussieht. Alles in allem gefällt mir das ganze recht gut. Ich hab als letzten Akt noch ein set Bedienelemete druntergepackt und aufgeräumt.

Zugriff auf das Filesystem innerhalb eines Xen Images

tw — Mon, 25 Jul 2011 08:38:40 +0000

Hin und wieder kommt es leider vor, das ein Dateisystem innerhalb eines Xen Images beschädigt ist. Das kann recht problematisch werden, da man da ja nicht so einfach rankommt. Hier ein Weg wie man trotzdem noch was retten kann bzw. einen Filesystemcheck durchführen etc.:

Mit kpartx -a das Image einbinden.
Hat das Image einen LVM bei Punkt vier weitermachen.
Hat das Image keinen LVM kann man nun via /dev/loop auf die Platte zugreifen. Zum Abschluß noch Punkt 9 beachten.
Bei einem Image mit LVM muss nun das System mit vgscannach neuen Devices durchsucht werden. Hat der LVM ein neues Device gefunden erhält man eine Ausgabe wie Found volume group “VolGroup00″ using metadata.
Das gefundene Volume muss man nun mit vgchange -ay VolGroup00 aktivieren.
Nun sind die einzelnen Partitionen unter /dev/Volgroup00/LogVol verfügbar.
Filesystemcheck machen oder mounten: fsck.ext3 /dev/VolGroup00/LogVol00 -f oder mount /dev/VolGroup00/LogVol00 /mnt oder was immer man braucht.
Wenn alle arbeiten abgeschlossen sind muss man dem LVM das Volume wieder wegnehmen. vgchange -an VolGroup00
Nun noch das Image unmounten mit kpartx -d .

Da meistens was übles schiefgegangen ist, wenn man diese Anleitung sucht, wünsche ich allen Lesern viel Glück ;-).

Content Komprimierung mit dem Apache Tomcat und gzip

tw — Mon, 15 Mar 2010 13:45:10 +0000

Ich hatte hier ja schon beschrieben, wie man Content direkt mit dem Apache Httpd komprimiert. Nun gibt es hin und wieder doch auch mal die Situation, das man einen Tomcat direkt am Netz hängen hat. Dieser soll natürlich auch seinen Content komprimieren und damit alle Vorteile bieten.

Hier nun was man eintragen muss, damit alles klappt:

In der server.xml sucht man den HTTP Connector:

Und fügt folgendes Hinzu:

compression="on"
compressionMinSize="2048"
noCompressionUserAgents="gozilla, traviata"
compressableMimeType="text/html,text/xml"

Anschließend sieht das ganze dann so aus:

Und schon läuft der Tomcat mit Kompression.

Motorradtour nach Skandinavien inklusive Nordkap

tw — Thu, 04 Feb 2010 14:25:59 +0000

Wir (mein Kollege und ich) planen aktuell ein Motorradtour durch das schöne Skandinavien inklusive einem Besuch am Nordkap. Hier eine Übersicht über die geplante Route, wobei wir diese gegen den Uhrzeigersinn (also Nürnberg –> Helsinki –> Nordkap –> Bergen –> Nürnberg) befahren wollen.

Übersichtskarte © OpenStreetMap und Mitwirkende, CC-BY-SA

GPX Track Datei dieser Übersichtskarte herunterladen

Diese Route haben wir ausgewählt, da wir oft gelesen haben, das Norwegen mit die schönsten Strecken bietet und wir natürlich hoffen das dies auch so ist. Die Tour soll über 3 Wochen vom 29 Mai bis zum 19 Juni 2010 stattfinden. Gesamtfahrstrecke laut Plan (also ohne Essen suchen, schönere Plätze finden, etc. und ohne Fähren) 6486km. Gesamtstrecke inkl. Fähren 7847km.

Bisher sichere Ausrüstung:

eoc:

BMW R 1150 GS
Givi Monkey Topcase E45
2x Givi Monkey Seitenkoffer E45
Rukka Airob Textilkombi mit Gore Tex
SHOEI Raid II
Xtend-Adventure Breeze 2
Them-a-Rest ProLite 4 Regular
Vaude Kiowa Ultralight 220 / 235 oder Ajungilak Tundra Spring 195R
Primus Kocher Express mit Piezozuendung
Vaude-Kochset-Cayenne
Primus Leichtgewicht Besteck

tw:

Suzuki GSX750F
Krausser K4 Seitenkoffer K5 Reflex Topcase
Hein Gericke Textilkombi mit Gore Tex
Schuberth C2 Helm
Salewa Micro Base Zelt (passt in nen K5 Reflex)
Michelin Pilot Road 2 Reifen
Ein Bundeswehrbesteck
TomTom Rider II inkl. Bluetooth Headset
Canon EOS 400D inkl. 3 Objektiven
Gorillapod (flexibles Stativ)
Kettenöler von Kettenoeler.com
Salewa Diadem Micro 250 SB Schlafsack
Them-a-Rest ProLite 4 Regular
Campingaz Twister Plus PZ Kocher
Campingaz Lumostar C 270 PZ Lampe

Bisherige definitive Fixpunkte:

30.05.2010 03:00 Abfahrt der Fähre Travemünde (DE) Helsinki (FI)
18.06.2010 08:00 Abfahrt der Fähre Kristiansand (NO) Hirtshals (DK)

Die Tage und Touren:

Alle Tage wird tw mit seinem TomTom und der Software Tripmaster aufzeichnen. Dazu wird alle 30 Sekunden die Position erfasst und aufgezeichnet. Diese Dateien gibt es nach der Tour als Karte und zum Download. Geplant ist eine Pro Tag, wobei Tag 2 natürlich entfällt, da wir ja eh nur auf der Fähre sind. Die einzelnen Tage werden dazu dann verlinkt.

Alle GPS Dateien (itn, gpx-tracks, gpx-paths) als Archiv zum Download:

[Update]

Wir haben überlebt und sind zurück. Nach und nach werde ich nun die Seite updaten und die einzelnen Tage einstellen. Bitte geduld, das dauert alles ein bischen.

[/Update]

Tag 1: 29.05.2010 (682km Autobahn)

[[Visit blog to check out this spoiler]]

Tag 2: 30.05.2010 (Wenns mit der Fähre klappt) Update: Tallink Silja fährt nicht, also Fahren wir jetzt Finnlines :-D (1.225km Bootfahrn)

[[Visit blog to check out this spoiler]]

GPX Datei des Tag 2 herunterladen
Keine ITN und keine Track Datei, weil da fahren wir ja nicht selbst ;-)

Alle Karten auf dieser Seite stammen vom OpenStreetmap Projekt unter CC-BY-SA http://creativecommons.org/licenses/by-sa/2.0/ Lizenz.

Schlechte Bildqualität im Firefox

tw — Tue, 02 Feb 2010 09:47:13 +0000

Seit geraumer Zeit hatte ich ein Problem mit der Darstellung von Bildern im Firefox. Diese sahen ziemlich pixelig und zerstört aus. Ein Kollege konnte das Problem beheben, indem er sein Profil weggeschmissen und ein neues erstellt hat. Das wollte ich aber nicht. Deswegen hab ich ewig gesucht und schließlich die verblüffend einfache Lösung gefunden:

Man gehe auf Ansicht –> Zoom –> und mache einen Haken bei “Nur Text Zoomen”

Und plötzlich sehen die ganzen Bilder nimmer so schlimm aus ;-). Zugegeben, das ist kein wirklicher Fehler, allerdings hat mich das eine ganze Weile geärgert, das ich es lieber mal hier hinschreibe, evtl. haben ja auch andere das Problem, die eine Webseite mal vergrößert und verkleinert haben.

Also, User zu dumm, aber trozdem hilfreich.

Wer UMTS nutzt, kann ein anderes Problem haben: Es gibt Proxys bei den Providern welche Grafiken komprimieren um Webseiten schneller Laden zu lassen, hier hilft oft das Drücken von CTRL-R oder das abschalten des Proxys. Hier kann euch google weiterhelfen.

Content Komprimierung mit mod_deflate und Apache 2

tw — Wed, 20 Jan 2010 08:17:35 +0000

Warum soll ich meinen Content Komprimieren?

Hierfür gibt es einige Argumente:

Verringerung der nötigen Bandbreite, Verkleinerung des Volumens der Seite
Ggf. schneller Ladezeiten beim Nutzer
Good Style ;-)

Tatsächlich ist es so, das heute viele Webseiten auf Komprimierung Ihrer Daten setzen, dies ist mit modernen CPUs und effektiven Modulen wie mod_deflate, selbst bei hochvolumigen Seiten, kein Problem mehr. Hiermit kann ohne großen Aufwand massiv Bandbreite gespart werden, da nahezu alle modernen Browser mit komprimierten Inhalten umgehen können. Nach meinen Erfahrungen kann man locker 10 bis 20% Traffic einsparen, aber auch hier ist das ganze natürlich abhängig von den lokalen Gegebenheiten.

Hier eine Beispielkonfiguration im Apache:

#Maximize Compression
DeflateCompressionLevel 9

# Insert filter
SetOutputFilter DEFLATE

# Netscape 4.x has some problems…
BrowserMatch ^Mozilla/4 gzip-only-text/html

# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip

# MSIE masquerades as Netscape, but it is fine
# BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

# NOTE: Due to a bug in mod_setenvif up to Apache 2.0.48
# the above regex won’t work. You can use the following
# workaround to get the desired effect:
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html

# Don’t compress images
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png)$ no-gzip dont-vary

# Make sure proxies don’t deliver the wrong content
Header append Vary User-Agent env=!dont-vary

Mit dem Parameter “DeflateCompressionLevel” setzt man, wie bei gzip auch, die Stärke der Kompression. 9 ist das Maximum und 1 das schwächste. Dies kann man je nach Serverleistung variieren, wobei das ganze mit mod_deflate ziemlich effizient ist und ich auch mit einem 9 nur einen sehr geringen Anstieg der Serverlast hatte (Server mit mehreren Million Zugriffen/Tag). Der Rest der Konfiguration ist 1 zu 1 aus dem Apache Handbuch kopiert und ich hatte bisher nie Probleme damit.

Date Wed, 20 Jan 2010 08:12:01 GMT
Content-Type text/html;charset=ISO-8859-15
Vary Accept-Encoding,User-Agent
Content-Encoding gzip
Content-Length 6389
Xonnection close

Hier seht Ihr nochmal wie das dann im Header, welchen Ihr mit Firebug oder ähnlichem sehen könnt, anschließend aussieht. Content-Encoding ist gzip, das Kompressionslevel kann man hier nicht sehen, dieses wird im Header nicht angegeben. Ihr könnt allerdings mal mit dem CompressionLevel Paramter rumspielen und euch dann die Content-Length anschauen.

Hier noch der Link zum Apache Manual

Expire Header mit mod_expire im Apache 2

tw — Wed, 20 Jan 2010 07:45:27 +0000

Wozu Expire Header?

Oft kommt es vor, das man Daten über einen Webserver ausliefert, welche lange Zeit konsistent bleiben, Logos, bestimmte Grafiken etc. Wenn man solche Bestandteile auf seiner Webseite hat, sollte man diese mit einem Expire Header versehen. Der Expire Header bewirkt dabei, das die statischen Bestandteile der Seite bei (den meisten) Nutzern nur einmal heruntergeladen werden und bis zum Ende der Expiration im Cache des Browser gehalten werden. Besucht der Anwender innerhalb der Expiration Zeit die Webseite nochmals, werden die statischen Bestandteile aus dem lokalem Cache des Benutzers geladen und müssen somit nicht erneut heruntergeladen werden. Dies bietet zwei Vorteile, zum einen spart man damit Bandbreite und Datenvolumen zum anderen ist die Ausgabe aus dem Cache, des Browsers, in der Regel deutlich schneller als das Herunterladen des Contents. Bei der Verbreitung von Breitbandanschlüßen (zu mindestens in Europa) kommt dem Argument des schnelleren Seitenaufbaus oft mehr Bedeutung zu als der genutzten Bandbreite, wobei dies natürlich auch stark vom jeweiligen Angebot abhängt.

Hin und wieder hat man den Bedarf Expire Header von bestimmten Dateitypen zu setzen, entweder weil die dahinterliegende Applikation dies nicht richtig kann, oder weil statischer Content direkt über den Apache ausgeliefert werden soll. Hierzu kann man das Modul mod_expire des Apache’s verwenden.

Hier ein Beispiel:

#set expire header for the static directorys to 7 days

ExpiresActive On
ExpiresDefault “access plus 7 days”

In diesem Beispiel wird ein Expire Header für von 7 Tagen (bei wirklich statischem Content zu kurz) auf das Verzeichnis /img gesetzt.

Sobald das Modul aktiv ist und erfolgreich Arbeitet, kann man sich z.B. mit Firebug anschauen ob die Änderungen erfolgreich waren:

Date Wed, 20 Jan 2010 07:22:58 GMT
Server Apache
Last-Modified Wed, 08 Oct 2008 08:36:30 GMT
Etag "eb039a-33-458b9d013df80"
Accept-Ranges bytes
Content-Length 51
Cache-Control max-age=604800
Expires Wed, 27 Jan 2010 07:22:58 GMT
Content-Type image/gif

Hier sieht man nun sehr schön wie im Header die entsprechenden Expire Informationen gesetzt werden.

Hierzu gehören sowohl das Feld “Last-Modified”, “Cache-Control” und natürlich “Expires”.

Eine Ramdisk unter Linux erstellen und verwenden

tw — Mon, 05 Oct 2009 08:43:07 +0000

Eine Ramdisk erstellen

Hier beschreibe ich wie man unter den gängigen Linux Distributionen eine Ramdisk erstellt. Das kann an vielen Stellen ganz nützlich sein.

Was ist eine Ramdisk?

Eine Ramdisk ist ein Teil des flüchtigen Arbeitsspeichers (RAM –> Random Access Memory), auf welchen man wie auf eine Festplatte zugreift. Großer Vorteil der Ramdisk ist, das diese erheblich schneller ist als eine Festplatte. Während man von modernen Festplatten bis ca. 150 MB/s lesen kann, kann dies bei einer Ramdisk leicht mit über 1 GB/s passieren. Großer Nachteil an einer Ramdisk ist, das der Inhalt in einem flüchtigen Speicher liegt und bei jedem Reboot oder bei jedem abschalten der Maschine verloren geht. D.h. die Ramdisk muss bei jedem starten neu „beladen“ werden bzw. durch temporären Inhalt versorgt werden.

Wie erstellt man eine Ramdisk

Ein Ramdisk kann man heute unter jeder aktuellen Linux Distribution erstellen. Der Support für Ramdisks ist im Kernel integriert. Ich beschreibe hier alle Schritte die nötig sind um eine Ramdisk zu erstellen und diese als „Plattenersatz“ zu verwenden.

Kerneloptionen konfigurieren

Zum Erstellen einer Ramdisk muss man dem Kernel eine Option mitgeben diese zu erstellen. Das tut man in der Regel in seinem Bootloader. Auf dem meisten gängigen Distributionen ist dies Grub. Die Konfigurationsdatei befindet sich bei den meisten Distributionen unter /boot/grub/menu.lst. In dieser ist der zu bootende Kernel aufgeführt und seine Parameter. Erkennen kann man das an dem vorgestelltem Wort kernel. Wir fügen an diese Zeile einfach den Parameter ramdisk_size=xxxxxx an, wobei xxxxxxx durch eine Anzahl 1024KB Blöcke ersetzt wird. D.h. wenn ich 10 Megabyte Ramdisk haben möchte setze ich den Wert auf 10 * 1024 = 10240. Damit erhalte ich eine 10 MB Ramdisk. 300 MB Ramdisk sind dann entsprechend 307200. Ein Beispiel einer Ramdisk mit 976,5625 MB .

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/sda2
#          initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-53.1.21.el5)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-53.1.21.el5 ro root=LABEL=/ ramdisk_size=1000000
        initrd /initrd-2.6.18-53.1.21.el5.img

Ist der Parameter hinzugefügt worden muss gebootet werden. Damit der Kernel die Option bei Starten auswerten kann. Im Anschluß an den boot Vorgang kann man sich mit dem Befehl dmesg das Log des Kernels anschauen und folgendes entdecken:

Diese Ausgabe kommt nicht bei jeder Distribution …

Kernel command line: ro root=LABEL=/ ramdisk_size=1000000

Diese Ausgabe sollte man aber immer sehen, die Zahlen beziehen sich auf das Beispiel mit der 976,5625 MB Ramdisk.

RAMDISK driver initialized: 16 RAM disks of 1000000K size 4096 blocksize

Das sagt uns das jetzt prinzipiell 16 RAM disks mit 1000000K große zur Verfügung stehen. Das ist ein bischen viel, weil 16 * 1000000 K = 15625 MB = 15.2587890625 GB. Zuviel für die meisten Rechner. Den Rechner den ich hier verwende hat auch nur 8 GB RAM. Also hätten wir ein Problem, da uns der RAM nicht reicht. Aber keine Angst, wir haben nun nur die Möglichkeit 16 Ramdisks in der größe verwendet, der Speicher wird erst dann verbraucht wenn wir diese auch tatsächlich nutzen. Ich benötige nur eine und hab damit noch genug ram frei.

Ramdisk nutzen

Nachdem wir nun erfolgreich die Ramdisk(s) initialisiert haben, können wir diese nun nutzen. Dazu müssen wir ein Dateisystem auf der Ramdisk erstellen, damit wir auch Dateien abspeichern können. Die Ramdisk steht uns unter einer Device Adresse zur Verfügung, ähnlich wie eine Festplatte. /dev/ram0 ist die erste Ramdisk in einem System /dev/ram1 die zweite und so weiter, in meinem Fall bis /dev/ram15, also die 16te Ramdisk. Ich brauche ja nur eine, nehme also die /dev/ram0. Auf dieser Ramdisk benötigen wir kein tolles Filesystem mit Journaling oder ähnlichem, da es sowieso bei jedem booten verloren geht. Also entscheide ich mich für das klassiche ext2 Dateisystem, dies ist recht ausgereift und auf ner Ramdisk ausreichend performant. Wir verwenden also folgenden Befehl: mkfs.ext2 -m /dev/ram0. Damit erstellen wir das Dateisystem auf dem Device /dev/ram0, die Option -m bewirkt das wir das Dateisystem im vollen Umfang nutzen können und kein Platz für den Benutzer root reserviert wird (weil das brauchen wir hier ja nicht). Und schon ist unsere Ramdisk fertig. Wir können Sie nun mounten und verwenden. mount /dev/ram0 /mnt.

Zu Beachten

Die Erzeugung des Filesystems und das mounten muss nach jedem reboot wiederholt werden. Ich verwende dafür ein init script, mann kann es natürlich auch anders machen.
Auch zu beachten ist, das man jetzt eine hochperformante Platte hat, von der Daten schnell gelesen und in die Daten schnell geschrieben werden können. Es kann durchaus dazu kommen, das Prozesse die zuvor an zu langsamen Platten gescheitert sind, nun plötzlich an nicht ausreichender Prozessorperformance scheitern, bzw. den Rechner enorm auslasten. Das muss man im Einzelfall testen.

Init Scripte für Centos / Redhat fit machen (Chkconfig)

tw — Mon, 05 Oct 2009 08:38:04 +0000

Init Scripte für Chkconfig

Hier bekommst Du eine kurze beschreibung wie man init Scripte für chkconfig fit macht.

Die Syntax

Für chkconfig sind folgende zwei Einträge im Init Script nötig:

chkconfig:
description:

Die description ist zwingend notwendig. Ein bischen Doku kann man schon machen.

Bei chkconfig: ist zu beachten, das man den “:“ nicht vergisst, ansonsten erkennt chkconfig den Eintrag nicht. chkconfig: hat drei Paramater, das Runlevel, die Startpriorität und die Stoppriorität. Der Runlevel besagt in welchem Runlevel der Dienst gestartet wird, also 1,2,3,4 oder 5. Die Angabe wird einfach durch die Angabe der Runlevel geamacht. Also:

chkconfig: 12345  <- Script wird in Runlevel 1,2,3,4 und 5 gestartet
chkconfig: 345 <- Übliche Variante, Script wird in Runlevel 2,4,5 gestartet

Die Startpriorität legt fest wann ein Script in den Runleveln gestartet wird. Also:

Script 1:
chkconfig: 345 20 <- Script wird in Runlevel 3,4,5 gestartet mit der Prio 20

Script 2:
chkconfig: 345 21 <- Script wird in Runlevel 3,4,5 gestartet mit der Prio 21 also später als Script 1

Die Stopprorität legt fest wann ein Script in den Runleveln gestopt wird. Also:

Script 1:
chkconfig: 345 20 80 <- Script wird in Runlevel 3,4,5 gestartet mit der Prio 20, gestopped mit der Prio 80

Script 2:
chkconfig: 345 21 79 <- Script wird in Runlevel 3,4,5 gestartet mit der Prio 21 also später als Script 1, gestopped wird es mit Prio 79 also früher als Script 1

Alles ganz einfach.

Eine Description sieht dann folgendermaßen aus:

description: Was mein Script macht

Auch nicht der Hammer. Hier sei nochmals gesagt, man braucht die description gelle Martin?

Beispiel

Hier nochmal ein komplettes Beispiel:

#! /bin/sh
#
# Mein Script
#
# chkconfig: 345 21 79
# description: Mein Script

[Howto/Tutorial] Dropbear ssh für Android cyanogenmod konfigurieren

tw — Fri, 18 Sep 2009 10:05:23 +0000

Du möchtest also per ssh auf dein Telefon. Das ist prinzipiell ab der Version 4.0.2 der cyanogenmod Software auf deinem Telefon möglich. Ab dieser Version ist der dropbear ssh server mit dabei. Dieser nutzt im Build von cyanogen das Verzeichnis /data/dropbear/.

Du musst nun folgendes tun:

Einen ssh key mit PuTTY oder Linux erzeugen. Für Putty gibts hier eine Anleitung.

Jetzt muss Du den ssh public key als Datei speichern und authorized_keys Datei auf der sdkarte speichern.

Jetzt kommen die Sachen im Terminal deines Telefons:

Werde root:

su -

Lege das Verzeichnis /data/dropbear und /data/dropbear/.ssh an:

mkdir -p /data/dropbear/.ssh

Kopiere die die Datei authorized_keys nach /data/dropbear/.ssh

cp /sdcard/authorized_keys /data/dropbear/.ssh/

Setze nun die richtigen Rechte:

chmod -R 644 /data/dropbear

Erzeuge nun einen passenden Hostkey (das kann einen moment dauern):

dropbearkey -t rsa -f /data/dropbear/dropbear_rsa_hostkey

Optional kannst Du noch einen dss key erzeugen:

dropbearkey -t dss -f /data/dropbear/dropbear_dss_host_key

Jetzt musst Du Dir noch ein passendes Profil anlegen:

echo >>/data/dropbear/.profile "PATH=/usr/bin:/usr/sbin:/bin:/sbin \
:/system/sbin:/system/bin:/system/xbin:/system/xbin/bb:/data/local/bin"

echo >>/data/dropbear/.profile "export PATH"

Fertig!

Jetzt kannst Du den dropbear Server das erste mal starten:

dropbear -v -F

Wenn alles gut ist siehst Du folgendes (oder so ähnlich):

TRACE: enter loadhostkeys
TRACE: enter buf_get_priv_key
TRACE: enter rsa_key_free
TRACE: leave rsa_key_free: key == NULL
TRACE: enter buf_get_rsa_priv_key
TRACE: enter buf_get_rsa_pub_key
TRACE: leave buf_get_rsa_pub_key: success
TRACE: leave buf_get_rsa_priv_key
TRACE: leave buf_get_priv_key
TRACE: enter buf_get_priv_key
TRACE: enter dsa_key_free
TRACE: enter dsa_key_free: key == NULL
TRACE: enter buf_get_dss_pub_key
TRACE: leave buf_get_dss_pub_key: success
TRACE: leave buf_get_priv_key
TRACE: leave loadhostkeys
[6343] Sep 18 11:53:35 Not forking
TRACE: listensockets: 1 to try

TRACE: listening on ':22'
TRACE: enter dropbear_listen
TRACE: dropbear_listen: all interfaces
TRACE: leave dropbear_listen: success, 1 socks bound

Nun kannst Du das erste mal ein ssh auf dein Telefon machen. In einem anderen Artikel beschreibe ich wie man den Dienst beim booten startet. Hattest Du nun die Hoffnung auf ein Login unterwegs möglich ist, muss ich dich leider, zumindestens für T-Mobile, entäuschen. Du bekommst im T-Mobile Netz keine öffentliche IP, sondern eine Private (NAT). Damit ist es nicht möglich von aussen auf dein Telefon zuzugreifen.

Ein Teil dieses Artikels ist im übrigen dem Wiki hier entnommen.