Author Archives: вяоӣсо

About вяоӣсо

I'm a computer kid of the 80', not born but raised in good old' germany, playin' games, makin' music & lovin' the blues. My career started at an age of 10 in a shopping mall where they sold computers too. It was the first time ever i've seen such an electronic monster and was fascinated instantly. Later on i've learned my first programming skills (Basic) with a friend's Sinclair ZX 81. Yes, that one with the strange plastics keyboard. After that i got some experience with a Schneider CPC464 and the Commodore C64 until i fell in love with the Commodore Amiga, a machine with 4096 different colors which sounds nowadays to most like black'n'white tv's sounded to me at that time. We played a lot of games like Decathlon, The Last V8, Impossible Mission, Elite, Mega'lo'Mania, Xenon, Speedball or Chaos Engine and ruined a lot of those Competition Pro Joysticks. My favourites were mostly games by Sensible Software, Bitmap Brothers or Rainbow Arts. What i liked the most about that machine was it's AmigaOS, it's operating system was ahead of it's time. On this machine i learned my first assembler language (m68k) and the hardware internas. I watched the decline of Commodore with a tear in my eye and at some point i went over to usual business and my first PC and learned it's beastly manners.

.net == Open Source?

Super, zwar kommt das ungefähr zehn Jahre zu spät aber immerhin, besser spät als nie. Vielleicht wird +Microsoft auf seine alten Tage vernünftig, warten wir es mal ab oder hängt das eher mit dem neuen Führungsstil von +Satya Nadella zusammen?
Diese Entscheidung war lange überfällig und wird +Xamarin ‘s Mono Framwork (womöglich auch unter Linux?) einen Schub geben insbesondere wenn man nicht mehr Angst haben muß verklagt zu werden denn das war bisher der größte Hemmschuh für potentielle Entwickler mit dem Ziel sich die Platformunabhängigkeit von .net tatsächlich nutzbar zu machen. Nichtsdestotrotz eine gute Entscheidung und ein richtiger Schritt

https://heise.de/-2452033

Telekom VDSL Anschluß nach Annex J

Seit einiger Zeit bietet die Telekom sogenannte IP-basierte DSL Anschlüsse nach G.992.(3|5) Annex J ITU Standard an, das bedeutet dass auch das untere Frequenzband bis 25 kHz zur Datenübertragung im Upstream genutzt werden kann wo sich früher das gute, alte, analoge Telefon- (POTS) und ISDN Signal befand.
Früher auch bekannt als Call & Surf Comfort (Speed, …) nennt sich der Tarif heute MagentaZuhause (S|M|L) und verbannt die Telefonie mit VoIP endgültig in das digitale Reich der Bits & Bytes, daher ist ein Splitter nicht mehr erforderlich. Die Telefondose selbst redet nur noch in digital, damit man allerdings die volle Bandbreite genießen kann benötigt man ein Annex J-fähiges DSL Modem welches einen Upstream mit bis zu 5 Mbit/s und einen Downstream bis zu 100 Mbit/s ermöglicht. In der Regel sind solche Modems in der Lage viel mehr Bandbreite als die besagten 5 Mbit/s zu liefern allerdings gibt oft das Frequenzband des alten Klingeldrahts nicht mehr her.

Frequenzbänder der unterschiedlichen Annex Standards.

Die meisten älteren Modems beherrschen lediglich schmalere Frequenzbänder nach älteren Annex Standards daher möchte ich hier einige Erfahrungen mit Geräten betrachten, die ein Modem nach Annex J Standard enthalten.

Linux als Mitglied einer Windows Domäne

