Re: Palm Tungsten T / externes IrDA

On Do, 21.04.2005, 17:10, Oliver Fromme sagte:
> Marian Hettwer <MH(at)kernel32.de> wrote:
> > On Do, 21.04.2005, 12:47, Oliver Fromme sagte:
> > > Marian Hettwer <MH(at)kernel32.de> wrote:
> > > > 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.
> >
> > Tun sie das einwandfrei ?
>
> Ja.
>
ziemlich pauschal die Aussage...

> > Braucht nicht auch iLO einen Javafähigen Browser
>
> Nur wenn Du eine _graphische_ Oberfläche vom Server zu Dir
> auf den Browser umleiten willst. Dann ist das Java-Applet
> Pflicht.
>
Das heißt, iLO gibt mir die Möglichkeit (auch für mehrere Personen
gleichzeitig) via ssh auf die systemkonsole zu kommen ?

> > und dann funktioniert das Applet auch nur dann und wann (will heissen
> mit
> > _genau_ der richtigen JRE ?)
>
> Es scheint mir durchaus recht robust zu sein, zumindest
> sind mir keine Probleme bekannt. HP nennt auch offiziell
> Firefox als unterstützten Browser, d.h. nicht nur Windows
> mit MS-IE.
>
das klingt ja schonmal positiv.

> > >
> > > Blödsinn. Das skaliert nicht schlechter als ein Ratten-
> > > schwanz von RS232-Kabeln. Eher besser, da Du nicht für
> >
> > Ob ich jetzt ein CAT-5 Kabel pro seriellen Port hernehme, oder 1 CAT-5
> > Kabel pro iLO, wo also einmal Ethernet drüber läuft und einmal RS232,
> > macht vom Platzbedarf keinen Unterschied.
>
> 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.
An den seriellen Port dann noch einen kleinen Adapter, der die 8 Adern so
verdreht, daß man am Ende CAT-5 drüber spricht.

> ist nicht der Platzbedarf das entscheidende, sondern
> die Tatsache, daß Du zusätzliche proprietäre Hardware
> benötigst (ein Cyclades o.ä.). Drittens bietet iLO
> auch einen sogenannten Shared-Mode, wo der bereits vor-
> handene System-NIC mitverwendet wird, d.h. _keinerlei_
> zusätzliche Kabel sind dann notwendig.
>
Und für den shared-mode ist ein Treiber für das OS nötig, korrekt ?
Da dreht sich mir nun der Magen um.
Wenn schon Serviceprozessor Marke iLO, dann ohne Eingriff in das OS was
auf dem Server läuft.

> >
> > hehe.
> > Was ihn ja im Falle von Cyclades nicht propritär macht (GPL).
>
> Das kommt drauf an, welche Definition von »proprietär« Du
> verwendest. Auf jeden Fall ist es ein teures, zusätzliches
> Gerät, das man nicht unbedingt haben muß. 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.

> > Genauer
> > genommen, hast du dank solcher 1 HE Büchsen die Möglichkeit bis zu 48
> > serielle Geräte anzuschließen. Der Platzbedarf ist also minimal im
> Rack.
>
> In 1 HE kann ich ebenso einen Standard-Switch einbauen, der
> erheblich billiger sein dürfte, insbesondere da ein RZ so-
> was ja eh im Dutzend kauft und managed.
>
Die RZ's die ich kennengelernt habe, kaufen keine Gigabit Cisco switches
im dutzend und sind froh, wenn sie nicht dauernd neue kaufen müssen, da
selbige doch ins Geld gehen.
Aber egal... das sind Feinheiten.

> > Und auf der Clientseite reicht ein stinknormaler SSH Client.
>
> Dito.
>
erfreulich.

> > Musst also zusätzlich noch sichere
> > Möglichkeiten schaffen um von anderen Netzen (von draussen) sicher
> > reinzukommen.
>
> Die Möglichkeiten müssen eh existieren. Du loggst Dich
> sicherlich nicht direkt von daheim oder einem Internet-
> Cafe auf einem Konsolenserver in einem Rechenzentrum ein,
> auch nicht per ssh.
Es gibt große RZ's die sowas mit Konsolenservern machen. Ist natürlich
gewagt, und ich würde es tunlichst vermeiden.

> Wenn doch, dann weißt Du nichts von Security.
>
Entschuldige, aber ich denke, ich weiß schon etwas von Security ;)
Es ging inital darum, daß du auch nicht über Portforwarding über einige
Hops kommst, ohne dass es unübersichtlich wird.
Beispielsweise:
daheim --> loginhost im RZ --> RechnerX um in Management LAN zu kommen -->
BLADE Center mit Weboberfläche.

