Re: Palm Tungsten T / externes IrDA

Marian Hettwer <MH(at)kernel32.de> wrote:
> [...]

Wie es aussieht, haben wir beide etwas unterschiedliche
Vorstellungen von Remote-management, die nicht wirklich
unter einen Hut zu bekommen sind. Insofern ist die wei-
tere Diskussion wohl sinnlos.

Vielleicht können wir uns aber auf den Punkt einigen, daß
zum Remote-management unbedingt ein Zugriff auf die Kon-
sole eines Servers (und zwar nicht nur die UNIX-Konsole)
gehört. Über das Wie und alles weitere kann man (offenbar)
streiten.

Ein paar Bemerkungen muß ich aber noch loswerden ...

> On Do, 21.04.2005, 17:10, Oliver Fromme sagte:
> > Erstens crimpt man sich für eine RS232-Verbindung kein
> > Cat5-Kabel, wie Bernd ganz richtig bemerkte. Zweitens
>
> Da stimme ich nicht mit Bernd überein. CAT-5 Kabel sind in einem RZ in
> rauhen Mengen vorhanden und vorverlegt. Bevor ich mich also hinstelle und
> selber Flachbandkabel zusammenkrimpe für 600 Server, nehme ich lieber
> CAT-5 Kabel die fertig vorkonfektioniert sind.

Und hast im Schnitt ca. 600m überflüssige, teure Cat.5-Ka-
bel in den Schränken herumhängen. Für RS232-Verbindungen
Kabel passender Länge von der 1000m-Flachbandrolle zu crim-
pen, geht ziemlich schnell (man muß da ja keine Adern sor-
tieren oder so) und dürfte sogar noch billiger sein, auch
die Arbeitszeit berücksichtigend.

(Wenn man nur max. einen Meter überbrücken muß, kann man
solche Kabel auch für 10base-T-Ethernet hernehmen. Been
there, done that.)

> An den seriellen Port dann noch einen kleinen Adapter, der die 8 Adern so
> verdreht, daß man am Ende CAT-5 drüber spricht.

Den Satz verstehe ich jetzt nicht. Cat.5 ist eine Kabel-
spezifikation, kein Protokoll.

> > Einen Switch hat
> > man eh in jedem Rack, und wenn der nicht genug Ports hat,
> > steckt man noch einen dazu.
> >
> In RZ's werden gerne teure Cisco Switches verbaut. Ich garantiere dir, daß
> ein Cyclades Konsolenserver preiswerter ist.
> Du benutzt in nem RZ doch nicht den D-LINK Switch ausm Supermarkt.

Du solltest nicht von einem Extrem ins andere fallen. Es
genügt durchaus ein üblicher 48port-Switch, der nicht un-
bedingt managementfähig sein muß. In diesem Fall würde es
sogar ein 10Mbit-Modell tun, das man häufig noch in einem
Lagerraum zu Dutzenden herumliegen hat, weil man sie für
nichts anderes mehr brauchen kann. Pech hat man natürlich,
wenn ein übereifriger Mitarbeiter die ausrangierten Dinger
inzwischen auf eBay vertickert hat ... :-)

> > Wobei ich es für gefährlich und falsch halte, »sicher« mit
> > SSH gleichzusetzen. Es gibt genug Sicherheitsprobleme, die
> > SSH nicht löst, mal von den regelmäßigen Bugs in SSH selbst
> > ganz abgesehen. Und TELNET ist sicher genug, wenn man ge-
> > nau weiß, unter welchen Bedingungen man es einsetzen kann;
> > siehe oben.
>
> Dein letzter Satz suggeriert, daß SSH in einigen belangen nicht sicher
> ist,

Korrekt. Leider gibt es viele, die ssh blind vertrauen.
Wie ssh tatsächlich funktioniert, wissen die Wenigsten.

> und wenn man nur genug drauf achtet, TELNET sicher genug ist.

Nicht grundsätzlich, aber es gibt Anwendungsfälle, wo das
der Fall ist.

> Ich hoffe du beliebst zu scherzen.

Nein, das ist mein voller Ernst.

> Ergo: Ich will mal davon ausgehen, daß es vernachlässigbar ist, ob 2 Meter
> serielle Kommunikation vom Konsolenserver zum seriellen Port des Servers
> hin unverschlüsselt von statten gehen.

Kommt auf die Umstände an. Im Serverraum einer Firma ist
es egal. Wenn ich aber einen Server mit sensitiven Daten
im Rack eines CoLo-Providers zwischen dutzenden von anderen
Kisten stehen habe, wo ich nichtmal weiß, wem die gehören,
ist's mir nicht egal.

> > Davon abgesehen: Wenn man eine Farm für einen bestimmten
> > Zweck aufbaut, kauft man normalerweise die Rechner beim
> > selben Hersteller. Nicht etwa zehn bei HP, sieben bei
> > Dell, vier bei IBM ...
>
> Im Normalfall nimmt man für große Installationen zwei Hersteller, um
> Unabhängig zu bleiben, falls es bei einem mal zu Problemen kommt
> (Lieferbarkeit, schlechter Support, Preisveränderungen,
> Produktabkündigungen).

Das halte ich eher _nicht_ für den Normalfall. Im Normal-
fall nimmt man einheitliche Hardware, solange man nicht
zwingende Gründe hat (weil man z.B. für bestimmte Dinge
Suns benötigt).

Das gleiche kann Dir im übrigen auch mit den Konsolenser-
vern passieren. Morgen ist Cyclades pleite, und man muß
sich Lantronics, Dominion oder sonstwas hinstellen, die
natürlich auch anders funktionieren, da es keinen allge-
meinen Standard gibt. Ist halt auch alles proprietär.