Heute möchte ich die Anbindung eines Linux Host als vollwertiges Domänenmitglied in eine Windows Server 200x Active Directory Domäne behandeln. Dabei kommt einem vermutlich Samba in den Sinn jedoch dient dies eher der Dateifreigabe in einem Netzwerk, bei einfachen Windows-Arbeitsgruppen Netzwerken ist dies auch recht schnell bewerkstelligt allerdings mit einigen Einschränkungen. Die Benutzer und Gruppen, die Identifiktaion der einzelnen Hosts eines Netzwerks, verschiedenen Berechtigungsysteme etc. alles muß von Hand verwaltet werden.
Eine Windows Active Directory-Domäne bietet hier verschiedene Vorteile. Alle Entitäten werden in einer LDAP Datenbank auf dem Windows Server innerhalb eines sogenannten Realms (vgl. Domäne) verwaltet, dabei erhalten alle Maschinen ihre verschiedenen Berechtigungen vom Windows Server. Für Windows Maschinen ist das nichts besonderes aber man kann sowas auch mit einer Linux Maschine machen dabei sollen folgende Kriterien erfüllt sein:

  • Nutzung der Kerberos Authentifizierung. Der Linux Host soll ein Domänen Mitglied mit eigener Machine Credential sein um sich so auch passwortlos am Domänennetzwerk anmelden zu können. So wie das Windows Maschinen auch machen.
  • Benutzer und Gruppen des Realms (vgl. Domäne) sollen dem Linux Host bekannt sein und auch als Besitzer für Dateien und Ordner des Linux Hosts gesetzt werden können.
  • Linux spezifische Accountdaten wie UID, GID, Homepath, Shell, etc, sollen im Active Directory verwaltet werden.
  • Der Linux Host soll Dienste anbieten die den Single sign-on Mechanismus der Domäne verwenden können und bei dem sich auch Benutzer der Domäne auf Diensten des Linux Hosts anmelden können z.B. Samba oder NFS Freigaben nutzen oder per SSH anmelden, etc.

Quellen:
The Official Samba 3.5.x HOWTO and Reference Guide
http://web.mit.edu/kerberos

Festplatte auswerfen (Hot-Swap|eSata)

Um USB Sticks auszuwerfen gibt es das eject-Kommando. Möchte man aber eine Festplatte z.B. per Hot-Swap oder am eSata Quick-Port auswerfen kann man folgendes machen:

# echo "1" >/sys/block/sda/device/delete

Wobei die Angabe sda die Platte angibt die ausgeworfen werden soll. Ein kleine Bash-Funktion mit entsprechenden Sicherheitsabfragen läßt sich z.B. leicht in der .bash_aliases unterbringen:

function ejectHD()
{
    [ -z $1 ] && echo "Usage: ejectHD BLOCK_DEV_NODE (eg: sda, sdb, ...)" && return 1
    [ ! -e "/sys/block/$1" ] && echo "Device node not ejectable." && return 2
    read -s -n1 -p ">> Attention! Ejecting '$1'! Sure? (y|N) "
    [[ $REPLY =~ (y|Y) ]] && echo "1" >/sys/block/$1/device/delete && echo "... done" && return 0         
    echo "... aborted."
}

Zuvor sollte man allerdings sicherstellen das man alle Dateisysteme per unmount abgerissen hat sonst kann es schnell zu Datenunfällen kommen.

MBR sichern und untersuchen

Möchte man einen genaueren Blick auf den MBR einer Platte werfen bietet sich zunächst ein Dump der ersten 512 Bytes einer Platte an:

> dd if=/dev/sda of=mbr.bin bs=512 count=1

Anschließend kann man sich diese Datei mit dem File-Kommando ausgeben lassen:

> file mbr.bin
mbr.bin: x86 boot sector;
partition 1: ID=0×83, active, starthead 1, startsector 63, 40949622 sectors;
partition 2: ID=0×82, starthead 254, startsector 40949685, 2088450 sectors;
partition 3: ID=0x8e, starthead 254, startsector 43038135, 74172105 sectors, code offset 0×48

Man kann die Datei auch dahernehmen und sie wieder auf eine andere Platte duplizieren aber vorsicht, mit solchen Aktionen lassen sich Platten in NullKommaNix unwiderruflich schraddeln. Die Daten sind zwar faktisch unberührt aber ohne die korrekten Partitionsinformationen nicht mehr zugänglich.
Möchte man nur den boot loader ohne die Primärpartition clonen, kopiert man nur die ersten 446 bytes des MBR anstatt der 512:

> dd if=mbr.bin of=/dev/[DRIVENODE] bs=446 count=1

Wer die Windows Installation einer kompletten physischen Platte samt aller Partitionen auf eine neue kopieren möchte erneuert mit diesem Kommando den boot loader auf der Zielplatte ohne die Partitionstabelle zu überschreiben!
Dies löst Bootprobleme wenn nach der BIOS Sequenz lediglich die Nachricht Loading Operating System erscheint, der Bootprozess dann aber einfach eingestellt wird.

Quellen:
Easy way to read MBR?
Disk Cloning

Partitionsschema duplizieren

In manchen Situationen möchte man ein Platte exakt genauso partitionieren wie man es zuvor schon bei einer anderen gemacht hat. Man könnte per fdisk, gdisk, parted, etc. sich jedesmal durch die Menüs hangeln, das kann aber u.U. langwierig sein. Hierfür bietet sich sfdisk an:

~$ sfdisk -d /dev/sdc | sfdisk /dev/sdd
~$ # cloning partition schema

Insbesonders bei RAID Konfiguration bei denen ein Reihe von Geräten gleich partitioniert sein sollten ist das hilfreich und funktioniert analog auch für GPT Partitionierungsschema mit dem sgdisk Kommando. Ggfs. auch hier den Disk Identifier überprüfen. Das Partitionsschema läßt sich auch in eine Datei zwischenspeichern:

~$ sfdisk -d /dev/sdc > partition.sfdisk
~$ ...
~$ sfdisk /dev/sdc < partition.sfdisk

Achtung!
Beim dupliziren von Partitionsdaten orientiert sich der Pipe-Vorgang unter sfdisk in der Reihenfolge Quelle, Ziel. Beim Duplizieren von Partitionsdaten mit sgdisk hingegen wird keine Pipe verwendet sondern eine Argumentübergabe die genau umgekehrt angeordnet ist!

~$ sgdisk -R /dev/sd[Y] /dev/sd[X]
~$ # with Y=Destination & X=Source
~$ sgdisk -G /dev/sd[Y]
~$ # create a new disk GUID!

Den Disk Identifier kann auch mit fdisk für MBR-basierte Partitionsschemata ändern:

~$ fdisk /dev/sd[Y]
Command (m for help): x

Expert command (m for help): i
New disk identifier (current 0x00112233): deadbeef
Expert command (m for help): w

Achtung!
Stellt man fest dass der Disk Identifier sich auch nach dieser Prozedur nicht wirklich verändert hat, liegt das an einem recht alten Bug im fdisk-Kommando. Wenn man nichts weiter ändert als den Disk Identifier so erkennt fdisk dies manchmal nicht als Veränderung der Partitionstabelle an und schreibt einfach gar keine Daten, um das zu umgehen kann z.B. den Partitiontyp irgendeiner Partition auf einen beliebigen Wert setzen und ihn anschließend gleich wieder auf den alten Wert zurücksetzen. Das hat keine wirkliche Änderung der Partition zur Folge sorgt aber dafür das fdisk Änderungen nun auch tatsächlich schreibt.

Quelle:
automated disk partitioning with sfdisk

Disk Clone per dd

Unter Linux lassen sich physische Datenträger samt Partitionsinformationen als Bit-by-Bit-Copy leicht klonen:

> dd if=/dev/sd[X] of=/dev/sd[Y]
#X=Source drive, Y=Target drive

Solche Vorgänge dauern je nach Diskgröße länger u.U. die ganze Nacht daher empfiehlt es sich den Kopiervorgang asynchron z.B. per Screen anzustarten. Danach liegt eine exakte Kopie vor, bei der allerdings auch der Disk Identifier geklont wurde, dies bringt die Partitions- bzw. Geräteerkennung des Linux Kernels etwas durcheinander weil nun zwei physische Geräte mit ein und derselben Identifikation vorliegen. Man sollte das ändern wenn man Quell und Zielgerät weiterhin in einem System betreiben möchte.

