PLuG a écrit 1010 commentaires

>Et comment fait-on pour ça ? (t'as une recette ?)

ben c'est supporté en standard par x11vnc. il faut configurer xinetd pour qu'il ecoute sur le port 5900 et passe la connexion a x11vnc avec des options pour lui dire d'utiliser le login/passwd unix, de changer de uid pour l'utilisateur qui vient de s'authentifier, et de lancer une session X si aucune n'existe.
C'est (mal) documenté sut le site de x11vnc ( http://www.karlrunge.com/x11vnc/ ), si tu as besoin d'exemples, j'en récupererai au boulot :-)

sauf si cela a changé, vncserver oblige a convenir d'un port TCP différent pour chaque utilisateur, et de définir un "mot de passe vnc" stocké dans un fichier ... beurk

x11vnc peut utiliser Xvnc pour créer des sessions X qui ne sont pas la session Xorg ( :0 ) du serveur, et l'utilisateur peut utiliser soit sa clef ssh, soit son mot de passe unix pour s'authentifier. De plus tous les displays crées peuvent être joignables sur le port vnc par défaut (5900) et donc plus besoin de convenir a l'avance d'un port particulier pour une personne. C'est quand même plus pratique !

non x11vnc ne ferme pas forcement la session.

x11vnc peut servir a donner acces a la session X11 existante (celle du serveur) à distance en vnc, mais il sait aussi servir des sessions. Les options de la ligne de commande sont touffues, mais on peut faire pas mal de choses.

Par exemple:
- ecoute sur le port tcp/5900 via xinetd (vnc standard) et demande de user+password graphiquement (en protocole vnc), puis changement d'uid pour lancer la session X11 qui sera accessible en vnc. Dans ce mode, on peut lui demander de ne pas tuer la session a la deconnection et de la récupérer quand le meme user revient. Tout ce qu'il faut sur le client c'est un client VNC.
- ou alors, l'utilisateur se connecte grace a sa clef ssh et le protocole VNC est tunnelé dans SSH. Dans ce mode, plus besoin de user+password et la aussi la session peut rester et etre recupérée. Pour utiliser ce mode, j'ai un peu instrumenté le .profile pour que la socket de liaison avec l'agent SSH ne change pas de nom a chaque session et du coup quand je me reconnecte, tous mes xterms et autres programmes déjà lancés récupèrent également la connection vers mon agent ssh (ma clef privée reste sur mon portable, pas question de la copier sur le serveur).

bref, on peut faire pas mal de choses. J'ai même utilisé le mode authentification ldap, et j'ai du envoyer un patch car il y a un bug quand on veut utiliser le mode xinetd et ldap.

je suis partiellement d'accord avec toi. les outils "acronymes" ne sont pas forcément plus compliqués et ne bouffent pas 500Mo de ram. De plus ils viennent avec une api qui fait bien plus qu'une simple copie de fichiers.
Avec la méthode "fichiers" il va falloir définir le format des fichiers (xml ? ascii ? ...) et puis décider quand on peut l'effacer (quand considère t'on qu'il a bien été traité en face ?), et puis mettre en place un compte applicatif avec une clef ssh sans passphrase (scp), mais alors on voudra le bloquer dans un sous répertoire pour sécuriser la machine (chroot ?) ou alors ne pas utiliser scp mais plutôt une commande associée a la clef ...
Et puis cela va marcher ... jusqu'au jour ou le contenu du fichier ne sera pas prévu par le parser écrit a-la-rache, et que l'import du fichier va foirer. mais comme c'est mal écrit le script ne sait pas remonter l'erreur, ni sauter le fichier qui pose problème, du coup il se bloque.
Alors on va décider d'ajouter du monitoring, de créer les sondes cacti qui vont avec, et on va de nouveau engager 15 jours/homme sur ce problème pour "ne pas utiliser d'acronymes".

Si le besoin est ultra simple (et cela semble le cas), scp peut-être la bonne méthode, mais moi j'en ai marre des usines a gaz commandées par des crontab qui se lancent toutes les minutes, et qui s'enchainent de serveur en serveur pour faire passer les informations. C'est rapide a mettre en place mais c'est rapidement la foire totale sur les machines.

ah! bigre !!
mon premier post n'apparaissait pas j'ai cru que Firefox l'avait avalé tout cru !
désolé !

tu veux un MOM ( Message Oriented Middleware).
c'est un logiciel qui gère l'envoi des informations entre deux autres logiciels avec une queue pour les garder en spool si la transmission immédiate n'est pas possible.

chez les editeurs IBM MQSeries, Tibco, ...
en plus libre: OpenJMS, ActiveMQ, ...

tu trouvera bien l'implémentation qui te plait le mieux sur le web

tu veux un middleware orienté message (MOM).
un MOM gère une queue de messages dans laquelle les informations sont stockées si la livraison immédiate n'est pas possible.

Il y a des produits commerciaux très connus (IBM MQSeries, tibco, ...).
tu peux te tourner vers JMS en java, ou activeMQ, ou ... tu trouvera bien l'implémentation qui te plait le mieux.

pour le web y'a des outils sympa qui génèrent des moyt de passe en fonction d'un password unique et du nom de domaine par exemple.
c'est implémenté en modules firefox, comme "password hasher" https://addons.mozilla.org/en-US/firefox/addon/3282

ça permet de ne retenir qu'un seul mot de passe pour les sites web.

Si tu as peur de charger le serveur avec tcpdump, tu peux sniffer a coté du client ... ce sera moins verbose et de toutes manières pas fait par le serveur.

Sinon avec un tcpdump -n -i interface port 67 or port 68 -s0 -w /tmp/matrace.dump tu vas enregistrer les paquets qui t'intéressent, et tu pourra ouvrir ce fichier avec wireshark (sous linux ou windows).

ben moi je passe plus de temps au boulot que sur mon pc perso ... donc 25%
cela dit, au boulot, on utilise des postes windows pour gérer des serveurs linux ... ça se compte comment ça ?

juste pour participer, avec mysql la réplication multi-maitre peut fonctionner, si ton application prend quelques mesures pour ne pas avoir de problèmes.
Une astuce est aussi de configurer chaque serveur pour qu'il génère des clef primaires qui n'entrent pas en conflit (par exemple un serveur génère des clefs "paires" et l'autre des clefs "impaires"). cela se fait dans mysql.ini

server-id = 1
auto-increment-increment = 2
auto-increment-offset = 1

server-id = 1
auto-increment-increment = 2
auto-increment-offset = 2

en fait le GROS problème de la réplication multi-maitre asynchrone est qu'en cas de crash il est extremement compliqué de garantir la restauration exhaustive de toutes les transactions en cours. la réplication asynchrone n'aide pas, et le multi maitre complique encore les choses. Quel backup garder ? comment etre sur d'avoir tous les journaux necessaires ? comment les rejouer après une restauration de serveur ?? bref c'est bien pour certaines applis mais compliqué a opérer correctement.

un autre soucis est aussi que Windows est capable d'etre infecté par tellement de saloperies différentes que clamav est loin de toutes les détecter ... J'en ai encore fait l'expérience récemment avec une clef USB sur laquelle un virus était présent, détecté par des antivirus sous windows, pas par clamav sous linux...

tout a fait, le nombre d'utilisateurs n'est pas limité arbitrairement dans les logiciels libres (pas de licence 253 users et pas un de plus), donc la limite va dépendre .... de ton utilisation, et tu ne trouvera pas l'information qui TE concerne sur les sites web.
La limite va dépendre de la puissance de ton hardware, du nombre de serveurs, mais surtout de l'architecture logicielle utilisée et de la qualité des algorithmes utilisés.
La plupart du temps un problème de performance peut être résolu avec des améliorations algorithmiques ou architecturales qui permettent de passer avec le même hardware ... (mais c'est plus cher que de changer le hardware ou d'ajouter des serveurs alors souvent on ajoute du hardware :-)).

Bref Eric ci dessus a raison, utilise l'outil qui est déjà le plus utilisé par les entreprises et pour lequel tu aura le plus de doc et le meilleur support de la communauté (et de SSII pourquoi pas).

contrairement a RAID qui améliore la disponibilité du stockage sur disque mais ne prémuni pas des erreurs humaines, "time machine" permet de se protéger de certaines erreurs humaines (mais pas de toutes), mais ne fait rien pour protéger d'une panne disque.
Les deux ne sont pas de vraies sauvegardes externalisables et protégeant contre le vol de matériel ou les catastrophes (incendie, inondation, ...)

et surtout RAID n'est pas un mécanisme de sauvegarde, c'est un procédé qui permet d'améliorer la fiabilité du stockage disque. Si tu balance un "rm -rf * " dans ton home directory, RAID va gentiment le faire sur les n copies mirrorées puisque c'est son rôle.
Avec une sauvegarde, tu as une copie que tu espère pas trop ancienne des données, sur un média différent, que tu peux stocker dans un lieu volontairement distant pour te prémunir
aussi des dégats matériels (incendie, inondation, foudre, ...) ou même des vols de matériel
(si pendant tes congés tu te fais piquer ton PC avec tes 2 disques en RAID ... ben t'as tout perdu).

si si c'est pertinent, mais c'est une autre approche.

Ce que tu cherche a éviter s'appele "split brain" en technologie cluster (les 2 sont actifs) et cela arrive parce que le protocole/la méthode pour que les 2 nodes du clusters négocie leur état ne fonctionne plus, du coup comme ils ne se "voient" plus l'un/l'autre ils deviennent master tous les deux.
En réseau en général on s'en fou un peu. Par exemple si un switch dégage, que le routeur connecté dessus devienne master n'est pas grâve puisque les machines ne pourront pas le joindre (a cause de la panne du switch).
Par contre en technologie de cluster c'est gravissime, l'application devient active des deux cotés et les données peuvent être complètement détruites (montage d'un même filesystème en ecriture par les deux nodes simultanément, ...). Du coup pour les clusters, la méthode est de rendre ce "protocole" de communication entre les deux clusters vraiment fiable, impossible de le faire tomber en panne.

Heartbeat implémente ça, en multipliant les liaisons (reseau, séries, ...) entre tes deux machines. Dans ton cas avec des parefeux, tu pourrais utiliser plusieurs cartes réseau connectées sur plusieurs switchs eux même reliés entre eux avec plusieurs trunks ... et ajouter une liaison série "au cas ou". La cela devient autement improbable de passer en "split brain".

et si tu le configure dans dhcp-options? (man dhcp-options )

Intégrer un logiciel existant ... ça demande pas mal de travail, surtout si c'est fait dans les règles de l'art de l'entreprise cliente, et selon ses procédures ...
Ca coute beaucoup plus qu'un téléphone !! et cela même si y'a presque rien à développer.

Du coup je trouve cette annonce pas sérieuse, ça doit être un fake ... mince je me suis fait prendre.

Dans la pratique ce n'est pas l'inverse, il n'y a pas de support SAN ESS IBM dans les distributions centos. D'ailleurs c'est compliqué car si on prend le driver fourni par redhat on a le support de redhat (mais pas de IBM qui demande de mettre le sien) et si on met le driver de IBM on a des difficultées avec le support de redhat ....

Si on ajoute que IBM ne livre de toutes façons pas de RPMs dudit driver et que si on suit le manuel d'installation il faudrait avoir gcc sur le serveur pour compiler le driver en local ... c'est très crado.

Donc nous on utilise centos, on package en RPM les drivers d'IBM (ou on utilise celui de la distribution), bref on fait notre sauce ... et on a de toutes façons pas de support (ni IBM ni RedHat).
Ca c'est très faisable sur une débian ou une gentoo si t'en as envie. Pour nous l'interêt de centos c'est qu'on a l'habitude de packager en RPM, qu'on a des dépots yum, et qu'on a "l'habitude" des distributions redhat. Mais dans la pratique on aurait pu migrer tout ça en debian ... c'est juste plus cher que de passer à centos (puisque identique a redhat).

J'ai beaucoup de serveurs pro en centos 4 et 5 sans aucun soucis particuliers... sauf la gestion des mises à jour.

Je m'explique: redhat fourni les rpm de mise à jour avec des descriptions qui indiquent la catégorie (nouvelles fonctionnalités, bug fix, security fix), mais Centos ne le fait pas ce qui complique la gestion du "patch management". De même quand le projet centos travaille sur une nouvelle release (5.x) le traitement des bug fix ou security fix est retardé (surement par manque de ressources) ce qui n'est pas "top" mais pas bloquant pour moi.

Hormis ce delta, le support fourni par RedHat s'est illustré a maintes reprises par son incompétence. Comme il ne sertait a rien nous avons transformé la totalité de nos redhat en centos (migration hyper simple).

C'est le risque du business modèle ou l'on ne vent plus la licence mais juste le support. En vendant la licence, on extorque de l'argent au client sans qu'il ait d'autre choix. En ne vendant que le service ... ben faut que le service soit de qualité sinon le client ne le prend plus.

de plus c'est simple, et documenté ... (man 5 crontab).

Je n'ai essayé que "tomtom one". Il est vu comme un drive usb-storage, ce qui permet de mettre a jour les POI depuis Linux, mais pas de faire toutes la maintenance du tomtom. Pour cela il faut utiliser le logiciel adequat qui ne fonctionne pas sous wine ... dommage vu que a priori tomtom utilise linux de son coté ....

Je ne connais pas les autres GPS et je n'ai pas joué a récupérer les coordonnées gps.

si tu veux de l'hdmi et du bluray pourquoi pas prendre une playstation 3 de sony?
tu peux la booter sous linux si tu veux, mais en standard elle lit les bluray, le h264, le navigateur supporte meme le flash kipu (youtube ...) et sa télécommande permet elle aussi de la mettre en marche et de l'arrêter :-)

Moi j'aime bien l'argument du parefeu a 50000 règles avec la préoccupation de le rendre auditable ... A mon sens quand on arrive a ce nombre de règles, c'est que l'architecture du réseau n'est pas bien pensée, il faut plutôt refondre le réseau pour le segmenter en fonctions logiques auditables plutot que de multiplier les règles pour gérer des exceptions.

Enfin, il est certainement temps de moderniser netfilter, même si chez moi il remplace très avantageusement un pix ou un firewall-1. Notement grâce a son système de jump qui permet d'optimiser le parcours des règles en construisant un arbre de décision...

il faut reprendre les contrats un par un, souvent le droit d'usage n'est pas lié a la maintenance annuelle, et le prix de cette dernière suffit a justifier un projet de remplacement, voire a le financer en un an ou deux ans.
Si un remplacement de hardware est prévu, il est possible de faire de grosses économies en passant d'un truc proprio (Solaris, AIX, ...) vers un linux sur un serveur intel vraiment moins cher, dont la maintenance sera elle aussi moins chère (d'ailleur on se demande si les serveurs intel ne sont pas juste jetables et que la garantie suffit)....
le problème c'est que la DSI possède les chiffres pour faire l'analyse et que le technicien qui connait l'intéret de la migration ne les a pas... et puis il faut quand même faire l'analyse, quelques fois il ne faut pas migrer !!