Wenn dort am Ende ein iLO hängt, was direkt ssh spricht, okay, wenn es
eine Weboberfläche ist, dann möchte ich doch gerne das SSH tunneling
sehen, was mir über diese diversen hosts hinweg die Weboberfläche nach
Hause holt.

> > Das ist doch Konfigurationsseitig Overkill.
>
> Ein Konsolenserver ist Overkill.
>
Nein, das sehe ich nicht so.

> > Geldlich im übrigen auch teurer.
>
> Ein Konsolenserver ist teurer.
>
Nur wenn du einen billigswitch benutzt. Und dann nochmals nein. Für
Serviceprozesorre aka iLO zahlst du doch auch Geld.

> > Ein ordentlicher Switch, nebst der Infrastruktur um von daheim in
> > dieses abgeschottete Management LAN zu kommen, könnte mehr Kosten, als
> ein
> > Konsolenserver, wo ich 48 Endgeräte anschließe.
>
> Die Infrastruktur für ein Management-LAN (bzw. -VLAN)
> brauchst Du eh. Ich würde einen Konsolenserver nicht
> in ein Produktions-LAN stecken, möglichst nichtmal
> hinter dieselbe Firewall. Das spielt für die Investi-
> tionskosten also keine Rolle.
>
Ich würde einen Konsolenserver in ein Management LAN stecken.
Ich sehe jedoch keinen Grund, einen ordentlichen Konsolenserver nochmals
mit einer Firewall zu sichern.
Wenn du das tust, hast du keine Ahnung von modernen Konsolenservern.
(Freilich würde man alte Annex Terminalserver lieber hinter 3 Firewalls
stecken).

> > > > und keine einheitliche sichere Managementoberfläche
> > >
> > > Kannst Du das präzisieren, was Du mit »einheitlich sicher«
> > > meinst? Ich kann den Kritikpunkt nicht nachvollziehen.
> >
> > mit einheitlich und sicher meine ich, die Möglichkeit auf jedes
> serielles
> > Interface via SSH raufzukommen.
>
> Ich _will_ ja gar nicht auf serielle Interfaces kommen,
> sondern auf die Systemkonsole, bzw. ich will die Server
> remote managen können.
>
Und hinter dem seriellen Interface verbirgt sich die systemkonsole.
Durch selbige kannst du den Server remote managen. Ja, das geht. Wird doch
in der SUN Welt seit äonen so gemacht.

> Genau das kann man mit iLO. Einfach und sicher.
>
Genau das kann man mit nem Konsolenserver genausoeinfach und sicherer bei
weniger administrativen Aufwand.

> > Einheitlich: Immer der selbe Client, immer der selbe Verbindungsaufbau
> > Sicher: SSH
>
> Ja, genau.
>
> 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, und wenn man nur genug drauf achtet, TELNET sicher genug ist.
Ich hoffe du beliebst zu scherzen.
Freilich hat der sshd von OpenSSH auch schon Bugs gehabt. Dafür gibt es
dann kostenlose Updates vom Hersteller des Konsolenservers, die diese
Probleme beheben.
Wie fährst du ein Update auf iLO Servern wenn es einen Bug in SSH gibt ?
Weißt du überhaupt ob HP dort OpenSSH oder ein anderes SSH einsetzt ?!
Wenn nicht, dürfte das ein weiterer Nachteil sein, da du keine Ahnung
hast, wann du ein Sicherheitsproblem hast. Es sei denn, HP sagts
irgendwann.

> Und falls es Dich beruhigt: iLO kann SSH, und dies ist so-
> gar der Default (TELNET ist per Default aus Sicherheits-
> gründen disabled). Und das ist sogar sicherer als Dein
siehe oben ...

> toller Konsolenserver, denn der verschlüsselt nur bis zu
> sich selbst. Auf dem RS232-Kabel wird im Klartext kommuni-
> ziert. Bei iLO geht die Verschlüsselung bis in die Büchse.
>
Wenn du Angst hast, daß ein böser Mensch neben dem RACK steht und auf den
letzten 3 Metern probiert am Kabel zu lauschen (wo er dann RS232 typisch
Highs und Lows sieht), dann hast du in deinem RZ ein Problem mit dem
physischen Zugriffsberechtigungen.
Und wenn diese Aussage ein Argument für iLO sein soll, dann sage ich:
Nagut, mag iLO bis in die Büchse gehen, aber wenn man daneben stehen kann,
ziehe ich den iLO stecker und stecke mir direkt einen Monitor und eine
Tastatur an.

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.

