Je trouve la commande sshfs particulièrement simple, moi... plus rapide qu'apprendre à utiliser un nouveau logiciel, en tout cas.
Dans le cas de vi, ok, c'est relativement pertinent, parce que cet outil fait partie d'un standard. Ce n'est pas le cas de beaucoup d'éditeurs de texte, par contre.
Il y a toujours la possibilité de copier mais c'est long et tu multiplie les risques d'erreurs.
Le risque d'erreur bien moche me semble bien plus élevé quand on bosse en direct sur la prod, hein... si l'utilisateur n'est pas habitué aux terminaux, alors il est peu probable qu'il ait configuré ses outils pour avoir un distinguo visuel, et donc, la confusion de machine deviens nettement plus facile, surtout si les machines font partie d'un parc ou les noms sont cryptiques.
Dans le cas des gestionnaires de configuration basés sur un agent (cfengine3, notamment, les autres me souviens plus) c'est effectivement long et complexe a mettre en place, mais dans le cas de drist ou rexify (il y en a d'autres, plus connu, mais... voir parenthèse précédente) par contre, ça n'implique pas d'installer quoique ce soit sur le système distant (enfin, si, ssh, ainsi que rsync pour drist apparemment, ou perl pour rexify) ça n'est pas vrai, et le fait d'utiliser des scripts automatiques permets de pouvoir reproduire la procédure sans risque d'erreur, justement. Donc, 1) on tests sur un serveur de test 2) une fois validé que ça marche comme on veut, on lance le même sur un serveur de prod. C'est nettement moins casse-gueule, à mon avis, que modifier une configuration manuellement sur le serveur de test, puis de prod. Je ne parle même pas du cas ou on "oublie" de tester, hein... (mais je tape pas, j'ai fait. Problème de mauvaise éducation, j'ai longtemps ignoré l'existence de rex&drist après tout)
[^] # Re: Sans vouloir faire mon vieux con...
Posté par freem . En réponse au lien dte : un autre éditeur de texte normal. Évalué à 2.
Je trouve la commande sshfs particulièrement simple, moi... plus rapide qu'apprendre à utiliser un nouveau logiciel, en tout cas.
Dans le cas de vi, ok, c'est relativement pertinent, parce que cet outil fait partie d'un standard. Ce n'est pas le cas de beaucoup d'éditeurs de texte, par contre.
Le risque d'erreur bien moche me semble bien plus élevé quand on bosse en direct sur la prod, hein... si l'utilisateur n'est pas habitué aux terminaux, alors il est peu probable qu'il ait configuré ses outils pour avoir un distinguo visuel, et donc, la confusion de machine deviens nettement plus facile, surtout si les machines font partie d'un parc ou les noms sont cryptiques.
Dans le cas des gestionnaires de configuration basés sur un agent (cfengine3, notamment, les autres me souviens plus) c'est effectivement long et complexe a mettre en place, mais dans le cas de drist ou rexify (il y en a d'autres, plus connu, mais... voir parenthèse précédente) par contre, ça n'implique pas d'installer quoique ce soit sur le système distant (enfin, si, ssh, ainsi que rsync pour drist apparemment, ou perl pour rexify) ça n'est pas vrai, et le fait d'utiliser des scripts automatiques permets de pouvoir reproduire la procédure sans risque d'erreur, justement. Donc, 1) on tests sur un serveur de test 2) une fois validé que ça marche comme on veut, on lance le même sur un serveur de prod. C'est nettement moins casse-gueule, à mon avis, que modifier une configuration manuellement sur le serveur de test, puis de prod. Je ne parle même pas du cas ou on "oublie" de tester, hein... (mais je tape pas, j'ai fait. Problème de mauvaise éducation, j'ai longtemps ignoré l'existence de rex&drist après tout)