unorganisiertes sammelsurium

07. 06

Nachdem ich schon mehrfach Anleitungen gesehen habe, nach denen die Litzen einfach übereinandergelegt oder verzwirbelt und dann verlötet werden, wollte ich hier nochmal die von mir präferierte Methode vorstellen. Diese wurde unter anderem in Mo 03/2011 als “Wrap-Technik” vorgestellt. Sie hat den Vorteil, dass die Lötstelle nicht gleichzeitig die mechanische Verbindung darstellt. Bei klassischen Stoßverbindungen wird oft die Lötstelle nicht genug erhitzt, da die Litze im kompletten Durchmesser auf Temperatur gebracht werden müsste, falls doch, zieht sich durch den Kapilareffekt gerne Lötzinn weiter hinein. Im ersten Fall erhält man eine kalte Lötstelle, im zweiten ist sie durch die Versteifung unnötig bruchgefährdet.

ca 1 und 3 cm weit die Isolierung entfernen

ca 2/3 der Adern auf die Länge des kurzen Stücks abknipsen

Die beiden Büschel ineinanderschieben

Das lange Büschel um die kurzen Wickeln, dabei kann das Halten mit einer Zange helfen…

…bis es vollständig umschlossen ist. Elektrisch ist durch das feste Wickeln der Kontakt hergestellt,…

…doch sichern wir das Ende noch mit etwas Lötzinn.

05. 12

Der Deutsche Bundestag hat im Rahmen des IT-Investitionsprogramms aus dem Konjunkturpaket II Mittel in Höhe von 24 Mio. Euro als Zuschuss zur Ausgabe von IT-Sicherheitskits an Bürgerinnen und Bürger bereitgestellt. Die Förderung der IT-Sicherheitskits durch den Bund soll dazu führen, dass eine signifikante Anzahl an Lesegeräten für die Nutzung elektronischer Chipkarten verfügbar ist.

In der seit gestern erhältlichen Computerbild (mit DVD) findet sich daher ein Basisleser (ohne Tastatur+DIsplay) sowie eine sogenannte "ComputerBild loginCard". Auch wenn ich noch keinen neuen Perso habe, und dies auch noch nicht so schnell vorhabe, kostenlose Technik zum Spielen ist nie verkehrt. Daher jetzt erstmal kurz die Schritte zum ans laufen bekommen, kurz zusammengefasst, unter Debian Testing:

> sudo aptitude install pcsc-tools pcscd libccid
> pcsc_scan
PC/SC device scanner   
V 1.4.16 (c) 2001-2009, Ludovic Rousseau 
Compiled with PC/SC lite version: 1.5.5
Scanning present readers...
Waiting for the first reader...found one
Scanning present readers...
0: REINER SCT cyberJack RFID basis 00 00

Sat Dec  4 23:33:38 2010
 Reader 0: REINER SCT cyberJack RFID basis 00 00
  Card state: Card removed, 

Sat Dec  4 23:33:42 2010
 Reader 0: REINER SCT cyberJack RFID basis 00 00
  Card state: Card inserted, 
  ATR: 3B 81 80 01 80 80

ATR: 3B 81 80 01 80 80
+ TS = 3B --> Direct Convention
+ T0 = 81, Y(1): 1000, K: 1 (historical bytes)
  TD(1) = 80 --> Y(i+1) = 1000, Protocol T = 0 
-----
  TD(2) = 01 --> Y(i+1) = 0000, Protocol T = 1 
-----
+ Historical bytes: 80
  Category indicator byte: 80 (compact TLV data object)
+ TCK = 80 (correct checksum)

Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3B 81 80 01 80 80
	Mifare DESFire

Sat Dec  4 23:33:50 2010
 Reader 0: REINER SCT cyberJack RFID basis 00 00
  Card state: Card removed, 

OpenSC mag den Reader auch, nur die Karte anscheinend nicht, aber im Wiki ist sie auch nicht erwähnt:

> sudo aptitude install opensc
> opensc-tool --list-readers --list-drivers
Readers known about:
Nr.    Driver     Name
0      openct     CCID Compatible
1      openct     OpenCT reader (detached)
2      pcsc       OpenCT 00 00
Configured card drivers:
  cardos           Siemens CardOS
  cardos           Siemens CardOS
  flex             Schlumberger Multiflex/Cryptoflex
  cyberflex        Schlumberger Cyberflex
  gpk              Gemplus GPK
  gemsafeV1        driver for the Gemplus GemSAFE V1 applet
  miocos           MioCOS 1.1
  mcrd             MICARDO 2.1
  asepcos          Athena ASEPCOS
  setcos           Setec cards
  starcos          STARCOS SPK 2.3/2.4
  tcos             TCOS 3.0
  openpgp          OpenPGP card
  jcop             JCOP cards with BlueZ PKCS#15 applet
  oberthur         Oberthur AuthentIC.v2/CosmopolIC.v4
  belpic           Belpic cards
  atrust-acos      A-Trust ACOS cards
  muscle           Muscle Card Driver
  incrypto34       Incard Incripto34
  piv              PIV-II  for multiple cards
  acos5            ACS ACOS5 card
  akis             TUBITAK UEKAE AKIS
  entersafe        entersafe
  rutoken          Rutoken driver
  rutoken_ecp      Rutoken ECP driver
  westcos          WESTCOS compatible cards
  myeid            MyEID cards with PKCS#15 applet
  emv              EMV compatible cards
  default          Default driver for unknown cards
> opensc-tool --name
Using reader with a card: CCID Compatible
[opensc-tool] apdu.c:528:sc_transmit_apdu: unable to acquire lock
[opensc-tool] apdu.c:528:sc_transmit_apdu: unable to acquire lock
[opensc-tool] card-default.c:66:autodetect_class: APDU transmit failed: Generic reader error
[opensc-tool] card-default.c:113:default_init: unable to determine the right class byte
[opensc-tool] card.c:202:sc_connect_card: driver 'Default driver for unknown cards' init() failed: Card is invalid or cannot be handled
[opensc-tool] card.c:213:sc_connect_card: unable to find driver for inserted card
[opensc-tool] card.c:228:sc_connect_card: returning with: Card is invalid or cannot be handled
Failed to connect to card: Card is invalid or cannot be handled

Der Vollständigkeit halber ein paar Seiten dazu verlinkt:t

• Der neue Personalausweis - Das brauchen Sie
• IT-Beauftragte der Bundesregierung - Zuwendungsmaßnahme IT-Sicherheitskit
• BSI: Der neue Personalausweis - Geeignete Kartenleser
• REINER SCT - Sie suchen aktuelle CCID Treiber für Ihren cyberJack RFID basis?
• Wikipedia - Mifare DESFire
• Basisleser zerlegt

29. 10

Ich habe mir, passend zum geplanten C3-Besuch diesen Winter, ein neues (und mein erstes gekauftes) Notebook gegönnt, ein Lenovo ThinkPat T410s. Soviel als Vorgeschichte des Problems:

Lenovo liefert, wie viele andere Hersteller auch, keine Installationsdatenträger mehr mit, sondern nurnoch alle Daten in Form einer Recovery-Partition. Diese darf man dann mit einem mitgelieferten Tool immerhin netterweise selber auf andere Medien sichern. Dieser Vorgang brach dann immer wieder ab, und bis ich darauf kam, dass mit DVD-RAM hier eben nicht DVD-RAM, sondern wohl generell jede Form von DVD-Rohling (im gegensatz zur CD) gemeint ist, dauerte es eine Weile.
Update:Der Fehler war nicht das Medium, sondern das vorinstallierte Brennprogramm — selbiges deinstalliert, und es tat.

Also eben schnell auf einen USB-Stick gesichert, immerhin geht das ja auch. Nur war dieser danach nicht bootfähig, so dass er mir auch nichts brachte. Und — ohne dass es davor eine Warnung gegeben hätte — darf man die Wiederherstellungsdatenträger kein zweites mal brennen. Nur, zu meinem Glück muss die Information ja auch irgendwo gespeichert werden, also die Option Geschützte Systemdateien ausblenden deaktiviert, und schon sind auf dem Recovery-Laufwerk (in meinem Fall Q:) auch Daten sichtbar. Und da man bei Lenovo seine Kunden ja mag, macht man ihnen das auffinden garnicht schwer: In Q:\FactoryRecovery\service_done.ini ist diese Information gespeichert:

[SERVICE]
DONE=1

Und jetzt, wo der Pfad belannt ist, reicht auch ein Windowstaste+R, Q:\FactoryRecovery\service_done.ini, Enter um die Datei im Editor zu öffnen, so dass an den Sichtbarkeitseinstellungen nichtmal etwas verstellt werden muss. Ein bisschen Aufwändiger hättet ihr diese “Sicherung” doch gestalten können, wo bleibt denn da die Herausforderung?

08. 09

Nur mal kurz zur Erinnerung - einfaches Klonen von Maschinen in Virtualbox, ohne nerviges Geklicke:

#/bin/bash
if [[ -z "$1" ]]; then
        echo "no disk image given"
        exit