> > Wenn deine iLO Boards in einem eigenen Netz hängen und du einen Browser
> > brauchst um drauf zu kommen,
>
> Browser brauch ich nicht unbedingt.
>
Nicht unbedingt, oder nie ?
Aber gut zu wissen, daß es ohne geht.

> > > > falls man mal 500 iLO Server hat.
> > >
> > > Und wenn's 5000 sind. Was soll's.
> >
> > Es wird um so schwieriger.
>
> Nein, es skaliert linear (Anzahl der Kabel und Ports).
>
Ich rede hier unter anderem auch von den Updates jeglicher iLO Ports,
falls es eine neue Firmware gibt.
Ist das mit ner grossen Schleife die ein SCP tut getan ?!

> > Bietet dir HP für die iLOs eine zentrale Möglichkeit zum User verwalten
> > auf diesen Kisten ?
>
> Es unterstützt z.B. LDAP.
>
Das ist ein Anfang. Wie schauts mit anderen Methoden aus ? (Radius,
Tacacs, Kerberos, NIS)
Ein guter Konsolenserver unterstützt natürlich auch LDAP und die anderen
genannten verdächtigen.
Das ganze dann aber bitte mit der Funktion, "nimm LDAP, wenn host down,
geh automatisch lokal nachgucken".

> > Wie machst du ein Update auf 5000 iLO Boards, falls mal ein Bugfix oder
> > neue Features von HP rauskommen ?
> > 5000 mal mit nem Browser auf die entsprechende HP Maschine surfen ?
>
> Natürlich nicht.
>
Die Frage hatten wir schon oben.
Wie funktioniert das bei iLO ? Über eine spezifische Software von HP (die
dann Geld kostet) ?

> > Ich könnte diese Liste ewig fortführen ;-)
>
> Und ich kann jeden einzelnen Punkt entkräften.
>
Dito.

> >
> > So war das nicht gemeint ;)
> > Natürlich nur einen, nicht vier. Im Idealfall keinen, sondern ein BIOS
> was
> > ordentlich nen Redirect-to-Serial kann.
>
> Wieso Idealfall? Ein unabhängiger Management-Prozessor ist
> natürlich besser als ein Redirect-Krücke im BIOS, die ei-
Ein unabhängiger Managementprozessor setzt voraus, daß die Software die
darauf läuft entsprechend gewartet werden kann.
So wie es bei jeder Software nunmal der Fall ist.
Die Thematik hatten wir schon oben.

> gentlich -- außer Konsolenumleitung -- keine nennenswerten
> Manegement-Features bieten kann.
>
Ein Konsolenserver bietet dir etliche zusätzliche Features, neben dem
einfachen Zugriff auf die Systemkonsole á la eth->rs232.

> > > 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.
> >
> > Man nehme eine Steckdosenleiste, die serielle am Konsolenserver hängt.
>
> *argl* Noch so eine Pfusch-Lösung, noch mehr proprietäre,
> überflüssige Hardware, noch mehr Kabel ... Weiche von mir,
> Satan ... :-)
>
> Um's nochmal zu wiederholen: Zu Remote-Management gehört
> _viel_ mehr als Konsolenzugriff und den Strom auszuknipsen.
>
Remote rebooten können, an die Systemkonsole kommen, den Strom schalten
können, loggen können wer wann wo was getan hat auf der Systemkonsole,
sind meiner Ansicht nach alles was zum Remote Management gehört.
Ja, es geht auch wirklich um Remote Management, also spricht ein
ordentlicher Konsolenserver auch SNMP, um dir zu sagen "hej, da is dein
netzwerkinterface $foo runtergefallen". Und wenn man SNMP nicht mag, dann
schickt ein ordentlicher Konsolenserver diese Meldung weiter an einen
remote syslog server, der mit den Daten was anfangen kann.
Es gehört noch mehr zum Remote-Management, aber dazu mehr in der nächsten
Mail ;-)

> > Die können das BIOS auf seriell umlenken :)
>
> Ja, das funktioniert aber nicht richtig, z.B. gehen nicht
> alle Funktionstasten. Probier's mal aus ... Vermutlich
> hat das niemand richtig getestet, weil die meisten einfach
> iLO benutzen. ;-)
>
Ich kenne große Installationen (groß == ca. 500 Server), die iLO aus den
von mir beschriebenen Bedenken ausgeschaltet haben, und Konsolenserver
auf der seriellen Benutzen, weil beim näheren Betrachten iLO keinen
Mehrwert sondern Mehraufwand mit sich bringt ...
Und ja, in dieser Installation, hatte ich ebenso das Problem, daß die
Funktionstasten im BIOS nicht wollten.
Es stellt sich heraus, daß das BIOS ANSI sprechen wollte, während der
Admin gerne xterm sprechen wollte.
Das geht natürlich nicht gut.
Ergo: Im BIOS die selbe Terminalemulation konfigurieren wie im Client selbst.

