Besonderheiten der Betriebssysteme der beteiligten Rechner |
Im vorhandenen System bestehen einige Voraussetzungen, die eine besondere Behaldlung der Betriebssysteme erfordern. Das Hauptproblem ist die Mobilität des Roboters, was sich in zwei Bereichen besonders bemerkbar macht: Den Erschütterungen und Schwingungen, die der Roboterrechner überleben muß und das Wireless-LAN samt der möglichen Verbindungsabbrüche.
Während der Arbeiten am Projekt hat sich herausgestellt, daß die Festplatte die Schwingungsdämpfungsmaßnahmen als nicht ausreichend beurteilt und sich daher Krank gemeldet hat. Da wir schlecht an eine Vertretung kommen und der Verschleiß etwas hoch wäre, war eine andere Lösung nötig: Die ursprünglich vorgesehene RAM-Disk-Lösung. Der Rechner hat genau für diesen Zweck 512 (510+2 MB Framebuffer) MB Ram und das System braucht effektiv weniger als 128M für den normalen Betrieb. Daher bleiben noch über 300MByte für ein RAM-Disk-System übrig, was einigermassen bequem hinzukriegen ist. Als Probleme gibt es aber noch folgende Bereiche:
Üblicherweise könnte man für so ein Unterfangen ein NFS-Root-System nehmen und hätte das ganze RAM-Disk-Problem umgangen. Allerdings ist das WLAN nicht so gut, daß man eine ausreichend gute Verbindung garantieren kann und ein NFS-Root-System, dem das Netz abhanden kommt, geht ziemlich schnell in Streik. Eine andere übliche Methode wäre, die RAM-Disk über das Netz zu laden. Voraussetzung hierzu ist aber, daß das BIOS das Netzwerkinterface unterstützt und dieses das passende Boot-ROM dabei hat. Bei WLAN-Karten ist beides nicht der Fall, daher besteht keine ausreichend einfache Lösung für dieses Problem. Als Lösung kommt nur noch die Nutzung eines Massenspeichers im Roboter in Frage. Hierbei fallen, mangels BIOS-Unterstützung, USB-Geräte wie die einigermassen günstigen Flash-Sticks weg. Als Möglichkeit bestehen Floppys, Festplatten, CD-ROM-Laufwerke (oder generell: bootfähige ATA/ATAPI-Geräte) und noch Disk-on-Chip-Module. Letztere sind aber nicht wirklich leicht erhältlich und haben einen im Gegensatz zu Notebookplatten viel höheren Preis. Die Nutzung einer Festplatte ist prinzipiell ohne Probleme möglich, da sie nach dem Booten der RAM-Disk abgeschaltet wird und damit ziemlich unempfindlich ist. Das Booten von CD-Rom ist deutlich umständlicher in der Einrichtung, aber dafür hat man ein Read-Only-Medium und sehr günstige Laufwerke (die aber u.U. Probleme mit der Vibration haben könnten - Lasereinheiten sind mechanisch einigermassen empfindlich).
Durch die Mobilität, die ein autonomer Roboter haben muß, entsteht das Problem, daß er sich aus der vom Funknetz abgedeckten Zone herausbewegen kann. Daher darf das System nicht auf die dauerhafte Verbindung angewiesen sein sondern muß gegen Verbindungsabbrüchen tolerant aufgebaut werden. Damit ist eine Nutzung von Netzwerkdateisystemen für betriebswichtige Anwendungen nicht möglich, für die Entwicklung aber durchaus eine gute Möglichkeit, da man dort davon ausgehen kann, daß sich der Roboter in der abgedeckten Zone befindet.
Für den Betrieb wichtige Software muß also in der RAM-Disk untergebracht sein.
Momentan lädt der Roboterrechner sein System aus einem Ramdisk-Image, das entweder von einer Notebook-Festplatte oder einer CD geladen wird. Der Home-Bereich wird per NFS über das WLAN bezogen und dient der Entwicklung der Steuerprogramme. Wenn diese fertig entwickelt sind können sie in das RAM-Disk-Image aufgenommen werden und sind dann beim nächsten Neustart automatisch verfügbar.
Das RAM-Disk-Image liegt auf dem Arbeitsplatzrechner und wird bei Bedarf eingetütet, d.h. mit gzip -c initrd.img >initrd.gz für das Laden als initrd bereitgemacht.
/usr/src lebt komplett im NFS, es macht keinen Sinn, /usr/src in die RAM-Disk zu packen, zumal dieser Bereich viel zu groß ist.
Auf robogate muß man zuerst das Image mounten:
mount -oloop initrd.img /mnt
danach kann man normal in /mnt arbeiten und die Änderungen vornehmen.
Wenn man damit fertig ist, wird mit
umount /mnt
das Image umounted. Man kann nochmal einen Dateisystemcheck durchführen (eine Ramdisk mit Fehlern muß nicht sein...)
fsck -f initrd.img
und danach wird sie mit gzip eingepackt. Das Komprimieren spart zum einen Übertragungszeit und auch Ladezeit.
gzip -c initrd.img >initrd.gz
Danach muß initrd.gz noch auf die Platte des Roboterrechners kopiert werden. Dazu hat dieser noch ein "normal" installiertes System. LILO aufrufen nicht vergessen.
Wichtig ist noch, den Parameter ramdisk_size=300000 bei den Kernel-Parametern nicht zu vergessen.
Wichtig war noch, /etc/mtab als Link auf /proc/mounts zu setzen, da bei dem Ramdisk-System die mtab nicht aktualisiert wurde und damit df, mount usw. nicht funktioniert haben.
Zum Schlafenlegen der Festplatte ist in /etc/init.d/bootmisc.sh am Ende noch
/sbin/hdparm -Y /dev/hda
eingetragen. Vorsicht, danach ist die Festplatte so schläfrig, dass sie erst einen Reset benötigt, bis sie wieder reagiert, was der Kernel automatisch erledigen sollte.
Auch wichtig ist, in der /etc/fstab des Roboters keine Partitionen auf der Festplatte eingetragen zu haben.
Auf der Festplatte sollte ein minimalsystem installiert sein, damit man problemlos LILO o.ä. nutzen kann. Alternativ wäre noch ein kleines DOS und Syslinux möglich.
Um die initrd zu laden, muß man in der lilo.conf den Parameter initrd=/initrd.gz und in der append-Zeile ramdisk_size=300000 mit angeben. Nach dem Unterbringen des Kernels und des Ramdisk-Images an der passenden Stelle einmal lilo aufrufen und neu starten.
Für das Booten von CD wird Isolinux aus dem Syslinux-Paket (http://syslinux.zytor.com/) genommen.
Isolinux ist ein kleines Binary-File, daß vom BIOS beim Start von der CD gelesen und ausgeführt wird. Es lädt den Kernel und die Initrd, wobei es auch Bootparameter übergeben kann.
Auf robogate existiert im Verzeichnis /robo das Unterverzeichnis cdimage, das die Daten enthält, die auf die CD geschrieben werden sollen. Das Verzeichnis /robo/cd-Image wird zum Root-Verzeichnis der CD. In dem CD-Image muß für Isolinux ein Verzeichnis isolinux existieren, in dem isolinux seine Dateien sucht. Es sollte folgende Dateien enthalten:
Wichtig ist hier vor allem der Inhalt von isolinux.cfg:
DEFAULT bzImage SAY Robo-OS Version 1 Stand 2003-02-25 16:21 LABEL bzImage kernel bzImage append root=/dev/ram0 initrd=initrd.gz ramdisk_size=300000 rw
Die erste Zeile gibt an, daß standardmäßig bzImage geladen werden soll.
Die zweite Zeile ist nicht wirklich nötig, es bietet sich aber an, hier die Version der CD einzutragen, damit man sie später identifizieren kann. Kaum etwas ist nerviger als wenn sich nach einigen Stunden Debugging herausstellt, daß man mit einer veralteten Version gearbeitet hat deren Fehler schon längst beseitigt worden sind.
Die LABEL-Zeile definiert den Block für bzImage in dem der Kernel und die Parameter angegeben werden. root=/dev/ram0 gibt an, daß der Kernel als Root-Dateisystem die Ramdisk nutzen soll. initrd=initrd.gz sorgt dafür, daß die initrd.gz als initrd geladen wird und ramdisk_size=300000 ändert die Größe der Ramdisk von den 4 MByte der Standard-Ramdisk auf 300000 KByte (sonst passt sie nicht!). Das rw sorgt dafür, daß sie ReadWrite gemouted wird, da es keinen Sinn macht, sie erst im laufenden System nach einem fsck für das Schreiben freizugeben (Wenn ein Fehler auf der initrd ist, dann kann hier kein Schaden entstehen).
Nachdem die nötigen Dateien im Verzeichnis für die CD-Rom untergebracht wurden, muß nur noch ein ISO9660-Image davon gebaut werdne. Dies geschieht mit der Zeile
mkisofs -o rtest.img -b isolinux/isolinux.bin -c isolinux/boot.cat \ -no-emul-boot -boot-load-size 4 -boot-info-table cdimage/
die aus /robo aufgerufen werden sollte. Das \ am Ende der ersten Zeile kann man entfernen und beide Zeilen auf eine Zeile schreiben, für diesen Text ist sie zu lang und daher mußte ich sie umbrechen.
Die Parameter haben folgende Bedeutung:
Nachdem das Image fertig geschrieben ist, muß es nur noch auf CD geschrieben werden. Während der Entwicklungsarbeit bieten sich CD-RWs an, da sie gelöscht werden können und somit kein Berg an CD-Müll entsteht. Das folgende Beispiel gilt für den im Labor vorhandenen USB-CD-Brenner an robogate:
cdrecord dev=0,0,0 speed=4 driveropts=burnfree -v -eject -data rtest.img
Dabei haben die Parameter folgende Bedeutung:
Um eine CD-RW wieder zu löschen kann man folgende Zeile nehmen:
cdrecord dev=0,0,0 speed=4 -blank=fast
Bei blank=fast wird am wenigsten gelöscht, es geht aber schnell. Wenn man gründlicher sein will sollte man blank=disk nehmen.
robogate muß einige NFS-Exporte für /home, ggf. für /usr/src und bei Bedarf für andere Bereiche erlauben. Daneben hat man als Besonderheit die Zwei-Netz-Konfiguration, da robogate (wie der Name schon sagt) zum einen im "echten" Internet sitzt, zum anderen aber auch im WLAN von robo. Da die WLAN-Karte nicht von den normalen Netzwerkstartscripten des Init-Systems gestartet werden kann (WLAN-Karten werden als PCMCIA-Karten von dem Hotplugging-System, in diesem Fall von PCMCIA-System, behandelt) muß man darauf achten, daß dieses Interface nicht automatisch gestartet wird. In /etc/network/interfaces darf für eth1 kein auto-Eintrag vorhanden sein. Auch darf die WLAN-Karte nicht als Gateway eingetragen sein.
Wireless-LANs haben bisher einige Besonderheiten, die man berücksichtigen muß.
WLANs werben mit Sicherheit, bisher meistens mit WEP. Leider ist das WEP-System schon seit einiger Zeit geknackt (da das System kryptographisch fehlerhaft ist) und man kann nicht mehr davon ausgehen, daß Verbindungen nicht abgehört werden. Weiterhin kann jeder, der mit einer normalen WLAN-Karte in der Nähe ist, auf das Netz zugreifen.
Die bei uns eingesetzten Lucent Orinoco-Karten können prinzipiell eine Nenn-Rate von 11MBit. Dieser Modus steht aber nur zur Verfügung, wenn ein Access Point vorhanden ist. Zur Zeit haben wir keinen und daher werden die Karten im Ad-Hoc-Modus betrieben, was zu einer Bitratenreduktion auf 2MBit führen kann. Weiterhin ist die Bitrate von den Empfangsbedingungen abhängig, so daß schon eine Person im Weg zu einer verschlechterung der Qualität führen kann.
Die Nachteile des Ad-Hoc-Moduses sind verschmerzbar, da die Bitrate sich praktisch als ausreichend erwiesen hat. Beim Betrieb werden einige wenige kByte/Sekunde übertragen, wofür dieser Modus ausreicht. Bei Zukauf eines APs sollte ggf. eine Zwei-Antennen-Version in Erwägung gezogen werden, um verschiedene Bereiche des Gebäudes abdecken zu können, z.B. den Flur komplett.
Die Sicherheitsprobleme sind allerdings nicht zu vernachlässigen. Angriffe und Mißbrauch des Systems sind vor allem dann zu erwarten, wenn sie dem Angreifer etwas nutzen. Der Nutzen, den ein Angreifer ziehen könnte wäre:
Das "interessanteste" an einem offenen WLAN, also der kostenlose Internetzugang, ist in dem hier vorhandenen System einfach verhindert: Es geschieht kein Routing zwischen dem WLAN und dem Internet. Die einzige Möglichkeit wäre ein Shell-Login auf robogate und dazu ist ein Account nötig.
Eine Kompromitierung von Robogate ist unwahrscheinlich, da robogate sein eigenes System nicht freigibt und auch keine kritischen Dienste ins WLAN anbietet. Spezifisch wird kein NIS genutzt, daher besteht auf diesem Weg keine Möglichkeit, das Passwort eines der genutzten Accounts zu erlangen. Telnet und ähnliche Klartext-Protokolle kommen auch nicht zum Einsatz, daher besteht auch nicht die Möglichkeit, durch Mithören an ein Passwort zu gelangen.
Als letzte Möglichkeit bestünde noch das Problem der Erzeugung von sonstigen Schäden. Als größtes Potential wären mechanische Schäden durch den Roboter zu sehen. Dies ist aber zum einen durch die hardwaremäßigen Sperren (wenn der Schlüsselschalter aus ist, dann geht nichts) und zum anderen durch die Plausibilitätskontrolle des Steuerungssystems soweit eingeschränkt, daß keine Probleme zu erwarten sind. Unbeaufsichtigter Fahrbetrieb sind nicht vorgesehen.
Autor: gkemnitz, Letzte Änderung: 14.04.2011 15:10:00