fi
if [[ -z "$2" ]]; then
        echo "no name given"
        exit
fi
if [[ -z "$3" ]]; then
        echo "no port given"
        exit
fi

VBoxManage createvm             \
        --name $2               \
        --ostype Debian_64      \
        --register

VBoxManage modifyvm $2          \
        --memory 128            \
        --pae off               \
        --boot1 disk            \
        --boot2 net             \
        --boot3 none            \
        --boot4 none            \
        --nic1 bridged          \
        --cableconnected1 on    \
        --bridgeadapter1 eth0   \
        --mouse ps2             \
        --keyboard ps2          \
        --audio none            \
        --clipboard disabled    \
        --vrdp on               \
        --vrdpport $3           \
        --usb off               \
        --rtcuseutc on

VBoxManage storagectl $2        \
        --name "SATA Controller"\
        --add sata              \
        --controller IntelAhci  \
        --sataportcount 1       


VBoxManage clonehd $1.vdi $2.vdi \
        --format VDI            \
        --type normal           \
        --remember              


VBoxManage storageattach $2     \
        --storagectl "SATA Controller"\
        --port 0                \
        --device 0              \
        --type hdd              \
        --medium "$1.vdi"       \

29. 08

25. 05

Als ich bei Fefe einen Eintrag über das OpenSSL-Debakel bei Debian und dessen Auswirkungen gelesen habe, insbesondere der "Spaß" mit kompromittierten Keys, solange sie nicht abgelaufen sind und der passende Private Key berechnet wurde. Dazu kamen mir folgende Gedanken:

Wir haben das Problem, dass es bei SSL bzw X.509 zwar die Möglichkeit gibt, Zertifikate zurückzurufen, wobei diese Informationen dann über die so genannte "Revocation List" einsehbar ist, dieses Verfahren aber kaum eingesetzt wird. Außerdem bringt es prinzipbedingt das Problem mit sich, dass nur der negative Status eines Zertifikats überprüfbar ist, also ob es gesperrt wurde.

Dieses Problem sollte durch OCSP beseitigt werden, hier gibt es nun auch die (optionale) Möglichkeit auf die Abfrage hin ein Zertifikat eindeutig als gut auszuweisen. Nur kann ich mir weiterhin nicht vorstellen, wer freiwillig solche Server betreiben möchte. Die Last dürfte doch sehr hoch sein.

Aber so an sich haben wir eine einzige brauchbare, wirklich skalierende, verteilte Datenbank. Das Domain Name System. Es gibt zwar gewisse Latenzen durch das Caching, aber eine Lösung die mir mit ein paar Stunden zurückgerufene Keys anzeigt ist mir immer noch lieber als eine theoretisch existierende, aber nicht verwendete. Dazu müssten ein oder zwei neue Record-Typen eingeführt werden, und schon könnten der Fingerprint des aktuell gültigen und/oder der zurückgerufenen Schlüssel dort abgelegt werden. Mittels DNSSEC könnte die Authentizität dieser Angaben gesichert werden.

Disclaimer: Ich bin kein Experte was Kryptographie angeht, daher bitte ich bei Fehlern in meinen Gedanken um Rücksicht und entsprechende Kommentare

20. 08

Da ich hier gerade auf einer Kiste (naja, eher mehr - ein ASUS M2N32WS mit 6x500GB SATA für ein schicken Fileserver) mich mit XEN und pciback rumschlage, und das ganze mit AMD64 nicht so ganz tut, wollte ich nun mal auf i386 zurückfallen. Aber idealerweise ohne irgendwelche Daten zu verlieren, und da /boot nicht im LVM liegt, brauche ich zumindest hier ein Backup. Den Debian-Installer habe ich schon per PXE gebootet, um mir das Brennen einer CD sowie den einbau eines passenden Laufwerks zu ersparen. Aber immer die Config ändern, jenachdem, was man booten möchte, saugt irgendwie. Also muss ein Bootmenü her, welches GRML sowie die Debian-Installer wahlweise startet. Und wenn innerhalb von 20s nichts ausgewählt wird, wird von Platte gebootet. Somit kann PXE in entsprechend gesicherten Umgebungen einfach angelassen werden, ohne dass es zu Probleme führt.

Was wir brauchen:

• Das GRML-ISO
• Das für das Release passende GRML-Netboot-Package
• Das AMD64-Netboot-tar
• Das i386-Netboot-tar
• Die syslinux-quellen

# mkdir /srv/tftp/
# cd /srv/tftp/
# wget http://www.kernel.org/pub/linux/utils/boot/syslinux/syslinux-3.51.tar.gz
# tar xvfz syslinux-3.51.tar.gz
# cp syslinux-3.51/com32/modules/menu.c32 .

