Chaosdoor/iButton: Difference between revisions

Revision as of 21:39, 21 January 2014

Administration

ibuttond startet ibutton und piped die Ausgaben nach door
Alle 5 Minuten wird per Cronjob überprüft, ob ibutton und door laufen, andernfalls werden sie neugestartet (Ergebnis davon ist im Icinga sichtbar)
Das authorized_ibuttons Verzeichnis wird per git getrackt

iButton anlegen

iButton an der Tür einlesen
cat /tmp/last_failed_ibutton, mit aufgedruckter ID vergleichen

door > cd authorized_ibuttons
door > bin/add_ibutton nickname id

iButton revoken

Bei Verlust, Austritt oder sonstwas

door > cd authorized_ibuttons
door > bin/revoke_ibutton nickname
       (ID raussuchen)
door > bin/revoke_ibutton id
       (Grund eingeben und vim mit :x beenden)

SSH-Keys verwalten

in authorized_sshkeys befindet sich eine Datei pro Nickname, dort die Keys eintragen / entfernen und mit bin/refresh aktualisieren. Vor jeden Key wird automatisch no-port-forwarding,no-X11-forwarding,from="172.22.26.*" gepackt sowie der Nickname an den Keynamen angehängt.

Onewire Interface

iButtons:

Unterstützen READ ROM und SEARCH ROM
Kein Overdrive

Reader:

?

Debugging

Normalbetrieb

Einschalten der Neonröhre?

Mit Zoom

Reset des Readers?

Der iButton-Reader scheint nicht für größere Entfernungen zum tatsächlichen Lesekontakt ausgelegt zu sein. Der One-Wire-Bus kann durch ein- bzw. ausschalten der Leuchtstoffröhre über der Tür (Kabel / Röhre verlaufen parallel zum RJ45-Kabel vom iButton-Reader) so stark gestört werden, dass sich diese Störung auf den USB-Teil des Readers fortpflanzt und den angeschlossenen Host beeinträchtigt.

Auf der Tür-Dockstar ist es kein Problem, an einem Raspberry Pi funktioniert der iButton-Reader schlecht bis gar nicht, eine x86-Kiste kann das Problem erkennen und sich davon erholen. Relevanter Kernel-Log beim Einschalten der Röhre auf lastlight:

Jan 19 05:09:08 lastlight kernel: [214347.808082] hub 3-0:1.0: port 1 disabled by hub (EMI?), re-enabling...
Jan 19 05:09:08 lastlight kernel: [214347.808227] usb 3-1: USB disconnect, device number 20
Jan 19 05:09:08 lastlight kernel: [214348.088041] usb 3-1: new full-speed USB device number 21 using uhci_hcd
Jan 19 05:09:08 lastlight kernel: [214348.246910] usb 3-1: New USB device found, idVendor=04d8, idProduct=feb9
Jan 19 05:09:08 lastlight kernel: [214348.246919] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jan 19 05:09:08 lastlight kernel: [214348.246926] usb 3-1: Product: IBL USB iButton reader
Jan 19 05:09:08 lastlight kernel: [214348.246931] usb 3-1: Manufacturer: IBL
Jan 19 05:09:08 lastlight kernel: [214348.254139] input: IBL IBL USB iButton reader as /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/input/input21
Jan 19 05:09:08 lastlight kernel: [214348.254681] generic-usb 0003:04D8:FEB9.0011: input,hidraw0: USB HID v1.00 Keyboard [IBL IBL USB iButton reader] on usb-0000:00:1d.1-1/input0

Vorläufiger Workaround: iButton-Reader nur an door betreiben.

@@ Line 11: / Line 11: @@
 * iButton an der Tür einlesen
 * cat /tmp/last_failed_ibutton, mit aufgedruckter ID vergleichen
-* echo $nickname > /root/authorized_ibuttons/$id
-* committen
+<syntaxhighlight lang="text">
+door > cd authorized_ibuttons
+door > bin/add_ibutton nickname id
+</syntaxhighlight>
 === iButton revoken ===
@@ Line 18: / Line 21: @@
 Bei Verlust, Austritt oder sonstwas
-* fgrep $nickname /root/authorized_ibuttons/*
+<syntaxhighlight lang="text">
-* mv /root/authorized_ibuttons/$id{,.revoked}
+door > cd authorized_ibuttons
-* Revoke-Grund in die Datei schreiben
+door > bin/revoke_ibutton nickname
-* committen
+       (ID raussuchen)
+door > bin/revoke_ibutton id
+       (Grund eingeben und vim mit :x beenden)
+</syntaxhighlight>
+=== SSH-Keys verwalten ===
+in authorized_sshkeys befindet sich eine Datei pro Nickname, dort die Keys eintragen / entfernen und mit bin/refresh aktualisieren. Vor jeden Key wird automatisch <nowiki>no-port-forwarding,no-X11-forwarding,from="172.22.26.*"</nowiki> gepackt sowie der Nickname an den Keynamen angehängt.
 == Onewire Interface ==