> Und da wiederspreche ich, da es durchaus leichter ist, wenn man sein
> Remote Management vorher von den Herstellern der Server (und
> Netzwerkkomponenten) getrennt hat.

Und dazu zählst Du nicht den Hersteller der Konsolsenserver?

> > > Es mag vielleicht eine Frage des Geschmacks sein, aber ich manage meine
> > > FreeBSD (und Linux) Server doch über SSH an der ner Shell.
> >
> > Das tue ich auch, und zwar ganz normal über TCP/IP, ohne
> > daß da irgendeine RS232-Bremse dazwischen ist. Und ich
>
> Bremse ?
> Dann stelle halt nicht 9600 BAUD ein, sondern 57,6 kBaud.

Standard ist 9600/8N1. Das ist das einzige, was garantiert
übergreifend mit allen Komponenten funktioniert, von der
USV übers Server-BIOS bis zum Sun-LOM/ALOM-Interface.

(Übrigens geht letzteres auch über Ethernet, anstatt wie
bisher über die veraltete serielle Schnittstelle. Auch
Sun kommt am Fortschritt nicht vorbei. ;-)

> > finde es auch gut, daß die Server SNMP-Traps schicken,
>
> siehe oben ... kann ein Konsolenserver auch.

Ich will aber aus erster Hand wissen, wenn mit dem _Server_
etwas passiert, und nicht, welche eingeschränkten Beobach-
tungen der Konsolenserver macht.

> > wenn sie downgehen. Und daß ich remote auf den Reset-
> > Knopf drücken und remote eine virtuelle CD einlegen kann.
>
> Remote Resetknopf war oben durch eine Integration mit schaltbaren
> Steckdosenleisten gegeben.

Was hat ein Resetknopf mit der Steckdose zu tun?

> Eine CD remote einlegen, halte ich für sinnlos, da es für diesen
> Anwendungsfall einer Neuinstallation auch PXEBOOT inklusive kompletten
> Framework zur automatischen Installation gibt.

Ich kenne (und nutze) PXE -- und auch seine Nachteile. Ich
habe schon Diskless-Rechner remote gebootet, als PXE noch
gar nicht existierte.

> > Schonmal was von Port-Forwarding oder Tunneln gehört?
> > (Nicht daß das notwendig wäre, aber gehen tut das.)
>
> Natürlich ist mir Portforwarding (durch Paket Filter) und Tunneln (via
> SSH) bekannt.
> Ich weiß leider nicht, wie ich einen Tunnel über mehrere Hosts komfortabel
> aufbauen kann.

Genauso wie Du ihn über einen Host aufbaust, nur daß Du das
mehrfach hintereinander kaskadierst. Pro Host-Host-Verbin-
dung ein Kommando (bzw. lediglich eine zusätzliche Option
bei ssh, denn einloggen tut man sich normalerweise eh).
Und wenn man sich eine weitere Option nicht merken kann
und/oder zu faul zum Tippen ist, macht man sich ein Skript,
eine Shell-Funktion oder einen Alias dafür.

> > Und wenn der Umsetzer ein Problem hat? Du hast dort in
> > jedem Fall einen weiteren potentiellen Point-of-failure.
>
> Den Single Point of Failure hast du auch in einem iLO Board.

Das betrachte ich als Teil der Hardware, und Server sind ja
üblicherweise eh redundant ausgelegt. übrigens habe ich
noch nie von einem ausgefallenen iLO-Modul gehört oder gar
selbst sowas erlebt. Üblicherweise fallen Fastplatten aus,
Lüfter, Prozessoren oder RAM-Bausteine. In seltenen Fällen
auch mal ein Mainboard-Chipsatz. Aber nie ein iLO-Board.
Die Teile sind absichtlich robust ausgelegt.

> Da du aber ein Glück nicht jeden Tag auf den Remote Management
> Schnittstellen rumreitest und der Konsolenserver deiner Wahl auch SNMP
> spricht und via NAGIOS überwacht werden kann, wirst du einen Ausfall des
> Gerätes früh genug mitbekommen ;)

Toll, und wenn der Konsolenserver ausfällt, sind auf einen
Schlag 40 Server vom Remote-Management abgeschnitten.

> Und da so ein konsolenserver um längen Preiswerter ist als eine Reperatur
> eines Servers,

Nö, das sollte gleichgültig sein, da in beiden Fällen der
Servicevertrag mit dem Zulieferer zum Tragen kommt. Wer
Serverfarmen in der Größenordnung betreibt, _hat_ einen
entsprechenden Servicevertrag (oder sehr gute Gründe, kei-
nen zu haben, aber dann dürfte es ihm auch wiederum egal
sein).

Um's nochmal ganz klar zu sagen: iLO (und LOM und was es
sonst alles noch gibt) ist sicherlich nicht der Weisheit
letzter Schluß und hat auch seine Schwachpunkte. Aber es
ist der richtige Weg, da die klassische serielle Schnitt-
stelle einfach ausgedient hat.

> Beziehungsweise hoffe ich, daß du bei diversen OpenSSH T-Shirts nicht zu
> viele Zuckungen bekommst ;-)

OpenBSD/OpenSSH ist für seine markigen, aber nicht immer
fachlich korrekten Propagandasprüche bekannt.

> RIP
> telnet
> 1972 - 1999
> won't crypt

Das ist nichts weiter als eine Lüge. Das BSD-telnet hat
schon seit ewigen Zeiten Krypto- und Kerberos-Support.
Es ist sogar umgekehrt: telnet unterstützt diverse Dinge,
die ich bei OpenSSH schmerzlich vermisse (z.B. Linemode,
Delayed-Ack, -c none).

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.
"anyone new to programming should be kept as far from C++ as
possible;  actually showing the stuff should be considered a
criminal offence" -- Jacek Generowicz
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message