Zugschlusbeobachtungen (Entries tagged as hp)

ssh-Zugriff auf ProCurve-Switches automatisieren

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 24 Sep 2008 18:00:00 +0200

In HP ProCurve und ssh habe ich dokumentiert, wie man einem ProCurve-Switch beibringen kann, per ssh zum Management erreichbar zu sein. Leider wird “ssh manger@switch <command>” nicht unterstützt, so dass man Expect braucht, um den Switch zu bedienen.

Nun sind TCL und ich nicht gerade die allerbesten Freunde, und ich erinnere mich mit Schaudern daran, wie ich vor Jahren den Status eines Infortrend-RAIDs mit Expect aus der seriellen Schnittstelle herausgekitzelt habe, um über den Nagios Alarm zu schlagen, wenn eine Platte ausfällt. Also machen wir’s diesmal in Perl.

Noch schwerer wird’s, wenn man die Ausgabe des Switches weiterverarbeiten möchte: Denn das, was aus dem Expect herausfällt, ist voller Steuerzeichen. Hier hilft Term::VT102, ein Perl-Modul, das im Speicher ein VT102-Terminal simuliert, dessen Bildschirm man nach Abschluß der geplanten Aktion auslesen kann. Das habe ich mit einem Scroll-Hook gelöst, der die Daten, die aus dem virtuellen Terminal herausscrollen, in ein Array schreibt. Zum Schluß werden dann einfach genug CRs in das Terminal gekippt, dass auch die letzte Bildschirmseite in unserem Array gelandet ist.

Um die Eigenheiten des Switches zu Umschiffen und sicherzustellen, dass die Daten trotzdem lesbar sind, muss man dem VT102 noch Teile der Cursorbewegung abgewöhnen: Der Switch positioniert den Cursor oft hart, und das terminal kommt dabei durcheinander, wenn die im Switch eingestellte Terminalgröße nicht richtig ist.

Hier ein bisschen Perl, um das gewünschte Verhalten zu simulieren:

#!/usr/bin/perl -wT

package My::Expect;
use Expect;
use Carp;
our @ISA = qw(Expect);

sub expectordie {
    my $self=shift;
    my $timeout=shift;
    if( !defined($self->expect( $timeout, @_ )) ) {
        croak “expectordie failed”;
    }
}

sub send {
    my $self=shift;
    my $send=shift;
    my $debug = $self ? ${*$self}{exp_Debug} : $Expect::Debug;
    my $internal = $self ? ${*$self}{exp_Exp_Internal} : $Expect::Exp_Internal;

    print STDERR “send $send” if ($debug or $internal);
    $self->SUPER::send($send);
}

1;

package main;

use strict;
use Term::VT102;

$ENV{“PATH”}=“/sbin:/bin:/usr/sbin:/usr/bin”;
$ENV{“CDPATH”}=“”;

my @history;

sub my_code_CUP {
    my $self = shift;
    $self->{’x’}=1;
}

sub scroll_down {
    my ($vtobject, $type, $toprow, $numrows, $private) = @_;

    if ($type eq ‘SCROLL_DOWN’) {
        for( my $i=0; $i<$numrows; $i++ ) {
            push( @history, $vtobject->row_plaintext($toprow+$i) );
        }
    }
}

sub filteroutput {
    my $ignorelines=shift(@_);
    my $input=join(“”,@_);
    my $output;
    my $cols=1000;
    my $rows=25;

    my $term = Term::VT102->new (’cols’=>$cols, ‘rows’=>$rows);
    $term->{’_funcs’}->{’CUP’}=\&my_code_CUP;
    $term->callback_set (’SCROLL_DOWN’, \&scroll_down);

    $term->process($input);

    # scroll out the rest
    for( my $i=0; $i<$rows; $i++) { $term->process(“\n”); }

    # ignore given number of lines
    for( my $i=0; $i<$ignorelines; $i++) { shift @history; }

    foreach( @history ) {
        s/\s*$//;
        $output.=“$_\n”;
    }
    return $output;
}