> fdisk -l /dev/md1
[...]
Disk identifier: 0x000b1799

    Device Boot      Start         End      Blocks   Id  System
/dev/md1p1   *          63  1953520064   976760001    7  HPFS/NTFS/exFAT

> fdisk -l /dev/mapper/vg1-lv1 
[...]
Disk identifier: 0x000b1799

    Device Boot      Start         End      Blocks   Id  System
/dev/md2p1   *          63  1953520064   976760001    7  HPFS/NTFS/exFAT

> ### Huiaa! Two Disks same disk identifier

Unter den Experten Kommandos von fdisk findet man:

> fdisk /dev/md2

Command (m for help): x
Expert command (m for help): m
Command action
   [...]
   i   change the disk identifier
   [...]

Mit x gelangt man in der Expert Mode und mit i kann man einen neuen Disk Identifier angeben. Logischerweise sollte man eine Zahl wählen die bisher im System nicht existiert.

Expert command (m for help): i
New disk identifier (current 0x000b1799): 0xdeadbeef
Expert command (m for help): w

> ### Now let's see
> fdisk /dev/md2

[...]
Disk identifier: 0xdeadbeef

Analog funktioniert das auch mit gdisk statt fdisk wenn eine Partitionierung nach GPT vorliegt mit dem kleinen Unterschied das der Disk Identifier dort vom Typ GUID ist.

Mit dd läßt sich der dump auch in eine Image Datei schreiben anstatt die Kopie direkt auf eine andere Platte zu klonen. Nützlich für BackUps von z.B. Datenlaufwerken mit virtuellen Maschinen.

> dd if=/dev/sda dd of=/media/mySDA.img

Verwendet man irgendwann die Quellplatte andersweitig entsteht schnell der Wunsch die angelegte dd Image-Datei vorübergehend ins System einzubinden um z.B. Dateien auszutauschen.

> mount -t ext4 -o loop /media/mySDA.img /media/sda_image

Quelle:
askubuntu

RAID Superblock einer physischen Disk ausnullen.

Möchte man eine physische Disk die Teil eines mdadm RAIDs gewesen ist wieder neu partitionieren und untersucht die Disk mit dem Disks Tool (palimpsest) sieht man eine Partition vom Typ Linux RAID. Neben gewöhnlichen Partitionsmarkierungen befindet sich noch ein sogenannter Superblock der Metainformationen bzw. alle Details des RAID beinhaltet zudem die Festplatte mal gehörte. Ausnullen der ersten 512 bytes per dd um die Partitionsdaten zu zerstören ist hier aber nicht ausreichend da der Superblock für gewöhnlich am Ende des physischen Datenträgers untergebracht ist. Beim Versuch den Superblock zu entfernen kommt es manchmal zu einer nicht besonders hilfreichen Fehlermeldung:

# using sdd as an example:
> mdadm --misc --zero-superblock /dev/sdd
mdadm: Couldn't open /dev/sdd for write - not zeroing

Findet Linux beim Systemstart einen solchen Superblock wird dieser sofort an mdadm weitergereicht worauf dieser den RAID-Verbund im System einbindet also einen Device Node anlegt unter dem das Gerät im System ansprechbar ist auch dann wenn das eigentliche RAID im System gar nicht mehr existiert. Man sollte prüfen ob sich nicht klammheimlich ein neues RAID unter /dev/md127 findet:

> cat /proc/mdstat
[...]

md127 : active raid0 sdd5[0]
907026944 blocks super 1.2 128k chunks

unused devices: <none>

Aha! Hier muß man dieses erstmal per

> mdadm --stop /dev/md127

aus dem System auswerfen. Danach läßt sich auch der Superblock der RAID Partition ohne weiteren Fehler entfernen und man kann anschließend die Disk neu partitionieren.

Quellen:
Re: mdadm problem
Linux Software Raid Couldn’t Open …