Was ist ein HPPA-RISC?

Hier soll im folgenden mit "HPPA" und "Gecko" ein "HP Model 712/60" gemeint sein. Das benutzte Exemplar weist die folgende Ausstattung auf:

(wobei SCSI-Controller und Ethernet-Controller in einem Chip angesiedelt sind; Links zu detaillierterer Hardwarebeschreibung finden sich bei den Links.)

Erster Kontakt

Der erste Kontakt zu dieser Architektur war begleitet von der Tatsache, dass es einen neuen, großen und klobigen Monitor dazugab, begleitet von der Auskunft, dass man dazu auch Adapter auf "Normal-VGA" bekäme. So wurde dann erstmal das installierte HPUX gebootet. Fazit: Nette Spielerei. Sogar graphisch und halbwegs performant. Wer möchte, kann dieses System für HPPA noch immer direkt bei HP bestellen.

Was als nächstes auffiel war der Betriebsmodus des Monitors: Sync on Green. Ein Standard, der heute nur noch von entweder teuren oder alten Geräten unterstützt wird. Also wurde nach einer Schaltung für einen Adapter gesucht. Aber es wurde spontan nichts gefunden. So blieb es erst einmal dabei. Aber an der Software konnte ohne größere Probleme etwas geändert werden. Das HP-UX wurde zunächst einmal durch ein Debian Linux erstetzt.

Debian

Als erstes die klassische Frage bei der Installation eines Betriebssystems: Wovon installieren? Da das Gecko zum einen einen Boot per Netzwerk mittels DHCP und TFTP unterstützte und zum Anderen ein weiterer Rechner zur Verfügung stand, wurde auf diese Art installiert. Und zwar ganz dreckig von einem Windows-Rechner mittels einer Software wie tftp32, der man lediglich das Installations-Image hinschmeißt. Danach muss man dem Gecko nur noch mitteilen, dass es doch bitte aus dem Netzwerk booten mögen. Dazu wird während des Bootens die Escape-Taste gedrückt, woraufhin das Boot-Menü erscheint, welches folgendermaßen aussieht:

--------------------------------------------------------------------------------
Command                             Description
-------                             -----------
Auto [boot|search] [on|off]         Display or set auto flag
Boot [pri|alt|scsi.addr] [isl]      Boot from primary, alternate or SCSI
Boot lan[.lan_addr] [install] [isl] Boot from LAN
Chassis [on|off]                    Enable chassis codes
Diagnostic [on|off]                 Enable/Disable diagnostic boot mode
Fastboot [on|off]                   Display or set fast boot flag
Help                                Display the command menu
Information                         Display system information
LanAddress                          Display LAN station addresses
Monitor [type]                      Select monitor type
Path [pri|alt] [lan.idb|SCSI.addr]  Change boot path
Pim [hpmc|toc|lpmc]                 Display PIM info
Search [ipl] [scsi|lan [install   Display potential boot devices
Secure [on|off]                     Display or set security mode
--------------------------------------------------------------------------------
BOOT_ADMIN>
Hier kann nun ein Netzwerkboot eingeleitet werden, indem am Prompt "boot lan" eingegeben wird, woraufhin das LAN nach DHCP-Servern durchsucht und entsprechend gebootet wird. Nun schließt sich eine langsame und qualvolle Installation ab, die, bemerkt man den Sinn der speziellen Bootpartition sogar erfolgreich enden kann. Krönendes Ergebnis ist ein Debian, welches nach einem langen und langsamen Boot stabil läft. Allerdings sollte man nicht wagen, von X11 und dergleichen zu träumen – zumindest nicht ohne lange Bastelabende.
Die "Geschwindigkeit" (bis zu fünf Minuten beim Booten) war auch der Grund, weshalb des Gecko schon bald wieder ein neues System bekommen sollte. Für die Benutzung Faxserver war es deutlich zu langsam.

VGA-Adapter, ultratransportabel, hochmobil und spottbillig

Bevor es an weitere Misshandlungen auf der Softwareseite gehen konnte (das Gecko sah einer fröhlichen Zukunft als IRC-Konsole entgegen), sollte es dennoch die Zusammenarbeit mit einem VGA-Monitor erlernen, schon aufgrund der Reduzierung der Strahlendosis. Hierzu wurde ein Adapter entwickelt, der die obengenannten Kriterien Problemlos erfüllt. Es folgt eine kurze Anleitung:

  1. Das Gecko wie oben erklärt in das Bootmenü bringen. Hierzu noch den alten Monitor (Sync on green; so vorhanden ...) angeschlossen lassen.
  2. Durch Eingabe von "monitor" erhält man ein Menü, welches wie folgt aussehen sollte:
    Monitor Choices
    Type     Resolution       Frequency
    ----     ----------       ---------
      1      1280x1024          72Hz
      2      1024x768           75Hz
      3      1024x768           70Hz
      4      1024x786           75Hz      Flat Panel
      5      1280x1024          60Hz
      6      1024x768           60Hz
      7       640x480           60Hz
      8      1280x1024          75Hz      VESA
      9      1024x768           75Hz      VESA
     10       800x600           75Hz      VESA
     11       640x480           75Hz      VESA
    
    
    Current Monitor Type is
     10       800x600           75Hz      VESA
    
    BOOT_ADMIN>
    
  3. Hier wählt man nun beispielsweise als Monitor den mit der Nummer 11 (sollte mit allen Monitoren arbeiten) oder entsprechen höheren Modi (alle VESA-Modi durchspielen ...). Hierzu dient eine Eingabe wie "monitor 11". Damit der Wert gespeichert wird, folgt noch ein "boot", wobei der Boot-Vorgang durch Betätigung des Power-Knopfes am Gecko abgebrochen werden kann.
  4. Neuen Monitor (VGA) anschließen.
  5. Gecko wieder einschalten, dabei Daumen drücken. Ansonsten blind zurücktappsen und einen der anderen Monitore benutzen.
  6. Viel Glück kann ich wünschen, Garantien kann ich nicht übernehmen.
Alternativ kann auch der höchtste VESA-Modus eingestellt werden – wenn der Monitor den Modus nicht unterstützt (oder der VRAM des Geckos nicht ausreicht), beginnt der HPPA durch die möglichen Modi zu wechseln. Mit Enter und "y" kann ein funktionierender Modus ausgewaehlt werden.

OpenBSD

Das nächste Abenteuer, dem das Gecko ausgesetzt werden sollte, war OpenBSD. Die Installation gestaltete sich im wesentlichen einfacher als die des Debian Linux. Der Ansatz war ähnlich; auch hier wurde von einem Image ausgegangen, welches zum Netzwerkboot geeignet ist. Also wieder das bekannte Procedere wie schon bei Linux: Aufsetzen eines DHCP sowie TFTP-Servers und anschließende Benutzung des selbigen. Es folgen die üblichen Schritte: Konfiguration der Festplatte (wobei bei OpenBSD im Gegensatz zu Debian keine spezielle Partition für den Bootvorgang notwendig ist) und schließlich Installation der Software. Natürlich benötigt alles etwas länger, da BSD im Gegensatz zu Linux nicht mit Binärpaketen sondern Quelltexten arbeitet, soll heißen: Es werden Quelldateien geladen und anschließend auf dem Gecko selbst kompiliert. Da dies nur die Kraft der sechzig Megaherzen hat, dauert es entsprechend. Allerdings gibt es Binärpakete, diese werden mittels des Befehls pkg_add installiert. Entsprechend waren viele Installtionen ein wenig vom Abenteuer "Wird er's schaffen?" begleitet. Alles in allem hat er es geschafft, nur die libgcrypt hat ein Problem, welches bisher noch ungelöst verbleibt und es unmöglich macht, ein vpnc zu kompilieren (da dies hiervon abhängig wäre).

libgcrypt

(20.02.2007)
Ein halbes Jahr zog ins Land, dann packte mich der Ehrgeiz. Das mit der libgcrypt muss doch irgendwie zu machen sein. Irgendwie halt. Vielleicht war ja einfach nur was mit dem Port nicht in Ordnung. Also wurde der make-Vorgang mal unter die Lupe genommen und es stellte sich heraus, dass es das "make install" war, woran es scheiterte. Diverse Patches haben nichts geholfen, über eine bestimmte Schwelle kam das make nicht. Was nun?
Mir fiel auf, dass da in dem Port eine veraltete Version der libgcrypt benutzt wird ... also einmal die neuen Sources von heruntergeladen (zur Zeit, da ich dies schreibe, war libgcrypt-1.2.4.tar.gz aktuell) und irgendwo im nicht-Portstree entpacken. Hier ließ sich nun ohne Probleme ein make-Lauf veranstalten. Inklusive "make install".

vpnc

So, nun kann ich ja einfach /usr/ports/security/vpnc bauen und fertig ist. Dachte ich. Das erste Problem ist, dass OpenBSDs Package-DB nicht weiß, dass da eine libgcrypt installiert ist. Also wird versucht, die Abhängigkeit /usr/ports/security/libgcrypt zu erstellen. Was ja nichts werden kann, aber das ist schon erledigt. Also habe ich mich dazu hinreißen lassen, einfach mal diese Abhängigkeit aus dem Makefile auszukommentieren. Und schon hat der make-Lauf des vpnc immerhin schonmal das configure überlebt. Das eigentliche Erstellen war dann auch kein Problem mehr. Dann kam es wieder. Das "make install". Und es scheiterte. Dabei hatte doch alles geklappt. Warum also dies?
Die Antwort ist eklig. Was macht OpenBSD, wenn ein Programm aus den Ports installiert wird? Es lässt den Port so tun, als wenn er installiert. Dabei wird aber nichts wirklich getan, sondern von OpenBSD wird im wesentlichen aufgepasst, was da vor sich geht. Und dann wird aus diesen Informationen ein Package erstellet und jenes Package wird dann mittels (man ahnt es) pkg_add installiert. Das konnte nun nix werden, weil die libgcrypt bekanntermassen eher unsauber in das System integriert ist. Was also tun? Ein Versuch, so wie bei der libgcrypt vorzugehen, scheiterte schlicht und ergreifend an meiner mangelnden Fähigkeit, zu erkennen, wie da ein "configure" gemacht werden soll. Also habe ich etwas noch perverseres getan.
Ich habe vpnc im Port kompilieren lassen und das Install übergangen. Anschließend bin ich in das Arbeitsverzeichnis gegangen, in welchem sich als Resultat eine ausführbare Datei namens "vpnc" befand. Nun noch die Konfigurationsdateien kopieren (vpnc erzählt recht bereitwillig, wo es diese erwartet ...) und ./vpnc aufrufen. Es klappte :D
Nun schnell eine /etc/vpnc/defaults.conf angelegt und auf den Uni-VPN-Server gehetzt. vpnc lief durch. Netz hatte ich noch immer nicht. vpnc doof? OpenBSD doof? Uni-Seite des VPN doof? Irgendwas davon.

Kerneleien oder vpnc mit OpenBSD

Und was nun? Ich tat das, was heute jeder macht, wenn er ein Problem hat, für das kein Mensch eine Lösung zu haben scheint – man befragt Google. Google lieferte mir dann auch schließlich folgendes Posting: http://lists.unix-ag.uni-kl.de/pipermail/vpnc-devel/2005-May/000654.html. Um es kurz zu machen, es hilft, wenn man dem Kernel folgendes mitgibt (es sei hierzu sysctl das Mittel der Wahl):
net.inet.esp.enable=0           # 0=Disable the ESP IPsec protocol
net.inet.ah.enable=0            # 0=Disable the AH IPsec protocol
net.inet.esp.udpencap=0         # 0=Disable ESP-in-UDP encapsulation
Und plötzlich lässt sich auch der VPN-Tunnel nutzen.

Für alle, die es nachmachen wollen hier ein paar Listings als Anhaltspunkt

Zunächst einmal ein erfolgreicher VPNC-Lauf:
[ad001@milch /usr/ports/security/vpnc/w-vpnc-0.3.3p1/vpnc-0.3.3]$ sudo ./vpnc
vpnc version 0.3.3
IKE SA selected psk+xauth-3des-md5
NAT status: no NAT-T VID seen
Enter Username and Password.
got address 139.30.17.38
IPSEC SA selected des-md5
add host 139.30.252.225: gateway 10.34.46.254
delete net default
add net default: gateway 139.30.17.38
VPNC started in background (pid: 6020)...
[ad001@milch /usr/ports/security/vpnc/w-vpnc-0.3.3p1/vpnc-0.3.3]$
Was folgende Folgen hat:
[ad001@milch /usr/ports/security/vpnc/w-vpnc-0.3.3p1/vpnc-0.3.3]$ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33224
        groups: lo
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:60:b0:d0:a3:15
        media: Ethernet autoselect (10baseT)
        status: active
        inet6 fe80::260:b0ff:fed0:a315%dc0 prefixlen 64 scopeid 0x1
        inet 10.34.46.7 netmask 0xffffff00 broadcast 10.34.46.255
pflog0: flags=0<> mtu 33224
pfsync0: flags=0<> mtu 1460
        groups: carp
enc0: flags=0<> mtu 1536
tun0: flags=51<UP,POINTOPOINT,RUNNING> mtu 1412
        groups: tun egress
        inet 139.30.17.38 -->> 139.30.17.38 netmask 0xffffffff
[ad001@milch /usr/ports/security/vpnc/w-vpnc-0.3.3p1/vpnc-0.3.3]$ netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu  Interface
default            139.30.17.38       UGS         0       28      -   tun0
10.34.46/24        link#1             UC          1        0      -   dc0
10.34.46.7         127.0.0.1          UGHS        0        0  33224   lo0
10.34.46.254       00:30:b8:80:c7:0e  UHLc        1        0      -   dc0
127.0.0.1          127.0.0.1          UH          1       31  33224   lo0
139.30.17.38       139.30.17.38       UH          1        0      -   tun0
139.30.252.225     10.34.46.254       UGHS        1       29      -   dc0

Internet6:
Destination                        Gateway                        Flags    Refs      Use    Mtu  Interface
::1                                ::1                            UH          0        0  33224   lo0
fe80::%dc0/64                      link#1                         UC          0        0      -   dc0
fe80::%lo0/64                      fe80::1%lo0                    U           0        0      -   lo0
ff01::/32                          ::1                            UC          0        0      -   lo0
ff02::%dc0/32                      link#1                         UC          0        0      -   dc0
ff02::%lo0/32                      ::1                            UC          0        0      -   lo0
[ad001@milch /usr/ports/security/vpnc/w-vpnc-0.3.3p1/vpnc-0.3.3]$

Fall abgeschlossen oder alles wird gut

13.04.2007

Das was ich da hinbekommen habe, war zwar schoen, aber noch lange nicht das, was ich wollte. Das hier war mit Biegen und Brechen, mit System uebers Ohr hauen und danach mit Handschuhen verprügeln, um keine Spuren zu hinterlassen. Also - der Port musste gefixt werden. Leichter gesagt als getan, sowas hab ich unter OpenBSD noch nie getan. Also mal vorsichtig mit einer Kopie des alten Ports angefangen... und als erstes die Version von 1.2.0 auf 1.2.4 erhoeht. Soweit, so gut. Beim testweisen bauen des Ports brach dieses jedoch gleich mal ab, weil keiner der Patches mehr passte. Also einfach mal guter Hoffnung das Verzeichnis mit selbigen geloescht. Immerhin bis zum kompilieren ging es nun gut. Dann beim Installieren wieder bekannte Fehlermeldung, ein "__qrndv" sei nicht gefunden worden...
Also mal in das Makefile geschaut und gefunden, dass da was bei den Optionen steht, dass Assemblerbefehle einschraenkt.. einfach mal munter auskommentiert (das kann eklig werden, wenn die fuer i386 sind, aber was solls... Computer ist Computer, wie meine Mutter mal sagte, als ich versuchte zu erklaeren, was ein HPPA ist) und neuen Anlauf genommen. Und den tapferen belohnt das Glueck, die libgcrypt baute komplett, installierte und es bildete sich ein Package :)
Danach liess sich auch vpnc aus dem Port bauen und lief verzüglichst. Nun muss ich nur noch den Port mal veroeffentlichen (also in die OpenBSD-Ports hereingeben und nicht nur hier) und dann kann ich sagen
Case Closed.

Stichworte:


Impressum