Journal Simple Windows Remote Administration

Posté par  (site Web personnel) .
Étiquettes : aucune
0
18
juin
2004
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(...))

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).
  • # serveur ssh windows

    Posté par  . Évalué à 2.

    pour installer un serveur SSH sur les postes windows tu peux peut être te servir de http://sshwindows.sourceforge.net/(...) je n'ai pas testé mais il semble que ca utilise openssh et cygwin, le tout "pré packagé".
  • # Compléter par...

    Posté par  . Évalué à 2.

    http://ocsinventory.sourceforge.net/(...)

    Logiciel que je suis en train de découvrir et qui me semble vraiment super. Il semble capable de pouvoir être combiné avec des utilitaires de controle à distance.
  • # Pourquoi faire simple quand on peut faire complique

    Posté par  . Évalué à 3.

    Juste une idee comme ca, t'as jamais entendu parler des group policies et de WMI ?

    Parce que ca fait a peu pres tout ce que tu demandes en mieux et plus facile, et c'est en standard, pas besoin d'une patchwork d'une machine Linux commandant une machine Windows qui commande un tas de machines avec du perl/cygwin/ssh/machin truc
    • [^] # Re: Pourquoi faire simple quand on peut faire complique

      Posté par  (site Web personnel) . Évalué à 1.

      Je ne sais pas trop à quoi correspond le WMI et les group policies. Néanmoins, pour des raisons de schéma directeur, je n'ai pas droit à Active Directory (ne me demandez pas pourquoi, ce n'est pas moi qui prends la décision mais je suppose qu'il y a une volonté, à terme, de faire une bascule samba intégrale et comme le support AD de Samba n'est pas encore complet...). Or, je suppose (peut-être à tord) que les group policies font partie de AD.

      De plus, j'ai besoin d'une solution qui soit opensource. J'ai déjà trouvé un équivalent opensource à Remote Installation Server (il s'agit d'unattended) qui fonctionne bien et je n'ai pas du chercher longtemps pour en comprendre le fonctionnement interne: ça permet de le customiser facilement et ainsi de mieux l'intégrer dans le fonctionnement de l a structure.

      Néanmoins, je vais me documenter sur le sujet de WMI et des stratégies de groupe...
      • [^] # Re: Pourquoi faire simple quand on peut faire complique

        Posté par  (site Web personnel) . Évalué à 1.

        Petite précision d'importance:

        je n'ai pas que des postes sous win2k à administrer: j'ai quelques postes (desktop) qui tournent sous Linux (et à priori, c'est plutôt parti dans le sens d'en augmenter la proportion). La plupart de mes serveurs sont sous Linux. J'ai besoin d'avoir du reporting et de l'historique sur les deux "mondes" si possible à partir d'une même interface (et , pour faire plus simple, d'une même DB)
  • # Sources

    Posté par  (site Web personnel) . Évalué à 3.

    Serais tu pret à publier tes scripts. Je trouve que ton expérience et ton travail mérite d'etre publié ailleur que dans un journal linuxfr qui sera oublié dans 2 semaines...
    Je trouve vraiment très intéressant cette expérience et ses résultats, il faudrai mettre tout ca sur une page et donner l'adresse, que j'ai peur de rater ton prochain journal !

    dans tout les cas merci pour ce journal !
    • [^] # Re: Sources

      Posté par  (site Web personnel) . Évalué à 1.

      Bon, bonne idée, faut juste que je trouve le temps de faire la page ! Et je n'ai pas franchement le temps en ce moment...
      Sinon, j'ai commencé à me renseigner sur les GPO. Bon, ça permet de faire pas mal de choses mais c'est surtout puissant avec Active Directory (donc forcément moins dans mon cas). De plus, je pense qu'il est bon d'avoir pour un même OS des solutions différentes que le truc fournit en standard (du genre un gestionnaire de paquetages pour windows) même si Microsoft a déjà pensé à pas mal de choses, il faut le reconnaître.
      Après tout, on a bien KDE ET GNOME, MySQL ET POSTGRESQL, etc...

      Sinon, pour le WMI, j'ai juste trouvé que ça permet d'extirper "facilement" des infos techniques sur la machine cible. Donc, j'en conclus que c'est un bon truc pour faire du monitoring avancé.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.