Le mercredi 16 janvier 2008 08:47, Jean-Marc Beaune a écrit : | Salut, Salut, | | Si tu veux pouvoir accéder à la source vidéo de toutes les machines des le | commencement du POST, je ne pense pas qu'il y ait de solution software pour | ça étant donné qu'aucun OS n'est encore chargé à ce stade. Dans ce cas je ne | vois que l'utilisation d'un KVM, mais avec 2 écrans, là je ne vois pas | comment faire...
Oui, c'est ce que j'imagine aussi et que je cherche à approfondir. Peut-être le KVM uniquement pour les POST car de toutes façons je ne peux me concentrer que sur un seul POST/bios à la fois et l'Ethernet pour le second écran des applis tel que tu me l'as expliqué. Là où j'en suis : Je me demande comment font ceux qui administrent des machines à distance quand ils veulent changer un paramètre dans le bios de leur machines ou un simple fichier de config sous ssh sur la même machine. Dans un data-center ou avec des parcs importants par exemple je ne sais pas comment c'est organisé mais j'ai vu des photos. Il n'y a pas pas un écran sur chaque carte mère dans chacune des baies. Je vois mal aussi un admin de service en train de cavaler à droite et à gauche dans tous les bâtiments. Donc j'imagine que quelque part, un admin peut voir les POST à distance sur son écran par des KVM et aussi - à une autre distance - sur la même carte mère, des utilisateurs/clients hébergés pour les applis qui ne sont pas toujours des web services. C'est vrai que dans ce cas cela fait deux claviers et moi je m'entête à n'en vouloir qu'un et une seule souris. Est-ce là le noeud du problème? Dois-je accepter deux claviers puisque qu'un écran n'est pas adressable? Comment se comportera la douchette sur le câble en Y de mon premier clavier? Je ne veux pas non plus perdre la possibilité de l'utiliser sur des machines hétérogènes grâce au KVM actuel. Je dois explorer ça aussi. Hors sujet : L'usage des deux écrans c'est pour le confort d'utilisation pour certaines applis sur certaines machines. Pour gérer les serveurs, un seul écran me suffit mais un jour ces serveurs peuvent être recyclés en poste de travail et donc susceptibles de proposer le second écran de confort avec un minimum d'intervention. Je pense aussi aux machines en dual boot. Il s'agit d'un petit parc d'une dizaine de machines et la pièce où je travaille qui est trop petite ne peut pas les accueillir en terme de place et de dégagement de chaleur ni nos oreilles subir leur niveau sonore d'où la distance des 20m. Bref, revers de la médaille, j'en ai marre de perdre du temps à monter descendre un étage pour : brancher un écran là où il faut car mon premier KVM 4 ports s'arrête à 10m, le déménager ensuite car nécessaire à l'étage au-dessus... donc j'ai acheté deux écrans de plus... entrer dans un bios qui ne garde pas ses paramètres... ou c'est moi qui me suis trompé... sans compter les installations des nouvelles distributions avec un lecteur de CD-DVD à 20m... le scanner avec son câble parallèle d'un mètre... et j'en passe... Seule satisfaction, l'imprimante réseau. Dommage que les machines sous Linux ne la trouvent pas sur leur LAN :-( Pour allumer-éteindre une machine à distance j'ai compris le principe. Les bios peuvent éteindre à la réception d'une commande ACPI ou APIC ou quelque chose comme ça que je ne n'ai plus en tête actuellement mais selon les noyaux ça marche bien en général. Pour allumer les machines à distance les bios peuvent les "réveiller" avec le protocole SNMP sur leur réseau Ethernet ou sur leur port RS232. Il suffit d'avoir la main à distance sur une seule machine déjà éveillée. J'ai souvenir d'un article où il était question d'une machine qui s'allumait automatiquement une fois par semaine, prenait des backups sur son LAN et s'éteignait à la fin du job. Voilà, dans toute cette gestion à distance j'ai encore quelques trous noirs dont les deux écrans. J'interroge aussi notre ami commun sur le mot GTC. Je te remercie de t'être intéressé à mes interrogations. -- Cordialement Alain Vaugham ---------------------------------------------------------------- [PUB] Signature numérique GPG de ce courrier: 0xD26D18BC
pgpkuH8JJzIow.pgp
Description: PGP signature
_________________________________ Linux mailing list [email protected] http://lists.parinux.org/mailman/listinfo/linux
