Re: Palm Tungsten T / externes IrDA

On Thu, Apr 21, 2005 at 05:10:24PM +0200, Oliver Fromme wrote:
> 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.

Warum auch nicht.

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

Aber wer braucht das schon.

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

Ich werden mit sicherheit kein Java im Browser aktivieren - abgesehen
davon gibt es auf alpha eh kein Java Support.

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

Meine Serielen kosten defintiv deutlich weniger als ein tauglicher
Switch der gleichen Portzahl.

> > Das ist doch Konfigurationsseitig Overkill.
>
> Ein Konsolenserver ist Overkill.

Kommt darauf an - letzlich brauchst du den sowieso, z.B. weil der
eh notwendige Switch und Router per seriele bedient wird - klar können
echte Switche Telnet und teilweise sogar ssh, aber letzlich ist es ja
gerade die Netzverbindung, die im Fehlerfall zu debuggen ist.
Ebenso bietet sich eine Seriele für Firmwareupdates auf eben diesen
Geräten an - soll ja shcon mal schief gehen und dann ist xmodem über
seriele die letzte Chance.

> > Geldlich im übrigen auch teurer.
>
> Ein Konsolenserver ist teurer.

Das stimmt nur für eine sehr geringe Maschinenzahl.

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

Ja - so ein Management-LAN muss eh getrennt sein.

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

Kommt daruaf an was das für eine Maschine ist.
Auf diversen alphas hast du auch die Management Controller per Serieler
angebunden.

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

Zudem beherscht FreeBSD schon seit ewigen Zeiten verschlüsseltes Telnet.

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

Naja - wenn du da ein Problem siehst, dann hast du letzlich auch
ein noch viel größeres Problem.

> > 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-
> gentlich -- außer Konsolenumleitung -- keine nennenswerten
> Manegement-Features bieten kann.

Das ist wohl wahr.
Die umgeleitete Seriele wird dir nicht mehr sagen, dass die System-CPU
wegen Lüfterausfall ausgeschaltet wurde.
Es muss zwar so oder so einer raus, aber der kann dann gleich das
richtige Ersatzteil dabei haben.

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

Deshalb verkabel ich Steckdosen mit RS485 - die kann man dann in
Reihe hängen.

> Um's nochmal zu wiederholen: Zu Remote-Management gehört
> _viel_ mehr als Konsolenzugriff und den Strom auszuknipsen.

Natürlich - ein ordentlicher Management-Prozessor ist besser und kann
mehr, aber nicht immer verfügbar.
Normalerweise reicht eine RS232-Console und das Stromschalten ist
eine nette Zugabe.

> > Okay, vollständig isses erst, wenn das BIOS seinen Output auf die serielle
> > umlenken lässt, aber das ist zum Beispiel bei den HP Maschinen mit iLO der
> > Fall.
> > 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. ;-)

Die Nutzung von F-Tasten ist da nur ein Teil ds Problems
Zudem arbeiten alle mir bekannten Serverboards mit Full-Screen,
was jenseits von VT100 spassig ist.
Kleine Boards, wie die Soekris sind mit CLI-BIOS deutlich besser,
aber halt kein Ersatz für einen großen Server.

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

Das ist nicht immer praktikabel.

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

Die Probleme, die ein Ausfall eines solchen Systems mit sich bringen
halten sich aber in sehr überschaubaren Grenzen.

> > Aber nungut. Jedem sein Weltbild auf die Thematik "Remote Management".
> > Meins ist ziemlich RS232 festgefahren ;)
>
> Offensichtlich. :-)

Mir ist das eigendlich ziemlich egal, solange es praktikabel ist
und den Zweck erfüllt - RS232 reicht mir meistens aus, aber für
die beste Lösung halte ich das auch nicht.
Was für mich nicht praktikabel ist sind halt in erster Linie Lösungen,
die ich nicht per Textmode nutzen kann - auf meinem Notebook starte
ich nur sehr selten ein X.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message