Projekte.IndRobotBetriebssystem (Struktur)

Betriebssystem

Besonderheiten der Betriebssysteme der beteiligten Rechner

Anforderungen und Randbedingungen

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.

Festplattenprobleme

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:

  • Änderungen in dem RAM-Disk-System gehen verloren, daher muß man das Image ändern.
  • Das Image muß irgendwie geladen werden

Ü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).

WLAN-Verbindungsprobleme

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.

Praktischer Aufbau der Systeme

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.

Modifikationsrezept für die Ramdisk

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.

Festplatteninstallation

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.

Boot-CD-Erstellung

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:

bzImage
ist der Kernel, der geladen wird.
initrd.gz
ist das mit gzip komprimierte Image der initrd, also der Ramdisk.
isolinux.bin
ist das Binary von Isolinux, also der Bootloader.
isolinux.cfg
ist die Konfigurationsdatei von Isolinux und entspricht in etwa der lilo.conf.

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:

-o rtest.img
gibt die Ausgabedatei an, in die das Image geschrieben werden soll.
-b isolinux/isolinux.bin
gibt den Pfad und Dateinamen des El Torito-Boot-Images an, daß beim Booten von CD geladen werden soll. Da hier nicht im Emulationsmodus gearbeitet wird, ist isolinux.bin kein Floppy-Image. Der Pfad ist relativ zum CD-Root, daher wird hier kein cdimage vor isolinux geschrieben.
-c isolinux/boot.cat
ist der Bootkatalog, den mkisofs anlegt. Eine Datei diesen Namens darf nicht existieren und wird auch nicht angelegt, mkisofs erzeigt sie nur im Image.
--no-emul-boot
sorgt dafür, daß keine Floppy- oder HD-Emulation genutzt wird. Bei der Emulation emuliert das BIOS ein Floppy-Laufwerk indem es den Inhalt der mit -b angegebenen Datei als "Laufwerk a:" zugreifbar macht. Dies hat allerdings den Nachteil, daß man auf die Größe der Floppy begrenzt wird und manchmal Kompatibilitätsprobleme hat, daher wird es hier nicht eingesetzt, wofür diese Option sorgt.
--boot-load-size 4
gibt die Anzahl der virtuellen 512-Byte-Sektoren an, die im No-Emulation-Modus geladen werden sollen.
--boot-info-table
gibt an, daß die Tabelle mit dem CD-Layout in das Boot-File geschrieben werden soll. Dabei wird die Ausgangsdatei verändert.
cdimage/
ist der Pfad, an dem die Dateien, die auf CD geschrieben werden sollen, zu finden sind.

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:

dev=0,0,0
gibt das SCSI-Device an, an dem der Brenner angeschlossen ist. Die erste 0 steht für den Bus und ist 0, da robogate kein anderes SCSI-Interface hat (USB-Storage-Geräte werden von Linux als SCSI-Geräte angesprochen). Die nächste 0 ist die SCSI-ID und bei USB-IDE-Bridges mit nur einem Interface ist die Device-ID 0. Die dritte 0 steht für die LUN 0 und ist bei einem einfachen CD-Laufwerk praktisch immer 0.
speed=4
gibt die Brenngeschwindigkeit an. Da robogate nicht über einen USB2-Anschluß verfügt, wird die Brenngeschwindigkeit vom Bus auf Quadspeed begrenzt. Dazu kommt, daß die verwendeten CD-RW-Medien Low-Speed-Medien sind (CD-RWs kommen in 3 Geschwindigkeitsklassen: Low-Speed, High-Speed und Ultra-Speed. Im Gegensatz zu CD-R-Medien muß das Laufwerk für die unterschiedlichen Medienklassen eine unterschiedliche Schreibstrategie nutzen und daher ist das bei CD-Rs durchaus mögliche zu-schnell-Brennen bei -RWs nicht zu empfehlen.
driveropts=burnfree
ermöglicht es dem Laufwerk bei Datenstau im Rechner den Schreibvorgang kontrolliert zu unterbrechen und später, bei ausreichendem Bufferfüllstand, wieder fortzusetzen. Dies sollte praktisch in dieser Konfiguration nicht vorkommen, schadet aber auf jeden Fall nicht und unser Laufwerk unterstützt es.
-v
erhöht die Gesprächigkeit von cdrecord. Hierbei wird unter anderem der Brennfortschritt angezeigt.
-eject
wirft nach dem Brennen das Medium aus. Praktisch, wenn man in der Zwischenzeit etwas anderes machen will.
-data rtest.img
gibt die Datei an, die gebrannt werden soll.

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.

Anpassungen auf robogate

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.

WLAN-Konfiguration

Allgemeines zu WLANs

Wireless-LANs haben bisher einige Besonderheiten, die man berücksichtigen muß.

Sicherheit

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.

Accesspoints oder Ad-Hoc-Modus

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.

Auswirkungen für das hier vorhandene System

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:

  • Kostenloser Internetzugang
  • Anonymer Internetzugang
  • Kompromitierung der Rechner
  • Allgemeinen Schaden anrichten

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

 TU Clausthal 2020  Impressum