Re: Palm Tungsten T / externes IrDA

From: Oliver Fromme <olli(at)lurza.secnetix.de>
Date: Thu, 21 Apr 2005 12:47:15 +0200 (CEST)

Marian Hettwer <MH(at)kernel32.de> wrote:
> On Mi, 20.04.2005, 14:29, Oliver Fromme sagte:
> > [...]
> > Der einzige wichtige Anwendungszweck, der noch existiert,
> > ist für serielle Konsolen unter UNIX. Aber auch das ist
> > nur »Legacy« und nicht gerade eine besonders zeitgemäße
> > Art für Remote-Management. Daß es auch besser geht, zeigt
> > z.B. HP/Compaq mit iLO, und die anderen »großen Tiere«
> > (Dell, IBM, ...) bieten ähnliches mit ihren Servern.
>
> Da möchte ich vehement wiedersprechen.

Das ist Dein gutes Recht. Ich widerspreche Dir ja auch.
:-)

> Alle von dir genannten Methoden sind propritär

Na und? Da es keinen Standard gibt, existieren natürlich
unterschiedliche Lösungen bei den verschiedenen Herstel-
lern. Das interessiert mich aber erstmal genausowenig wie
die Farbe des Gehäuses, solange die Lösungen funktionieren.

> Ebenso lassen sich diese nicht gut, oder nur unter
> Vernachlässigung von Budget (Teuer) und Sicherheit skalieren.

Blödsinn. Das skaliert nicht schlechter als ein Ratten-
schwanz von RS232-Kabeln. Eher besser, da Du nicht für
jedes Rack zweiundvierzig RS232-Ethernet-Konverter oder
einen (proprietären, auwei auwei!) Terminal-/Consolen-
Access-Server o.ä. benötigst (z.B. Cyclades), auf dem
möglicherweise noch Linux läuft (igittigitt!).

(Bitte Smileys sparsam hinzufügen.)

> iLO, heißt eine IP Adresse pro Server zusätzlich

Wo ist das Problem? Man verwendet selbstverständlich ein
eigenes, privates Management-Netz dafür. In 10/8 hast Du
ca. 2^24 IP-Adressen zur Verfügung. Im Idealfall gehen
die Strippen an einen eigenen Management-Switch bzw. in
ein eigenes Management-VLAN.

> und keine einheitliche sichere Managementoberfläche

Kannst Du das präzisieren, was Du mit »einheitlich sicher«
meinst? Ich kann den Kritikpunkt nicht nachvollziehen.

> falls man mal 500 iLO Server hat.

Und wenn's 5000 sind. Was soll's.

> IBM, gerade bei den Blades, gibt dir eine Weboberfläche fürs Management
> von ca. 14 Blades. Dazu brauch es immer Java, und man hat wieder nur 14
> Blades auf einen Blick.

Diese Software kenne ich nun gerade nicht, aber man kann
sicherlich immer Beispiele finden, bei denen das Problem
des Remote-Management schlecht gelöst ist. Wenn sich das
nicht selbst lösen läßt und es inakzeptabel ist, dann ver-
meidet man halt diesen Hersteller.

> Dell hat ebenso wie iLO das selbe Manko. Ein Serviceprozessor pro Server.

Wieso, wieviele willst Du denn pro Server haben? Zwei,
vier, ...? Im Falle von HP ist das ein kleiner, billiger
(Embedded-)MIPS-Prozessor, wie er in jedem besseren Kühl-
schrank eingebaut ist.

Ich sehe da kein »Manko«.

> > FreeBSD unterstützt übrigens seit kurzem serielle Console
> > und remote gdb via IEEE1394 (Firewire), siehe dconschat(8).

(Mit den von Bernd aufgezeigten Nachteilen.)

> DAs ist angenehm zu hören, und es bleibt abzuwarten und zu hoffen, mit
> welchem Aufwand man sich eigene Konsolenserver basteln kann, die Firewire
> zu den Servern sprechen.

Naja, Konsolenzugang (d.h. Zugang zur UNIX-Systemcnsole)
alleine ist noch kein vollwertiges Remote-Management.
Da gehört noch einiges mehr dazu, und das kann ein Kon-
solenserver nicht leisten, egal ob RS232 oder Firewire.

> > Ich schrieb mindestens zweimal »PC«.
>
> Entschuldige.
> Mittlerweile gehts offensicht ums Remote Management ;)

Genau, und da gewinnt man heutzutage mit 'nem RS232-Zugang
allein keinen Blumenstrauß mehr, zumindest wenn man eine
nennenswerte PC-Serverfarm hat.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"UNIX was not designed to stop you from doing stupid things,
because that would also stop you from doing clever things."
        -- Doug Gwyn
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 21 Apr 2005 - 12:48:25 CEST

search this site