Veraltet: OpenIndiana und Solaris werden kaum noch als Desktop eingesetzt. Multimedia-Codecs sind unter Linux trivial installierbar.
Der OpenSolaris fork Openindiana und Multimedia
Ich nutze Openindiana auf meinem Notebook als Desktopsystem. Natürlich wird damit hauptsächlich gearbeitet, denn noch sehe ich mir gerne mal ein Video an, höhre eine mp3 oder einen Livestream im Internet. Dafür benötigt man passende Codecs und Player. Diese stehen oft unter Lizenzen, welche einem ausliefern mit Openindiana im Wege stehen.
Nun kann man also anfangen sich alles Stückchen für Stückchen zusammen zu suchen oder auf ein Multimedia Repository zurückgreifen. Das spart viel Arbeit.
Veraltet: OpenIndiana und Solaris werden kaum noch eingesetzt. Wine läuft unter Linux deutlich besser als je unter Solaris.
Der OpenSolaris fork Openindiana und Wine
Wine braucht man immer mal wieder für irgendwas. Ich auf meiner Solariskiste auch…. Auf der Download Seite von wienhq.org (http://www.winehq.org/download) gibt es zwar einen direkten Link zu einem fertigen Paket für Solaris (OpenSolaris binär .pkg für OpenSolaris x86) aber dieser scheint irgendwie tot zu sein:
This application is no longer in service. For those in the community who participated in the past we thank you for your contributions.
Damit ist wohl wieder mal Handarbeit angesagt. Um wine selbst zu übersetzten fehlen noch ein paar Pakete, diese lassen aber glücklicherweise schnell mit dem Paketmanager installieren:
Nun schnell den heruntergeladenen Tarball von wine auspacken und in das Verzeichnis springen:
$ bunzip2 wine-1.3.13.tar.bz2
$ tar xvfwine-1.3.13.tar
$ cd wine-1.3.13
Damit nun auch gleich alles gefunden wird muss noch ein Symlink angelegt werden:
$ ln -s /usr/bin/automake-1.10 /usr/bin/automake
Jetzt noch schnell der kleine Dreisatz:
$ ./configure --prefix=/usr
$ make
$ make install
Fertig ist wine… Da stand man schon vor größeren Herausforderungen, oder?
*Update*
Ihr solltet euch unbedingt mal das Spec Files Extra Repository anschauen, bevor ihr hier etwas macht !
Veraltet: OpenIndiana und Solaris werden kaum noch eingesetzt. NFS funktioniert unter FreeBSD und Linux identisch und ist dort besser dokumentiert.
Der OpenSolaris fork Openindiana und NFS zu Linux
Es gibt leider ein kleines Problem zwischen den Lizenzen unter welchen Linux und Opensolaris herausgegeben werden. Diese sind nämlich inkompatibel. Das bedeutet man kann nicht einfach Code welcher unter der CDDL erstellt wurde in den GPL Linux Kernel packen und umgekehrt. Dieses merkt man, wie ich, sehr schnell beim einfachen Versuche seine lang genutzte externe ext4 formatierte USB Festplatte in mein Opensolaris zu mounten…..
Es gibt zwar Mittel und Wege sein ext2 / ext3 read only zu mounten aber bei ext4 ist hängen im Schacht :-/ In Zeiten von GB-Netzwerken geht das ja bei kleineren Datenmengen dank NFS noch.
Pahhh da boote ich ganz cool meine Linux-Schüssel, hänge die USB-Platte ein und passe meine exports für einen ganz einfachen und schnellen Share an:
$ cat /etc/exports
/festpladde (ro)
Dann noch schnell dem NFS Server auf der Linuxschüssel sagen das er die exports neu einliest:
$ exportfs -ra
Und noch mal gegenchecken ob der Export auch sauber in der Liste steht:
$ showmount -e
/festpladde *
Perfekt nun sollte jeder Rechner einfach die Daten mounten können, denke ich!
Auf meinem Solaris gebe ich schnell in der Konsole den mount Befehl ein und:
$ mount 192.168.1.88:/festpladde /mnt
No such file or directory
No such file or directory?????
Ich prüfe alle Einstellungen noch 3 mal nach…. Alles richtig! Alles richtig?
Ja im groben schon. Solaris versucht die Linux Kiste per NFSv4 anzusprechen. Dieses unterstützen zwar beide Maschinen, es kann denn noch Probleme damit geben. Schaltet man aber bewusst auf NFSv3 zurück klappt es (darauf soll mal einer kommen.).
$ mount -o vers=3 192.168.1.88:/festpladde /mnt
Ganz blöde Falle, oder?
Hat man häufiger Datenaustausch per NFS zu Linux Maschinen könnte man Solaris dazu bringen per default immer NFSv3 zu nutzen:
$ sharectl set -p client_versmax=3 nfs
Will man es später ändern reicht es natürlich die 3 gegen eine 4 zu ersetzten, schlau was?
Veraltet: OpenIndiana als Solaris-Fork wird kaum noch produktiv eingesetzt. Wer ein robustes Unix-System mit ZFS sucht, ist mit FreeBSD besser bedient.
Der OpenSolaris fork Openindiana
Openindiana ist ein fork von OpenSolaris. OpenSolaris ist wiederum die von SUN unter der CDDL freigegebene Version ihres Betriebssystems Solaris. Seit meiner Ausbildung hänge ich immer irgendwie mit einem Bein im Solaristopf. Ich komme einfach nicht von diesem OS weg. Was wohl daran liegt das ich es auch nicht möchte. Denn es ist ein sehr schönes OS 🙂 Zusätzlich ist der default Unterbau seit längerem schon das Dateisystem ZFS.
ZFS ist nun schon ein paar Jahre alt, denn noch habe ich bisher noch kein Dateisystem gefunden welches im wirklich das Wasser reichen kann. Hier und da in Detailvergleichen, keine Frage aber
alles in allem „no way“. Bei seiner Einführung hat SUN etwas von unkaputtbar erzählt. Titanic lässt grüßen? Auf keinen Fall… Ich habe es noch nicht geschafft ein ZFS zu zerlegen. Egal wie oft der Strom ausfällt oder der Rechner einen Reset bekommt. Ohne Hammer bzw. echten Hardwaredef. läuft das System einfach weiter.
Wie auch immer…. Vor ein paar Tagen ist nun die Entwicklerversion oi_151a erschienen. Die Version 148 war schon viel versprechend. Diese Version lief auch immer im Dualboot neben meinem Gentoo. Da sie denn noch viel Schleifarbeit an vielen Stellen braucht hatte sie eher ein passives leben 🙁
Dieses hat sich jetzt nach einem kurzen Test geändert. Gentoo verschwindet in eine Virtualbox VM auf dem Solarissystem und dann geht es los.
Ich liste in laufe der Zeit mal in einem Untermenü auf was mir so aufgefallen ist bzw. was anderen vielleicht weiterhelfen könnte.
OpenIndiana der fork von OpenSolaris und Solaris? Ja und nein, denn Sun hat sein Verspechen, die OpenSolaris-Entwicklung für die Gemeinschaft zu öffnen, nicht eingehalten hat und da Oracle nach der Übernahme von Sun zunehmend Teilprojekte einstellte, haben Mitglieder der OpenSolaris-Entwickler-Gemeinschaft am 3. August 2010 die Gründung des Projektes Illumos zur Entwicklung eines wirklich freien Open-Source-Solaris bekanntgegeben. OpenIndiana hat nun diese Basis.
Ich hatte auf einer meiner Maschinen ein kleines Problem mit der LiveCD. Diese bliebt beim booten einfach hängen und dieses ohne erkennbaren Grund. Zumindest konnte ich auf den Konsolen nichts erkennen und einen Logfile gibt es so ja erstmal nicht :-/ Bei einem Linux Live System würde man ja nun erstmal Kernel Optionen wie: noacpi / noapic / acpi=off oder so ein Geschlönz probieren, aber hier????
Ich habe im Zusammenhang mit der OpenIndiana LiveDVD ein paar Bugs und Probleme im Zusammenhang mit USB gelesen. Hier scheint das System noch etwas „anfällig“ zu sein 🙁 Wie auch immer nach einigen Tests viel mit nichts besseres mehr ein als einfach den USB-Kontroller im BIOS zu deaktivieren. Nur um das USB-System auszuschließen versteht sich… Tja, was soll ich sagen? USB im BIOS ausschalten und LiveDVD (der OpenIndiana Live USB-Stick ist dann natürlich nutzlos) einlegen. Schon versagen ordnungsgemäß USB-Tastatur und USB-Maus ihren Dienst, OpenIndiana Bootet aber sauber hoch. Spannenderweise erkennt das gebootete System den USB-Kontroller wieder und somit auch Maus, Tastatur oder sonstige USB-Sticks. Dieses Verhalten führte zwar bei mir zu etwas Stirnrunzeln, bringt mir denn noch ein funktionierendes System.
Oracle Solaris 11
Oracle hat Solaris 11 herausgegeben. Im direkten Vergleich zu OpenIndiana gibt es dann doch einige Unterschiede. Vor allem hinsichtlich Zonen, Netzwerk, den erweiterten Möglichkeiten der höheren ZFS Version und noch vieles mehr….
Einiges hier wird sich daher etwas mischen. Auf was es sich jeweils bezieht werde ich jeweils aufführen.
GeoTagging mit dem i-gatU GT200e Gentoo Linux und Digikam…
Ich habe von meiner Frau einen GPS Datenlogger zum Geburtstag geschenkt bekommen. Damit hat sie mir auch direkt meinen Wunsch nach so einem Gerät erfüllt. Danke.
Allen jenen welche durch eine Suche auf diesen Beitrag gestoßen sind muss ich wohl kaum erzählen was und zu welchem Zweck man dieses kleine Gerät einsetzten kann. Besitzer eines Smartphones werden wohl meist auch nur müde lächeln. Daher reiße ich nur kurz an, was ich mit dem Teil möchte.
Angeschlossen und geladen wird der GT-200e von i-gatU per USB. Ich habe zusätzlich die Möglichkeit das Gerät per Bluetooth zu verbinden. So zum Beispiel mit meinem Nokia Mobiltelefon (ja, vielleicht kaufe ich irgendwann mal etwas neuers). Kismet auf meinem Notebook oder oder oder….
Die aktuelle GPS Position kann mit dem Gerät per Knopfdruck oder je nach Einstellung automatisch im Intervall gespeichert werden. Da ein Akku verbaut ist kann es dieses komplett als Stand-Alone Gerät. Genau dieses ist mein Hauptplan…. Ich packe es einfach in meine Tasche oder befästige es an meiner Spiegelreflexkamera und/oder Digitalkamera und lasse es einfach mitlaufen. Die Akkulaufzeit reichte bei mir schon für 3 Tage, dann habe ich aufgehört zu testen.
Dieses kleine Ding hängt nun also an meiner Canon EOS 450D und schreibt alle paar Sekunden meinen genauen Standort auf. Zuhause kann ich nun diese Daten vom Gerät als GPX Datei auslesen und zusammen mit meiner Bilderverwaltungssoftware Digikam, die Bilder meiner Kamera mit den GPS Koordinaten vermischen. Somit ist in den Metadaten jedes Bildes gespeichert an welcher Position genau ich es aufgenommen habe.
Natürlich lässt sich anhand der Wegpunkte die genaue Strecke, Geschwindigkeit, Höhe usw… Errechnen und in lustige Grafiken gießen. Dieses ist für mich dass Abfallprodukt.
Wie so oft reicht es auch i-gatU sich hinsichtlich Treiber- und Softwareunterstützung um die Microsoft Windows und Apple MacOS Benutzer zu kümmern. Linux Benutzer müssen sich halt selbst irgendwie kümmern und das haben sie getan. Es gibt das Progrämmchen igotu2gpx der Linux Kernel kommt ab Versionen größer 2.6.3 problemlos mit dem Gerät zurecht.
Um igotu2gpx kompilieren zu können sind im groben folgende Abhängigkeiten zu erfüllen:
– qt4
– boost
– libusb
– chrpath
– marble
– openssl
Dieses sollte sich auf jeder gängigen Distribution durch den Paketmanager erledigen lassen. Unterwegs kümmert sich nun der GT200e um die genaue Positionsbestimmung. Zuhause kann ich dann die Wegpunkte mit igotu2gpx in eine gpx Datei exportieren. Digikam verbindet dann die Bilder mit der passenden GPS Position. Dieses funktioniert über die Uhrzeit. Die Kamera hängt beim Knipsen eines Bildes automatisch die Uhrzeit an das Bild. Diese kann nun mit den Zeiten aus dem gpx Export verglichen werden. So lässt sich herausfinden an welcher Position man gerade beim Knipsen des Bildes gewesen ist. Vorausgesetzt die Kamera hat auch die richtige Uhrzeit und das richtige Datum.
Veraltet: StartSSL/StartCom wurde 2017 von allen Browsern als nicht mehr vertrauenswürdig eingestuft und hat den Betrieb eingestellt. Für kostenlose Zertifikate nimmt man heute Let’s Encrypt.
StartCom ist ein Unternehmen, das Software herstellt und als Zertifizierungsstelle digitale Zertifikate ausstellt. Seit Februar 2005 ist das Unternehmen als Zertifizierungsstelle tätig. Das bekannteste Produkt ist das kostenlose Class 1 X.509 SSL-Zertifikat „StartSSL Free“, das sowohl für Webserver (SSL/TLS) als auch für die E-Mail-Verschlüsselung (S/MIME) eingesetzt werden kann. Außerdem werden Class 2 Zertifikate und Extended-Validation-SSL-Zertifikate ausgestellt, für die eine kostenpflichtige Validierung Voraussetzung ist. StartCom-Zertifikate werden von allen modernen Browsern akzeptiert: Mozilla Firefox unterstützt sie schon ab Version 2.0, Opera seit Juli 2010, Apple Mac OS X ab Version 10.5 (Leopard) und Microsoft Windows seit September 2009; Apple Safari, Internet Explorer und Google Chrome greifen auf den Zertifikatspeicher des Betriebssystems zurück.
Das kostenlose Class1 Zertifikat stellt nur sicher das der angegebene Domainname existiert und anscheinend dem Halter des StartCom Accounts gehört. Aus diesem Grund findet sich natürlich auch nur der Domainname im Zertifikat. Wer seinen Namen auch noch im Zertifikat hinterlegen möchte kann dieses denn noch auf einem kostenlosen Weg schaffen. Ähnlich CAcert setzt StartCom auf das Prinzip des Web of Trust (wot). Es gibt bei StartCom ehrenamtliche Notare. Jeder Inhaber eines StartCom Accounts kann sich von diesen verifizieren lassen. Dazu findet sich im Webinterface des eigenen Accounts auf der Seite unter StartSSL WoT ==> WoT Netzwerk der Punkt Notarsucher. Hier findet sich über die Eingabe des eigenen Wohnortes oder halt der nächsten größeren Stadt schnell ein solcher Notar.
Wurde man von mindestens zwei dieser Notare bestätigt, kann man seinen Namen mit ins Zertifikat aufnehmen.
Eine solche Bestätigung findet immer über ein persönliches Treffen mit dem Notar statt. Bei diesem Treffen prüft der Notar anhand von zwei amtlichen Lichtbildausweisen ob der Name im Account mit dem auf den Ausweisen identisch ist.
Da die Root-Zertifikate dieser Zertifizierungsstelle bereits in den meisten großen Browsern und Betriebssystemen enthalten sind, kommt es bei diesen Zertifikaten (anders als bei z.B. CAcert.org) nicht zu „Fehlermeldunge“ bzw. Warnmeldungen im Zusammenhang mit den Zertifikaten. Vor allem dieser Umstand und natürlich da es kostenneutral ist, würde ich StartCom x.509 Zertifikate als einen optimalen Einstieg in diesen Themenbereich nennen können. Wer am Ende mehr will, wie eine Class 2 Zertifizierung oder bis hin zum Class 3 Zertifikat für Unternehmen, kann dieses schnell und günstig weiterführen. Wem das Class 1 Zertifikat ausreicht, dem stehen direkt nach der erfolgreichen Anmeldung schon fast alle Möglichkeiten der E-Mail Signatur / Verschlüsselung sowie SSL/TLS Verschlüsselte Serververbindungen offen.
Ich selbst bin bei StartSSL Notar und wie bei GPG / PGP oder CAcert.org bestätige ich auch hier gerne Identitäten auf Anfrage.
Ich bin nur sehr selten an einem Ort, an welchem ich keine Internetverbindung nutzen kann. Noch seltener würde ich genau dann eine Internetverbindung benötigen. Wenn es dann aber so ist, dann benötige ich sie wirklich!
Nun komme ich in der letzten Zeit immer mal wieder an diese Stelle und ärgere mich. Oft ist zwar ein Kollege oder Bekannter in der Nähe, mit so einem feinen Android Mobiltelefon, nur hilft mir dieses beim Arbeiten auf einer SSH-Shell weniger. Ja, es geht aber wirkliches Arbeiten geht nicht… Zudem bin ich ein Mensch der seinen Windowmanager benutzt, sprich viele offene Fenster. Auf so einem kleinen Mobilding ist mir mehr als eine kurze E-Mail oder etwas Google klicker klacker einfach zu aufwändig.
Das Handy also als Modem mit dem Rechner verbinden? So selten wie ich es im Moment benötige, mich direkt 1 Jahr an einen 20€/Monat Tarif meines Anbieters zu binden? Ne, so geht das nicht….
Vor kurzem war ich nun im Blödmarkt unterwegs. Da lagen in der Grabbelkiste so 15 Euronen O2 Prepaid USB-Sticks.
Dem etwas überforderten Fachberater für die Dinger konnte ich mit etwas Mühe die Information entlocken, dass ich über dieses Angebot „echtes“ Internet erhalte. Damit ist gemeint, dass ich SSH-Sessions auf beliebigen Ports öffnen kann und auch mein IPv6 Tunnelbroker funktionieren sollte. ….Nebenbei, habt ihr im Blödmarkt mal gefragt ob ihr über was auch immer eine Verbindung zu einen IPv6 Tunnelbroker aufbauen könnt? Macht mal, ist lustig.
HTTP / SMTP / IMAP mit und ohne SSL/TLS alles kein Problem!
Mit der 5 Tage x 3,50€ = 17,50€ Sollte einem Test nichts im Wege stehen. Keine Grundgebühr oder sonstige laufenden Kosten… Ich brauche es nicht, ich zahle es nicht. Wenn ich also feststelle das ich es doch oft und gut nutze, so dass sich einer der Knebelverträge des Anbieters meines Vertrauens lohnen würde, dann kann ich das Teil wegwerfen und mich bewusst knebeln lassen. Anderweitig habe ich eine tolle Lösung für den Notfall!
Beim Kauf habe ich jetzt nicht darauf geachtet ob das Teil nun unter bzw. mit meinem Linux (Gentoo) zusammenarbeitet. Den Fachberater im Blödmarkt wollte ich es nun nicht noch fragen, er schien jetzt schon von mir genervt zu sein!
Hey, gut wie ich bin, bekomme ich das Teil schon zum rennen (Boar ist diese Selbstüberschätzung nicht wiederlich?)!
Da meine Frau etwas von: „Rausgeworfenes Geld…. Überflüssiges Spielzeug… und du sitzt eh viel zu viel vor dem Computer!“ murmelte…. _MUSS_ das Teil einfach Laufen.
Tut es nur so ~out of the box~ nicht! Dass hat man nun also davon, man kauft im Blödmarkt halt nichts. Vor allem nicht ohne Verstand, oder gerade deswegen? Wie auch immer, so haben ich es ans Laufen bekommen!
Ich habe hier also den O2 Surfstick MF190 von der Firma ZTE.
Stecke ich diesen einfach in mein System ein und schaue mir an was der Kernel dazu sagt, sehe ich folgendes:
$ dmesg
usb 2-1: new high speed USB device using ehci_hcd and address 3
usb 2-1: New USB device found, idVendor=19d2, idProduct=0083
usb 2-1: New USB device strings: Mfr=3, Product=2, SerialNumber=4
usb 2-1: Product: ZTE WCDMA Technologies MSM
usb 2-1: Manufacturer: ZTE,Incorporated
usb 2-1: SerialNumber: P671A2TMED010000
scsi7 : usb-storage 2-1:1.0
scsi 7:0:0:0: CD-ROM ZTE USB SCSI CD-ROM 2.31 PQ: 0 ANSI: 2
sr1: scsi-1 drive
sr 7:0:0:0: Attached scsi CD-ROM sr1
sr 7:0:0:0: Attached scsi generic sg2 type 5
Der Stick wird also als USB-CDROM Laufwerk (hier liegt die Software für die Windows User) und USB-Festplatte (sofern eine MicroSD-Karte eingelegt ist, wäre es diese) erkannt.
Mal schauen was ein lsusb sagt:
$ lsusb
Bus 002 Device 004: ID 19d2:0083 ONDA Communication S.p.A
19d2 steht für den Hersteller und 0083 für das Gerät selbst. Google sagt 0083 ist der Stick aber im Modus (ich nenne es mal) Datenlaufwerk. Ich will aber Modem 🙂 Hierzu sagt Google man muss ein paar bestimmte Kommandos schicken und schon wechselt der USB-Stick seinen Modus. Findige Leute haben sich da schon einen Kopf zu gemacht und das Programm: usb_modeswitch geschrieben. Also soll emerge mal loslegen:
$ emerge usb_modeswitch
Solange er rechnet könnte ich meinen Kernel ja schon mal davon überzeugen das Gerät zu „ignorieren“. Dazu füge ich in die Datei: /usr/src/linux/drivers/usb/storage/unusual_devs.h folgende Zeilen ein:
Damit Geräte dieser Art überhaupt funktionieren können (und ich nach der Änderung in unusual_devs.h ja eh neu kompilieren muss) sollte die Kernelkonfiguration wie folgt angepasst werden:
Device Drivers ->
USB support --->
<M> OHCI HCD support (If not use Intel or VIA chipset)
<M> UHCI HCD (most Intel and VIA) support (If use Intel or VIA chipset)
<M> USB Serial Converter support --->
[*] USB Generic Serial Driver
<M> USB driver for GSM and CDMA modems
Network device support --->
<*> PPP (point-to-point protocol) support
<*> PPP support for async serial ports
Inzwischen ist usb_modeswitch fertig. Für meinen Stick muss ich leider noch etwas Handarbeit leisten. Denn in der Datei /lib/udev/rules.d/40-usb_modeswitch.rules müssen noch folgende Zeilen hinzugefügt werden:
Damit die neue Regel zur Anwendung kommen noch schnell ein:
$ udevadm control --reload-rules
Jetzt sollte es beim Einstecken vom Stick schon anders aussehen….
$ dmesg
usb 2-1: new high speed USB device using ehci_hcd and address 4
usb 2-1: New USB device found, idVendor=19d2, idProduct=0117
usb 2-1: New USB device strings: Mfr=3, Product=2, SerialNumber=4
usb 2-1: Product: ZTE WCDMA Technologies MSM
usb 2-1: Manufacturer: ZTE,Incorporated
usb 2-1: SerialNumber: P671A2TMED010000
usb-storage 2-1:1.0: device ignored
usb-storage 2-1:1.1: device ignored
usb-storage 2-1:1.2: device ignored
usb-storage 2-1:1.3: device ignored
usbcore: registered new interface driver usbserial
USB Serial support registered for generic
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial Driver core
USB Serial support registered for GSM modem (1-port)
option 2-1:1.0: GSM modem (1-port) converter detected
usb 2-1: GSM modem (1-port) converter now attached to ttyUSB0
option 2-1:1.1: GSM modem (1-port) converter detected
usb 2-1: GSM modem (1-port) converter now attached to ttyUSB1
option 2-1:1.2: GSM modem (1-port) converter detected
usb 2-1: GSM modem (1-port) converter now attached to ttyUSB2
usbcore: registered new interface driver option
option: v0.7.2:USB Driver for GSM modems
Wohooo ein GSM Modem. Was sagt lsusb?
$ lsusb
Bus 002 Device 004: ID 19d2:0117 ONDA Communication S.p.A.
OK, der Stick wird nun also als Modem erkannt, die Datenlaufwerke werden ignoriert und ich könnte mich ja mal um eine Interneteinwahl kümmern, oder? Nötig ist dafür ppp und (weil es so schön einfach ist) wvdial. Emerge muss das wieder für mich erledigen:
$ emerge ppp wvdial
Nach kurzer Zeit ist er fertig. Nun lege ich mal das ppp Device an:
$ mknod /dev/ppp c 108 0
*umschau* ich habe ja so ein paar Tests hinter mir und Scripte können da knallhart sein. Wenn man denen sagt: „Probiere mal bis geht…“ Dann tun die das auch wenn sie 100 mal die falsche PIN eingeben. Man kann lange suchen bis man darauf kommt die PUK einzugeben. SEHR lange. Ich habe also die PIN-Eingabe abgeschaltet!
wvdial ist schnell konfiguriert. Meine Konfiguration für O2 schaut so aus:
Stecke ich nun meinen (mit abgeschalteter PIN-Eingabe) Surfstick ins Notebook beginnt er rot zu leuchten. Ist der Stick betriebsbereit und hat Netz beginnt er grün zu leuchten 🙂 Einfach, oder?
Die Einwahl funktioniert nun recht einfach mit wvdial:
$ wvdial o2
--> WvDial: Internet dialer version 1.61
--> Cannot get information for serial port.
--> Initializing modem.
--> Sending: ATZ
ATZ
OK
--> Sending: ATQ0 V1 E1 S0=0 &C1 +FCLASS=0
ATQ0 V1 E1 S0=0 &C1 +FCLASS=0
OK
--> Sending: AT+ZOPRT=5
AT+ZOPRT=5
OK
--> Sending: AT+CGDCONT=1,"IP","pinternet.interkom.de"
AT+CGDCONT=1,"IP","pinternet.interkom.de"
OK
--> Modem initialized.
--> Sending: ATD*99#
--> Waiting for carrier.
ATD*99#
CONNECT 7200000
--> Carrier detected. Starting PPP immediately.
--> Starting pppd at Tue Mar 8 20:35:06 2011
--> Pid of pppd: 22068
--> Using interface ppp0
--> local IP address 10.151.95.132
--> remote IP address 10.64.64.64
--> primary DNS address 193.189.244.225
--> secondary DNS address 193.189.244.206
Nun sollte man auch schon online sein. Ein kurzer Blick auf die Interfacekonfiguration zeigt:
Ich wollte wissen, wie gut sich Daten mit Linux-Bordmitteln wiederherstellen lassen. Also habe ich eine alte Festplatte genommen und es systematisch ausprobiert. Erst normal gelöschte Dateien, dann ein RAW-Image, und am Ende habe ich die Platte physisch zerstört, um zu sehen was ddrescue und PhotoRec aus den Trümmern holen.
Vorbereitung: Testplatte befüllen
Die älteste funktionierende Platte aus meinem Fundus: eine WD Expert 136BA. Erst komplett mit Nullen überschrieben, dann partitioniert und als NTFS formatiert:
Die Optionen: -u für Undelete-Modus, -m '*.*' für alle Dateien (mit -m '*.doc' könnte man nur Word-Dateien holen), -p 100 für nur zu 100 % wiederherstellbare Dateien, -d /test als Zielverzeichnis. Bei Bildern könnte man den Prozentsatz auch niedriger setzen, Teile eines JPEG sind besser als nichts.
Alle 154 Dateien kamen vollständig zurück. Einzige Einschränkung: Dateien mit gleichem Namen werden nicht überschrieben. Sollte man beachten oder per Script lösen.
Arbeiten mit RAW-Images
Im Ernstfall arbeitet man nie mit der Originalplatte. Sobald man den Datenverlust bemerkt, am besten sofort den Stecker ziehen. Jeder weitere Betrieb, selbst ein Herunterfahren, kann die gelöschten Daten überschreiben. Also erst ein RAW-Image ziehen:
ntfsundelete funktioniert genauso mit dem Image-File. Gleiche Ergebnisse, gleiche Wiederherstellung. Genau so soll es sein.
Die Festplatte zerstören
Jetzt wird es interessant. Mich hat natürlich interessiert, was bei einer physisch beschädigten Platte passiert. Also Platte wieder voll gemacht und dann aufgeschraubt.
Vorsichtig ein paar Kratzer mit dem Schraubendreher auf die Magnetscheiben gesetzt. Nicht zu viel, aber genug, dass einige Gigabyte unlesbar sein sollten.
ddrescue: 52 Stunden an einer zerkratzten Platte
Platte wieder zugeschraubt und ddrescue drauf losgelassen:
Nach meiner kleinen Kratzorgie hat ddrescue 52 Stunden an der Platte gefummelt, bevor es durch war.
Wann zum Profi?
Wenn einem die Daten mehr als 3.000 Euro wert sind, sollte man einen professionellen Datenretter aufsuchen. Die nehmen zur Diagnose oft um die 90 Euro und sagen dann, was es wirklich kostet. Bei einem Fall aus 2010 hat ein Kunde mit einer 160 GB HDD und Headcrash einen Kostenrahmen von 15.000 bis 18.000 Euro genannt bekommen. Jede Bewegung an der Platte kann weitere Daten zerstören.
Ich habe selbst mal bei einer Seagate SCSI-Platte die komplette Elektronik von einer baugleichen getauscht, weil sie keinen Spin-Up mehr machte. Lief danach wieder, als wäre nie etwas gewesen. Auch ein Tausch der Schreib-/Leseköpfe hat einmal funktioniert, nachdem einer halb abgerissen war. Die Platte sprang genau ein Mal an, ich konnte sichern, beim nächsten Versuch ging nichts mehr. Solche Experimente klappen nicht immer. Hat man an der Platte herumgefummelt, hat oft auch der Profi keine Chance mehr.
PhotoRec: Dateien anhand des Headers retten
Das ddrescue-Image ließ sich in meinem Fall nicht mehr mounten. Durch die Kratzer war auch das NTFS-Dateisystem total im Eimer, selbst fsck half nicht. Also brauchte ich ein Programm, das Dateien anhand ihres Headers wiederherstellen kann: PhotoRec.
photorec datenrettung_parti_sicher.img
PhotoRec hat erstaunlich viele Dateien aus der zerkratzten Platte zurückgeholt. Wer sich das Programm anschaut, sollte sich auch TestDisk vom gleichen Entwickler ansehen. Damit lassen sich gelöschte Partitionen rekonstruieren und noch vieles mehr.
Update 2026: Was bei SSDs und NVMe anders ist
Der Beitrag oben ist von 2010 und das merkt man. Die meisten Endgeräte haben heute keine drehende Festplatte mehr, sondern eine SSD oder NVMe. Das ändert das Spiel komplett.
Sobald TRIM oder UNMAP aktiv sind, meldet das Dateisystem dem Controller, welche Blöcke nach einem DELETE freigegeben sind. Der Controller löscht diese Zellen oft sofort oder beim nächsten Garbage-Collection-Lauf. Ergebnis: ntfsundelete oder PhotoRec laufen ins Leere, weil die Daten physisch schon weg sind. Wer ein Recovery-Tool an einer SSD ansetzt, sollte das Laufwerk vorher per Software-Hardware-Befehl ruhigstellen, also nicht mounten und keine TRIM-Befehle mehr absetzen lassen.
NVMe legt noch eine Schaufel drauf. Mit nvme sanitize oder nvme format --ses=1 ist nach Sekunden alles weg, kryptografisch sauber. Das ist gut für Hardware-Verkauf oder -Entsorgung, ein Albtraum für Recovery.
Verschlüsselte Datenträger sind ein eigenes Kapitel. BitLocker, LUKS, FileVault, APFS-Encryption: ohne den Schlüssel oder das Recovery-Passwort hilft kein Tool der Welt. Bei einem PCB-Defekt einer SSD wird es zusätzlich kritisch, weil moderne Controller die Verschlüsselung intern anders handhaben als der Host. Selbst wenn die NAND-Chips noch heile sind, bekommt ohne den passenden Controller-State niemand mehr Klartext zurück. Mit anderen Worten: ein einfacher PCB-Tausch wie bei meiner alten Seagate SCSI ist 2026 nicht mehr drin, schon gar nicht im Selbstbau.
Update 2026: Backup schlägt Recovery
Die ehrliche Wahrheit nach 15 Jahren: ich habe nicht mehr ein einziges Mal in echt eine Datenrettung gemacht. Nicht weil die Tools schlechter geworden wären, sondern weil ich Backups habe. Wenn eine Platte stirbt, ziehe ich den letzten Snapshot zurück und gut ist. Recovery ist die Notlösung, wenn das Backup fehlt oder kaputt ist.
Was ich heute tatsächlich nutze:
ZFS-Snapshots mit zfs-auto-snapshot: stündlich, täglich, wöchentlich. Auf der Workstation und im Storage. Versehentliches rm -rf oder ein Crypto-Trojaner sind in Sekunden zurückgerollt.
zfs send / zfs recv auf einen externen Pool und auf ein Offsite-System. Inkrementell, verschlüsselt mit zfs send -w, vollautomatisch per Cron.
Borg / Restic für die Geräte, die kein ZFS sprechen. Deduplizierend, verschlüsselt, push und pull-Modi.
Time Machine auf dem MacBook, weil es genau das macht was es soll.
Die 3-2-1-Regel ist alt und immer noch korrekt: drei Kopien, auf zwei verschiedenen Medien, eine davon räumlich getrennt. Cloud-Sync wie Dropbox, OneDrive oder Google Drive ist dabei kein Backup. Wenn dort etwas gelöscht wird, ist es im selben Moment auch lokal weg. Ein Backup ist immer eine Kopie, die nicht automatisch mitläuft.
Update 2026: Tools und Preise heute
Die guten Nachrichten zuerst: alle vier Tools aus dem Original werden weiter aktiv gepflegt.
GNU ddrescue: aktuell Version 1.28, läuft auf jedem Linux/BSD/macOS. Mit ddrescueview gibt es eine GUI, die das Mapfile visualisiert.
PhotoRec / TestDisk: Version 7.2, von cgsecurity.org. Versteht inzwischen über 500 Dateiformate, auch moderne wie HEIC, AVIF, MKV-Container.
ntfsundelete: Teil der ntfs-3g/ntfsprogs, weiterhin im Standard-Repository jeder Distribution.
SMART und Vorhersage: smartctl aus smartmontools ist Pflicht. Die Werte Reallocated_Sector_Ct, Current_Pending_Sector und Offline_Uncorrectable sagen oft schon Tage vorher, dass die Platte sterben wird.
Bei den Preisen für professionelle Datenrettung hat sich einiges getan. Die Diagnose liegt heute meist zwischen 50 und 200 Euro, oft sogar kostenlos wenn man den Auftrag erteilt. Die eigentliche Rettung ist stark gestaffelt: einfache Logikfehler ab etwa 300 Euro, mechanische Defekte mit Reinraum ab 800 bis 1.500 Euro, schwere Schäden mit Plattentausch und Adaption-Tabellen können immer noch vier- bis fünfstellig werden. Anbieter wie CBL, Ontrack oder Stellar geben kostenlose Erstdiagnose, das nutze ich heute auch wenn nur ein Verdacht im Raum steht.
Ein Hinweis noch: SSD- und NVMe-Recovery ist deutlich teurer als HDD-Recovery, weil der Reinraum-Aufwand durch teure Equipment-Setups für NAND-Reads ersetzt wird. Wer also wirklich wichtige Daten auf einer SSD hatte, fährt mit einem soliden Backup-Konzept finanziell und nervlich besser.
Fazit
Für normal gelöschte Dateien auf NTFS reicht ntfsundelete. Bei physischen Schäden ist ddrescue das Mittel der Wahl, um erst ein Image zu sichern. Und wenn das Dateisystem komplett zerstört ist, kann PhotoRec anhand der Datei-Header noch erstaunlich viel retten. Wichtigste Regel: Nie an der Originalplatte arbeiten, immer zuerst ein Image ziehen.
2026 gilt das alles weiter, mit zwei Einschränkungen. Auf SSDs und NVMe kommt man oft schon gar nicht mehr an die Daten. Und: das beste Recovery ist das, das man nie machen muss. Backup, Backup, Backup.
DNSSEC (Domain Name System Security Extensions) schützt DNS-Antworten vor Fälschung. Ein anfragender Resolver kann damit prüfen, ob die gelieferten Zonendaten tatsächlich vom autorisierten Nameserver stammen und unterwegs nicht verändert wurden. DNSSEC wurde als Mittel gegen Cache Poisoning entwickelt — Serverauthentifizierung findet nicht statt.
Die Vertrauenskette
Was mich beim ersten Lesen zu DNSSEC durcheinandergebracht hat, war das Umherwerfen mit Begriffen: KSK, ZSK, DNSKEY, RRSIG, DS. Im Grunde ist es einfach:
Der KSK (Key Signing Key) hat eine Aufgabe: den ZSK unterschreiben. Der KSK wird als DS-Record in der übergeordneten Zone hinterlegt. Der ZSK (Zone Signing Key) hat auch nur eine Aufgabe: die eigentlichen Zonendaten unterschreiben.
Es beginnt bei der Root-Zone. Die Root-Server wissen, welche Nameserver für die TLDs zuständig sind. Die TLD-Server wissen, welche Nameserver für die einzelnen Domains zuständig sind. Jede Ebene signiert ihre Zone und veröffentlicht den DS-Record der Ebene darunter. So entsteht eine durchgehende Kette vom Root-KSK bis zu meiner Zone.
Will ein Angreifer dafür sorgen, dass www.kernel-error.org auf seinen Server zeigt, hat er zwei Möglichkeiten:
Er antwortet auf die Delegation-Anfrage mit seinem eigenen Nameserver.
Er antwortet mit gefälschter Absenderadresse schneller als der echte Server.
Mit DNSSEC kann der Resolver beide Angriffe erkennen — die gefälschte Antwort hat keine gültige Signatur.
DNSSEC in BIND aktivieren
Auf dem autoritativen Nameserver muss DNSSEC-Validierung aktiv sein. In modernen BIND-Versionen (ab 9.16) reicht im options-Block:
options {
dnssec-validation auto;
};
auto bedeutet, dass BIND den eingebauten Root-Trust-Anchor nutzt und diesen bei KSK-Rollovers automatisch aktualisiert (RFC 5011). Der alte dnssec-enable yes wurde in BIND 9.18 entfernt — DNSSEC ist seitdem immer aktiv.
Zone signieren — der moderne Weg
Seit BIND 9.16 gibt es dnssec-policy. Damit übernimmt BIND die Schlüsselerzeugung, das Signieren und den Key-Rollover vollautomatisch:
zone "kernel-error.org" {
type primary;
file "kernel-error.org";
dnssec-policy default;
inline-signing yes;
};
Die default-Policy verwendet ECDSAP256SHA256 (Algorithmus 13) — schneller und sicherer als das früher übliche NSEC3RSASHA1 mit 4096-Bit-Schlüsseln. inline-signing yes bedeutet: BIND signiert die Zone im Speicher, die Zonendatei auf der Platte bleibt unsigniert und lässt sich wie gewohnt bearbeiten.
Zone manuell signieren
Wer mehr Kontrolle will oder eine ältere BIND-Version hat, kann die Schlüssel von Hand erzeugen. KSK erstellen:
$ dnssec-keygen -a ECDSAP256SHA256 -f KSK -n ZONE kernel-error.org
Kkernel-error.org.+013+12345
ZSK erstellen:
$ dnssec-keygen -a ECDSAP256SHA256 -n ZONE kernel-error.org
Kkernel-error.org.+013+67890
Die öffentlichen Teile (*.key) in die Zonendatei einbinden und signieren:
$ cat Kkernel-error.org.+013+*.key >> kernel-error.org
$ dnssec-signzone -S -K /pfad/zu/keys -o kernel-error.org kernel-error.org
Verifying the zone using the following algorithms: ECDSAP256SHA256.
Zone signing complete:
Algorithm: ECDSAP256SHA256: ZSKs: 1, KSKs: 1 active, 0 stand-by
kernel-error.org.signed
Dann BIND anweisen, die signierte Zonendatei zu laden. Nach jeder Änderung an der Zone muss neu signiert werden — oder man nutzt inline-signing, dann entfällt das.
DS-Record beim Registrar einreichen
Der öffentliche KSK muss als DS-Record in der übergeordneten Zone landen. Bei der DENIC (.de) und den meisten TLD-Registries gibt es dafür ein Webinterface beim Registrar. Man schickt den öffentlichen KSK hin, der Registrar erstellt daraus einen DS-Record und veröffentlicht ihn neben den NS-Records.
Ob der DS-Record gesetzt ist, lässt sich prüfen, indem man die TLD-Nameserver direkt fragt:
DNSSEC-Signaturen machen DNS-Antworten deutlich größer als die 512 Bytes, die klassisches DNS über UDP erlaubt. EDNS (RFC 6891) hebt dieses Limit auf. Das ist seit 1999 spezifiziert, aber manche Firewalls und Billig-Router haben damit immer noch Probleme — sie filtern große UDP-Pakete oder EDNS-Optionen.
Wichtig: Gehen die Schlüssel verloren oder die signierte Zonendatei brennt ab, hat man ein Problem. Vor jeder großen Änderung (Key-Rollover, Algorithmus-Wechsel) immer die längste TTL der Zone abwarten. Sonst sind gecachte Antworten mit der alten Signatur noch gültig, während die neue Signatur schon aktiv ist — die Zone wird temporär nicht validierbar.
Meinen „analogen“ DNSSEC-Masterplan dazu habe ich mir damals aufgezeichnet:
Was man auf DNSSEC aufbauen kann
Wenn die Zone signiert ist, lassen sich darüber weitere Sicherheitsmechanismen verteilen:
DANE/TLSA — TLS-Zertifikate per DNS verifizieren, unabhängig von CAs.
Jabber, offiziell XMPP, ist ein offenes Messaging-Protokoll. Kein zentraler Betreiber, kein Vendor Lock-in, kein Unternehmen das die Nutzungsbedingungen diktiert. Jeder kann einen eigenen Server betreiben, und die Server sprechen untereinander. Wie E-Mail, nur für Messaging.
Warum ein eigener Server
Bei kommerziellen Messengern gibt man mit der Nutzung Rechte an seinen Inhalten ab. Die AGBs von AIM, ICQ, MSN und Co. erlaubten dem Betreiber die Verwertung aller Inhalte die über den Dienst liefen. Die Dienste gibt es größtenteils nicht mehr, aber das Muster ist geblieben. Ein eigener Server bedeutet: Eigene Regeln, eigene Daten, eigene Entscheidung welche Module aktiv sind.
Die Vorteile von XMPP: Open Source, Verschlüsselung per TLS, kein Single Point of Failure, und eine riesige Auswahl an Clients für jede Plattform.
Openfire
Nach Tests mit jabberd, ejabberd und Openfire bin ich bei Openfire hängengeblieben. Für einen kleinen Server mit Familie und Freunden bringt Openfire alles mit: Weboberfläche zur Administration, Plugin-System, IPv6-Support und einfache Installation unter Debian. Für einen großen öffentlichen Server würde ich anders entscheiden, aber für meinen Zweck passt es.
Um zu zeigen wie flexibel XMPP ist: Mein Siemens Gigaset C470IP hat ein Mobilteil C47H mit eingebautem Messenger. Das Telefon verbindet sich mit dem Jabber-Server und kann Nachrichten empfangen und verschicken. Ohne App, ohne Smartphone, direkt auf dem DECT-Telefon.
Der Jabber Messenger des Gigaset C47H ist online und mit dem Server verbunden.
Am Gigaset C47H ist eine neue Jabber-Nachricht angekommen.
Die Nachricht wird am Mobilteil gelesen. Antworten funktioniert genauso.
Pahhh da boote ich ganz cool meine Linux-Schüssel, hänge die USB-Platte ein und passe meine exports für einen ganz einfachen und schnellen Share an:
ZFS ist nun schon ein paar Jahre alt, denn noch habe ich bisher noch kein Dateisystem gefunden welches im wirklich das Wasser reichen kann. Hier und da in Detailvergleichen, keine Frage aber
alles in allem „no way“. Bei seiner Einführung hat SUN etwas von unkaputtbar erzählt. Titanic lässt grüßen? Auf keinen Fall… Ich habe es noch nicht geschafft ein ZFS zu zerlegen. Egal wie oft der Strom ausfällt oder der Rechner einen Reset bekommt. Ohne Hammer bzw. echten Hardwaredef. läuft das System einfach weiter.
Wie auch immer…. Vor ein paar Tagen ist nun die Entwicklerversion oi_151a erschienen. Die Version 148 war schon viel versprechend. Diese Version lief auch immer im Dualboot neben meinem Gentoo. Da sie denn noch viel Schleifarbeit an vielen Stellen braucht hatte sie eher ein passives leben 🙁
Dieses hat sich jetzt nach einem kurzen Test geändert. Gentoo verschwindet in eine Virtualbox VM auf dem Solarissystem und dann geht es los.
Ich liste in laufe der Zeit mal in einem Untermenü auf was mir so aufgefallen ist bzw. was anderen vielleicht weiterhelfen könnte.
OpenIndiana der fork von OpenSolaris und Solaris? Ja und nein, denn Sun hat sein Verspechen, die OpenSolaris-Entwicklung für die Gemeinschaft zu öffnen, nicht eingehalten hat und da Oracle nach der Übernahme von Sun zunehmend Teilprojekte einstellte, haben Mitglieder der OpenSolaris-Entwickler-Gemeinschaft am 3. August 2010 die Gründung des Projektes Illumos zur Entwicklung eines wirklich freien Open-Source-Solaris bekanntgegeben. OpenIndiana hat nun diese Basis.
Ich hatte auf einer meiner Maschinen ein kleines Problem mit der LiveCD. Diese bliebt beim booten einfach hängen und dieses ohne erkennbaren Grund. Zumindest konnte ich auf den Konsolen nichts erkennen und einen Logfile gibt es so ja erstmal nicht :-/ Bei einem Linux Live System würde man ja nun erstmal Kernel Optionen wie: noacpi / noapic / acpi=off oder so ein Geschlönz probieren, aber hier????
Ich habe im Zusammenhang mit der OpenIndiana LiveDVD ein paar Bugs und Probleme im Zusammenhang mit USB gelesen. Hier scheint das System noch etwas „anfällig“ zu sein 🙁 Wie auch immer nach einigen Tests viel mit nichts besseres mehr ein als einfach den USB-Kontroller im BIOS zu deaktivieren. Nur um das USB-System auszuschließen versteht sich… Tja, was soll ich sagen? USB im BIOS ausschalten und LiveDVD (der OpenIndiana Live USB-Stick ist dann natürlich nutzlos) einlegen. Schon versagen ordnungsgemäß USB-Tastatur und USB-Maus ihren Dienst, OpenIndiana Bootet aber sauber hoch. Spannenderweise erkennt das gebootete System den USB-Kontroller wieder und somit auch Maus, Tastatur oder sonstige USB-Sticks. Dieses Verhalten führte zwar bei mir zu etwas Stirnrunzeln, bringt mir denn noch ein funktionierendes System.