my $userhost=shift @ARGV;
if( $userhost =~ /([a-zA-Z0-9\.@]*)/ ) {
    $userhost = $1;
} else {
    die “Bad chars in command line\n”;
}
my $command=join(“ ”,@ARGV);

my ($user, $host) = split(/@/, $userhost);

my $output=“”;
my $timeout = 4;
my $exp = My::Expect->spawn(“ssh $user@$host”)
  or die “Cannot spawn ssh: $!\n”;
$exp->debug(0);
$exp->raw_pty(1);
$exp->log_stdout(0);
$exp->expectordie($timeout, ‘Press any key to continue’);
$exp->send(“\n”);
$exp->expectordie($timeout, ‘-re’, ‘[a-z0-9]+# ‘);
my $prompt = $exp->match();
$exp->send(“term length 999\n”);
$exp->expectordie($timeout, “$prompt”);
$exp->send(“$command\n”);
$exp->log_stdout(0);
while( $exp->expect($timeout, (’MORE --, next page: Space, next line: Enter, quit: Control-C’,
“$prompt”) ) == 1 ) {
    $exp->send(“ ”);
    $output.=$exp->before();
}
$output.=$exp->before();
$exp->log_stdout(0);
$exp->send(“logout\n”);
$exp->expectordie($timeout, ‘Do you want to log out [y/n]? ‘);
$exp->send(“y\n”);
if( $exp->expect($timeout, ‘Do you want to save current configuration [y/n]? ‘, ‘closed by remote
host.’)==1 ) {
    $exp->send(“y\n”);
    $exp->expectordie($timeout, ‘closed by remote host.’);
}
$exp->expectordie($timeout, eof);
$exp->soft_close();

print filteroutput(1, “$output”);

print “\n”;

HP ProCurve und ssh

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 09 Sep 2008 17:49:45 +0200

Das hier muss man in einen ProCurve-Switch reinpasten, damit er danach per ssh konfigurierbar ist:

ip ssh key-size 1024
crypto key generate ssh rsa
ip ssh version 2
ip ssh
aaa authentication ssh login public-key none
aaa authentication ssh enable public-key none
copy tftp pub-key-file <server-address> <file-name.pub> manager

Falle Nummer Eins: Der Kommentar zum Public Key darf kein Leerzeichen enthalten

Falle Nummer Zwei: Auch per ssh nimmt der Switch keine Kommandos auf der Kommandozeile entgegen, “ssh manager@switch show running-config” kann man also leider knicken. Man muss sich dann doch mit expect einen abbrechen, muss aber immerhin keine Klartextpassworte hinterlegen. Aber der passphraselose Key gibt natürlich trotzdem die volle Kontrolle über den Switch.

Von Kompatibilitätslisten und USB-Sticks

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 11 Jun 2008 11:00:00 +0200

Ich habe mich endlich auf einen USB-Stick-Typ geeinigt, den ich in Zukunft bevorzugt verwenden möchte: Den SanDisk Cruzer Micro. Zwar nicht besonders klein, aber auch nicht besonders groß, mit halbwegs günstigem Preis, und zurückziehbarem USB-Verbinder. Das bedeutet, dass keine Kappe verloren gehen kann und das Ding auch robust genug ist für das Schlüsselbund. Die dazugehörige “U3-Software”, die einem Windows ganz unkompliziert das Kaffeekochen beibringen soll, ignoriere ich völlig und benutze die Sticks halt als wären es ganz normale USB-Sticks.

Als USB-ZIP-Disk formatiert booten alle Rechner ganz prima von den Sticks. So gehört es sich ja auch. Nur gewisse hp-Server zicken.

Namentlich geht es um ältere Server vom Typ DL140, die zwar von echten Serverfans nicht als “echte Server” bezeichnet werden, aber dennoch den Segen in Form von hp-Logo und -Preisschild tragen. Die Maschinen sind zwar eigentlich als billiges austauschbares Element von Compute-Clustern etc konzipiert, aber aufgrund ihrer Hardwareausstattung als Server für moderne Linuxe prädestiniert. So sind einige dieser Kisten inzwischen in meinem Aufgabenbereich gelandet.

Im Normalfall bootet der DL140 auch prima von einem als USB-ZIP formatierten Stick, wie es die allermeisten Rechner in meinem Umfeld, die neu genug sind, auch tun. Nur von den SanDisk-Sticks wollen sie nicht. Und zwar wird der SanDisk-Stick entweder gar nicht oder doppelt erkannt, und dann wird doch von der Platte gebootet. Leider wird der Ende-des-Selbsttest-Screen nur einen Sekundenbruchteil lang angezeigt, so dass die Diagnose ein wenig schwer ist. Auch ein BIOS-Update (dank memdisk auch in der von hp gewählten Form des Floppy-Images auch ohne Floppy halbwegs schmerzarm) auf die aktuelle Version hilft nicht; das in manchen Foren empfohlene Entfernen der angeblich auf einer für Normalsterbliche unsichtbaren “Partition” abgelegten U3-Software mit einem proprietären Windows-Tool bleibt ebenfalls wirkungslos.

Also muss der eigentlich in den höchsten Tönen gelobte hp-Support, der in den letzten Tagen für mich schon einmal versagt hat, noch einmal ans Werk. Da für Server kein Chat angeboten wird, konservativer per Webformular.

Das Webformular fragt alles mögliche bis zur Schuhgröße des letzten Technikers, unter anderem auch das installierte Betriebssystem. Ich mache den Fehler, antworte wahrheitsgemäß “Debian GNU/Linux 4.0” und erkläre in der ~~EIngabebriefmarke~~ausreichend groß dimensionierten Textarea meine technische Herausforderung.

Die Antwort kommt auf dem Fuße innerhalb von wenigen Stunden: Debian GNU/Linux 4.0 sei nicht supported, und mein USB-Stick steht nicht auf der Kompatibilitätsliste. Man werde deswegen den Fall schließen; und die Webseite, auf die mein Ticket nun verweist, enthält praktischerweise weder eine Mögilchkeit zum Antworten noch eine, mit der das Ticket wieder geöffnet werden kann. Der gestreckte Mittelfinger ist somit endgültig.

Auf der Kompatibilitätsliste stehen natürlich nur USB-Sticks mit hp-Preisschild, und zwar ganze drei Stück aus der Kollektion von 2004. Das halte ich für heute völlig unzureichend.

Ich glaube, ich muss mal darüber bloggen, was Hardwarehersteller, Endkunden und ich unter “Support” verstehen. Ich habe nämlich den Verdacht, dass da drei ganz verschiedene Definitioen herauskommen.

Ich erwarte von “Support”, dass der Hersteller sich die Wehwehchen seiner Kunden wenigstens so lange anhört, bis jemand mit rudimentärem Sachverstand beurteilen kann, ob man es nicht mit einem offensichtlichen Hardware- oder Firmwarefehler zu tun hat, wie es hier der Fall ist. Schließlich ist im konkreten Problem das auf der Festplatte installierte Betriebssystem völlig irrelevant, weil nämlich der Rechner zum Zeitpunkt des Fehlers noch gar nicht gebootet hat. Außerdem erwarte ich, dass der Hersteller wenigstens eine Datenbank bekannter Macken führt, damit er seinem Kunden im Zweifel sagen kann, ob es sich um ein bekanntes Problem handelt oder ob es vielleicht einen Workaround gibt.

Ich erwarte ausdrücklich nicht, dass mir der Herstellersupport aus dem Kopf herbeten kann, wie man udev unter Arch Linux dazu bringt, einen eingesteckten USB-Stick automatisch zu mounten und als Swapdevice einzurichten, aber ich erwarte dass man mir konkrete technische Fragen zur Hardware auch dann beantwortet, wenn ich angegeben habe, dass auf dem System ein Linux installiert ist.

Außerdem finde ich es zum kotzen, dass hp auf der einen Seite große Töne spuckt, dass man Linux ja für soooooo wichtig hält, Debian-Entwickler bezahlt, mit großem Tamtam auf jeder Linux-Messe vertreten ist und dann in der Praxis die Anwender in dieser Form im Regen stehen lässt. “Wir unterstützen Windows, Windows und Windows, und wenn wir Linux sagen meinen wir Redhat”.

Dass es sich bei der Macke des DL140 mit meinen SanDisk-Sticks um einen BIOS-Fehler handeln muss, wird daraus klar, dass der DL140 von identisch partitionierten Sticks anderer Hersteller problemlos startet, und die SanDisk-Sticks von allen mir bekannten anderen Rechnern ebenso problemlos geschluckt werden.

Ach, was ist es so einfach, einen USB-Port so zu spezifizieren, dass nur eigene Devices unterstützt werden, und das dann auch zur Verweigerung von Support zu enforcen. Warum nicht gleich eine proprietäre, schon mechanisch inkompatible Spezialschnittstelle? Das sorgt wenigstens dafür, dass die Anwender auch das, was sonst problemlos funktionieren würde, nicht benutzt, allerdings auch für schlechte Presse, weil so der Nichtsupport gleich auf den ersten Blick offensichtlich ist. Wann geht es los, dass der Support verweigert wird, weil man das unterstützte Betriebssystem bei der Installation vom CD-ROM-Laufwerk eines Fremdherstellers gebootet hat?

hp Supportchat völlig unbrauchbar

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 02 Jun 2008 12:24:31 +0200

Ich möchte ein Notebook hp nc 8000 per Wake-on-LAN aufwecken, um sicherzustellen, dass es möglichst immer läuft. Leider habe ich im BIOS keine Einstellung für Wake-on-LAN gefunden, und ein per etherwake oder wakeonlan gesendetes magisches Paket wird ignoriert. Also versuche ich mal den hp-Supportchat, vielleicht bin ich ja nur zu doof zum suchen.

Ich bekomme innerhalb von wenigen Minuten Pavel K als Supportspezialisten zugewiesen, der zunächst nochmal den Typ und die Seriennummer des Notebooks abfragt. Er antwortet dann, dass Wake on LAN beim nc8000 nicht unterstützt wird. Lüge Nummer eins, denn schon in der Produktbeschreibung steht natürlich dass Wake on LAN unterstützt wird, und außerdem funktioniert das bei unseren Notebooks in der Firma ja auch prima.

Als nächstes versucht Pavel, mich mit einem BIOS-Update abzuspeisen und pastet mir den LInk auf das Bios F.0C vom 05. März 2004. Wir erinnern uns, in diese Falle bin ich am Wochenende auch schon getappt. Ich weise Pavel darauf hin und bitte ihn, mal das SP-Paket auszupacken und ins README zu gucken. Das aktuelle Bios F.18 ist bereits installiert.

Es folgt das Unvermeidliche: Er sagt, ich soll im Gerätemanager mal das und das nachgucken. Ich antworte ihm korrekt und höflich, dass auf dem System Linux installiert ist, und er nutzt diese Gelegenheit, um sich final aus der Affäre zu ziehen: Linux sei “als Software” auf dem nc8000 nicht unterstützt. Lüge Nummer zwei, denn hp ist im Bereich Linux-Unterstützung sehr rührig.

Meinen Hinweis auf die “Linux auf dem nc8000”-Webseite innerhalb des hp-Webangebots kommentiert er damit, dass das nc8000 zwar für Linux zertifiziert, aber nicht supported sei. Ich gebe auf.

Fazit: Die Unterstützung von Linux durch hp ist nach wie vor hauptsächlich ein Lippenbekenntnis, weil die Leute an der vorderen Supportfront nicht ausgebildet sind oder anders lautende Dienstanweisungen haben. Linux ist immer noch die finale Ausrede, sich mit “nicht supported” davonzustehlen.

Und wie Wake-on-LAN funktioniert, weiss ich immer noch nicht.

BIOS-Update a la hp

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 31 May 2008 08:59:35 +0200

Im Zuge einer doppelten Display- und Festplattentransplantation in meinem Notebook muss ich das Referenz-Windows[1] neu installieren. Da ich nun schon auf der Treiberseite von hp bin, fällt mir auf, dass es ein BIOS aus dem September 2007 gibt. Die Versionsnummer F.0C find ich zwar seltsam (installiert ist F.18 aus 2006), aber probieren wir das mal.

Es folgt ein Kampf mit jahrzehnte alter PC-Technik

Fußnoten
[1] ich installiere üblicherweise ein Windows XP in eine 3-GB-Partition auf jeder Platte eines Systems, für das ich Herstellersupport erwarte. Auf diese Weise kann ich einem renitenten Servicetechniker zeigen, dass der Hardwarefehler nicht nur mit diesem komischen Linuxdings auftritt, sondern auch mit dem Qualitätssystem des Marktführers. Habe ich bisher noch nie gebraucht, die Techniker von hp sind da ausgesprochen professionell ausgebildet.

Dieses neueste BIOS gibt es erstaunlicherweise - entgegen aller anderen BIOS-Updates auf der Seite - nicht als Windows-Programm (was für mich in dieser Situation - wir erinnern uns, ich war gerade dabei XP zu installieren - sehr praktisch gewesen wäre), sondern nur als “FreeDOS Bootable” in der Größe von 1.44 MB.

Superidee, hp, ein BIOS-Update für ein diskettenlaufwerkloses Notebook ausschließlich als bootbare Diskette anzubieten. Hat da mal wieder jemand nur bis zur eigenen Nasenspitze gedacht?

Das selbstextrahierende Archiv im handlichen und zeitgemäßen .exe-Format lässt sich natürlich mit unzip nicht auspacken (warum denn auch den Standardpacker benutzen, wenn das so schön proprietär geht), aber Wine führt das Archiv prima aus. Wir brechen den Vorgang dort, wo darum gebeten wird, eine Diskette in das nicht vorhandene Laufwerk A einzulegen ab und pulen uns den ausgepackten Inhalt des Archivs aus ~/.wine/fake_windows/Windows/profiles/mh/Desktop. Dort finden wir ein F0C.IMG und ein COPYDISK.EXE und ein wenig README. Das README lassen wir links liegen, was sich später als Fehler erweisen wird.

Das F0C.IMG lässt sich weder loopback mounten noch sagt file etwas anderes als schnödes “data”. Mit most -b reingeguckt, sieht es entfernt aus wie ein Disketten-Bootsektor. Komisch, das. Aus dem IRC kommt der Hinweis auf losetup --offset, und schnell ist ermittelt, dass da 32 Bytes Extraheader vorne dran sind. Nun lässt sich das Image mounten.

Kurze Recherche später: FreeDOS von USB-Stick booten zu lassen geht zwar, ist aber auch dann, wenn man nach dem Boot den Stick nicht mehr braucht, ein Kampf. Wenn man den Stick danach noch verwenden will, braucht’s auch noch einen USB-Treiber für DOS. Wir legen diese Idee zu den Akten.

Nächster Versuch: Das Diskettenimage direkt vom USB-Stick booten. Aber weder direkt mit dd auf /dev/sda geschrieben, noch in der Hoffnung eine Festplattenstruktur sei für das BIOS einfacher, ebenfalls mit dd auf /dev/sda4 geschrieben, gibt es etwas anderes als das seit 20 Jahren vertraute “Non system disk or disk error”.

Mir platzt der Kragen und ich opfere einen CD-Rohling. Ein leeres Daten-CD-Projekt mit dem Floppy-Image als Bootimage (Floppyemulation, El Torito sei Dank) ist mit k3b schnell erstellt und gebrannt und das Notebook bootet.

Und beschwert sich, dass das zu flashende neue BIOS älter ist als das, was bereits installiert werden soll: Installiert ist F.18 von 2006, installiert werden soll F.0C vom 05. März 2004. Das README bestätigt, dass der Inhalt des Archivs über drei Jahre älter ist als das Datum, mit dem das Image auf der Webseite von hp angegeben ist (und natürlich, ganz oben steht).

Recht schönen Dank, hp, das habt Ihr mal wieder so richtig gut gemacht. Not.