URL: https://linuxfr.org/users/medspx/journaux/simple-windows-remote-administration Title: Simple Windows Remote Administration Authors: Médéric RIBREUX Date: 2004年06月18日T17:49:56+02:00 Tags: Score: 0 Cher journal, je t'apporte quelques précisions sur mon idée d'administrer mon parc sous win2k par une solution open-source centralisée (cf [http://linuxfr.org/~medspx/11335.html(...)](http://linuxfr.org/~medspx/11335.html)) J'ai fait quelques expérimentations qui sont assez encourageantes. Après quelques recherches sur le net sur le sujet, j'ai trouvé deux solutions potables. Celle que j'ai testée en premier repose sur le principe suivant: - j'ai un serveur Linux avec pleins de services, une base de données, de quoi faire des logs. J'y stocke les informations des postes de travail, les commandes à effectuer à distance, des scripts PERL pour lancer les travaux sur les différents postes. - j'ai une station win2k dédiée à l'administration: j'y installe cygwin+ssh (histoire d'avoir un accès distant à peu près sécurisé et surtout un client ssh opensource !). Je peux donc la "commander" à distance via SSH à partir du serveur Linux d'administration. Sur cette station, j'ajoute des outils d'admin windows freeware: les PsTools. -Le principe retenu est que, lorsque je veux exécuter une série d'actions sur un ou plusieurs postes win2k du parc, j'utilise mon serveur Linux (avec un ou plusieurs scripts PERL) qui va commander la station win2k d'admin pour lancer différentes commandes d'administration du monde windows. Parmi ces commandes d'administration, j'utilise en priorité psexec des pstools qui me permet de lancer à distance sur n'importe quel poste du parc des actions. - L'intérêt de cette solution est la facilité de déploiement: le gros du travail est situé au niveau de la configuration du serveur Linux et de la station win2k d'admin. Les postes clients n'ont pas à être visités. De plus, les opérations peuvent être programmées via fcron sur le serveur: bien pratique pour les MAJ lourdes à faire la nuit... Les résultats sont assez satisfaisants: toutes les installations d'applications se font à distance sans problème majeur. J'ai utilisé cette technique pour les opérations suivantes: - Migration de Mozilla 1.4 vers 1.6 (désinstallation de l'ancienne version, installation de la nouvelle version, reconfiguration dynamique du profil par script perl). - Installation à distance d'imprimantes réseau (avec suppression des anciens pilotes). - Arrêt à distance des PC à partir d'une heure précise (histoire de faire baisser la facture EDF). - Installation à la demande de TightVNC (au cas d'assistance accompagnée) - Configuration NTP pour synchronisation des horloges. Je n'ai pas encore estimé le temps gagné mais je peux dire que ça m'évite pas mal de tâches basiques et un peu lourdes. Néanmoins, j'arrive aux limites du système: celle de cygwin et de psexec. Déjà , les pstools ne sont pas opensource. De plus, j'ai besoin de mobiliser une station win2k dédiée à l'admin. Ensuite, le fonctionnement de psexec ressemble fortement à un telnet installé à la demande (ou un vers) et est largement tributaire de la sécurité windows (donc pas terrible à priori). Et, surtout, j'ai un script qui plante de manière aléatoire: celui de la config NTP. Le problème vient de cygwin qui a du mal à faire fonctionner psexec.exe (qui essaie d'écrire sur un canal non existant). Résultat: ça passe 1 fois sur 5. Pas très pertinent comme système. D'autant plus que j'ai des scripts à balancer qui y ressemblent (commande windows à distance, arrêt/relance de services). Autre point noir: les commandes s'effectuent les unes à la suite des autres: on lance le script sur le PC 1 puis, une fois que celui-ci est terminé, on lance le script sur le PC 2, etc... Pour un parc de plus de 100 machines , avec (on imagine) un script qui met près de 15 minutes par poste, ça fait plus de 24H donc, pas très bon pour une MAJ d'un bloc. J'entrevois une demi-solution au problème cygwin+psexec: recoder psexec en "natif" linux ! En fait, psexec.exe ne fait rien d'autre que de balancer un exécutable psexecsvc.exe sur l'hôte à administrer (via SMB), puis d'installer un service basé sur ce binaire, puis de créer des canaux de communication chargés de recevoir les commandes et de renvoyer les messages d'erreur. On peut donc très bien envisager un script qui utilise SAMBA (TNG) pour faire ces opérations (même si j'ai un doute quand aux capacités d'installation de service) et voir si le résultat est meilleur. Cela permettrait également de se passer de la station win2K. Néanmoins, si on va au bout de cette idée, plutôt que d'utiliser un binaire non opensource (le psexecsvc.exe), qui communique en clair sur le réseau, on pourrait utiliser le couple cygwin+ssh sur tous les postes à administrer. SSH faisant la même chose, en mieux que psexec et cygwin apporterait de meilleures capacités de scripting aux postes clients. C'est la deuxième solution que j'entrevois. Néanmoins, elle reste, pour l'instant assez chiante à mettre en oeuvre: faut installer et configurer cygwin sur tous les postes... Je me suis penché sur un mode de déploiement automatisé qui, je pense, devrait être envisageable mais, rien n'est sûr. De plus, je ne connais pas bien le comportement de cygwin en pleine charge sur des configurations assez petiotes. Mais, je pense que cette solution est meilleure: - complètement open-source. - une seule unité d'administration centralisée. - scripts plus élaborés (donc plus puissants). - communication cryptées. - administration en "multicast" Sur ce, cher journal, je te promets de te tenir au courant dès que j'ai des résultats positifs. S'il y a des spécialistes cygwin dans la salle, je prends tout ce qu'il ont sur le sujet...(même si j'ai déjà un peu RTFM).

AltStyle によって変換されたページ (->オリジナル) /