> Und Übrigens kann man per iLO _auch_ auf die seriellen
> Ports (RS232) zugreifen, wenn man das braucht. Ich wüßte
> jetzt aber keinen Grund dafür.
>
Ich schon ;)

> > Du gewinnst genausowenig einen Blumenstrauß mit einer Galerie an
> Lösungen
> > die nur bei einem Hersteller funktionieren.
>
> »ssh $server_mgt« funktioniert nur bei einem Hersteller?
>
Du postulierst, daß jeder Serviceprozessor von jedem Hersteller gleich
funktioniert.
Beispielsweise, hast du auf deinem iLO jeztt LDAP in Betrieb, und wer
weiß, du hast vielleicht noch eine Galerie SUNs und auf einmal
funktioniert dein Remote-Management Konzept mit LDAP nicht mehr.

> 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).
Man setzt sicherlich nicht auf ein Pferd, und bestimmt auch nicht auf 6
unterschiedliche. Das wollte ich auch nicht ausdrücken.

> Selbst wenn man bei einer späteren Aufrüstung aus irgend-
> einem Grund den Hersteller wechselt (was auch aus anderen
> Gründen eher eine schlechte Idee ist), dann kann man das
> Remote-Management normalerweise unter einen Hut kriegen.
>
Und da wiederspreche ich, da es durchaus leichter ist, wenn man sein
Remote Management vorher von den Herstellern der Server (und
Netzwerkkomponenten) getrennt hat.

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

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

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

Dieses Dokument sei dir für FreeBSD ans Herz gelegt:
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/pxe/

Und für Debian Linux gibt es FAI, auch ganz nett:
http://www.informatik.uni-koeln.de/fai/

Mit genug wissen in FAI, kann man via FAI natürlich auch ein FreeBSD
installieren.

> Und daß in den Racks keine unnötigen Kabel im Weg herum-
> hängen, und keine proprietäre Geräte drinstecken, die Geld
> kosten und um die man sich kümmern muß.
>
iLo ist propritär, kostet Geld, und du musst dich darum kümmern.

> > Ich komme auf Webbasierte Anwendungen von zu Hause nicht ran, da ich
> nur
> > via SSH auf diverse Randrechner komme und von dort mich weiterhangeln
> > kann.
>
> 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.
Die Aufgabe dazu hatten wir ja weiter oben.

> > An sich reicht mir das auch. Für's remote Management eines Servers,
> falls
> > sein Netzwerkinterface mal ein Problem hat, funktioniert nunmal am
> Besten
> > eine Umsetzung von RS232 auf Ethernet
>
> 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.
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 ;)
Und da so ein konsolenserver um längen Preiswerter ist als eine Reperatur
eines Servers, der seine iLO Schnittstelle verloren hat, ist da auch
schnell Abhilfe geschaffen ;-)

> > (und dann bitte ssh, nicht telnet).
>
> Bitte keine blinde SSH-Gläubigkeit. Immer wenn ich dieses
> gebetsmühlenartige »ssh ist sicher, telnet ist unsicher«
> höre, kriege ich Zuckungen. :-)
>
Nun, dann drehen wir den Spruch um, und du sagst mir, warum telnet genauso
sicher ist wie SSH ;-)
Beziehungsweise hoffe ich, daß du bei diversen OpenSSH T-Shirts nicht zu
viele Zuckungen bekommst ;-)
RIP
telnet
1972 - 1999
won't crypt

> > Aber nungut. Jedem sein Weltbild auf die Thematik "Remote Management".
> > Meins ist ziemlich RS232 festgefahren ;)
>
> Offensichtlich. :-)
>
> So ist das mit vielen alten Dingen, die die Leute lange
> Jahre kennen und an denen sie festhalten und alles Neue
> erstmal mit Skepsis betrachten. Ich nehme mich da nicht
> aus, sonst würde ich inzwischen vermutlich mutt statt elm
> benutzen.
>
Naja, solange wir Konstruktiv "streiten" ist alles okay.
Und ich habe nun mittlerweile gelernt, daß iLO doch etwas mehr kann, als
ich es in Erinnerung hatte :)

Beste Grüße,
der Marian

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Fri 22 Apr 2005 - 10:45:36 CEST