# wget http://ftp.debian.org/debian/dists/etch/main/installer-amd64/current/images/netboot/netboot.tar.gz
# tar xvfz netboot.tar.gz
# rm netboot.tar.gz
# wget http://ftp.debian.org/debian/dists/etch/main/installer-i386/current/images/netboot/netboot.tar.gz
# tar xvfz netboot.tar.gz
# rm netboot.tar.gz
# rm pxelinux.0
# rm pxelinux.cfg

# mkdir grml
# wget ftp://ftp.uni-erlangen.de/pub/mirrors/grml/grml_1.0.iso
# mount -o loop grml_1.0.iso /mnt/tmp/
# cd grml
# cp -r /mnt/tmp/* .
# cd ..
# umount /mnt/tmp
# wget http://grml.org/terminalserver/grml_netboot_package_1.0.tar.bz2
# tar xvfj grml_netboot_package_1.0.tar.bz2
# cp tmp/terminalserver_grub.Ln6542/grml_netboot_package_grml/tftpboot/linux26 grml/boot/     
# cp tmp/terminalserver_grub.Ln6542/grml_netboot_package_grml/tftpboot/minirt26.gz grml/boot/
# cp tmp/terminalserver_grub.Ln6542/grml_netboot_package_grml/tftpboot/memtest grml/boot/

"PXE-Bootmenü für Debian-Installer und GRML" vollständig lesen

12. 01

Ich habe von meinen Eltern zu Weihnachten einen schicken 16:10-TFT bekommen, welcher natürlich auch Digital angesteuert gehört. Und dann bitte auch in seiner nativen Auflösung von 1680x1050 Pixel. Aber genau das führte zu viel Kopfzerbrechen - der Xserver startete immer nur in 1280x1024 oder auch 1024x768 :/

Nun hatte ich zwar passende Einstellungen in der xorg.conf, aber diese haben keinen Effekt gehabt:

Section "Screen"        
        Identifier      "Default Screen"
        Device          "NV15"
        Monitor         "SyncMaster"
        DefaultDepth    16
        SubSection "Display"
                Depth           16
                Modes           "1680x1050" 
        EndSubSection                                                         
        SubSection "Display"
                Depth           24
                Modes           "1680x1050"
        EndSubSection
EndSection

[...]
(--) NVIDIA(0): Connected display device(s) on GeForce FX 5200LE at
(--) NVIDIA(0):     PCI:1:0:0:
(--) NVIDIA(0):     Samsung SyncMaster (DFP-0)
(--) NVIDIA(0): Samsung SyncMaster (DFP-0): 135.0 MHz maximum pixel clock
[...]
(--) NVIDIA(0): Detailed Timings:
(--) NVIDIA(0):   1680 x 1050 @ 60 Hz
(--) NVIDIA(0):     Pixel Clock      : 146.25 MHz
[...]

"Nvidia, Xorg und mein neuer Monitor" vollständig lesen

25. 09

Gesehen bei The Raw Feed, weitere Infos im RC-Cam-Forum

25. 07

Wie die Projektverantwortlichen bei Debian heute mitteilten, soll Ende dieses Jahres Etch aka Debian GNU/Linux 4.0 erscheinen. Bis dahin soll den Bugs in mehreren Bug Squashing Partys zuleibe gerückt werden. Debian 4.0 wird das erste stable-Release mit

• Xorg
• GCC 4
• Secure Apt (gpg-Signaturen etc)

Übrigens, wer sich schon immer gefragt hat wie das Debian-Team zu den Namen seiner Releases kommt: Das sind alles Namen von Figuren aus dem Film Toy Story. Sid nimmt hierbei allerdings eine Doppelrolle ein: Es ist einerseits der Name des bösen Jungen von nebenan, der immer das Spielzeug kaputtmacht, andererseits auch ein Akronym für "still in development".

19. 07

Wer mal immer Wissen wollte, über wie viele Ecken sein GPG-Key meinen kennt:

07. 07

Ich habe gestern und Heute im Betrieb damit verbracht, defekte HDDs von ganzen zu trennen. Dabei habe ich mir erlaubt, ein klanglich wunderschönes Exemplar zu öffnen und ein kleines Video davon zu drehen, welches ich an dieser Stelle präsentiere. Am besten lässt sich der Klang so ca bei 0:40 hören, eine bessere Qualität gab mein Handy leider nicht her. Die Scheibe sah danach mehr nach feinem Schmirgelpapier als nach Festplatte aus...