Pourquoi utiliser "sudo su"? Ça me semble moyennement pertinent, non? Juste un sudo devrait faire le taf?
Sinon, compte tenu des contraintes de l'OP, à savoir pas d'installation possible sur les machines distantes, je conseillerais l'usage d'un outil de déploiement sans agent (agentless).
J'ai déjà utilisé un peu Rex, mais pas Ansible qui est plus connu:
* Rex, nécessite perl et un serveur ssh sur la cible;
* ansible, nécessite python et un serveur ssh sur la cible;
J'ai opté pour Rex, parce que mes cibles sont sous Debian (perl obligatoire) et je voulais réduire au maximum le nombre de dépendances. Ansible étant plus connu, il est probablement plus simple de trouver de l'aide.
Pour l'usage que j'ai eu, j'ai trouvé Rex assez facile à utiliser cela dit (même si je n'ai pas eu vraiment le temps de l'apprivoiser complètement).
C'est plutôt pratique: on peut configurer des tâches, des cibles, et des groupes de cibles. À partir de là, il est possible d'invoquer facilement une ou plusieurs tâches spécifiques sur un nombre variables de groupes ou de cibles, y compris en parallèle.
Pour régler le problème des machines accessibles uniquement par une «machine proxy», il est possible d'utiliser les rebonds ou les «proxycommand» ssh, par exemple avec une configuration ssh dans ce goût là:
Host mon_proxy
User proxy_user
Hostname proxy.example.com
Host ma_cible_1
User cible_1_user
Hostname cible_1
ProxyCommand ssh -C mon_proxy /bin/nc -U %h
Juste un commentaire sur l'extrait plus haut: mes cibles à moi, elles sont derrière des liens GPRS, du coup pas d'accès direct.
Les cibles établissent donc un tunnel inversé, non pas vers un port de la machine distante, mais vers un fichier de socket UNIX dont le nom dépend de la cible: ça facilite l'allocation de l'identifiant, vu que ce fichier est généré en fonction de l'identifiant de la cible. Et puis, pas besoin de se souvenir si ma_cible_1 utilise le port 2222 ou 2223: il suffit de lister les fichiers.
Ça implique le netcat d'openBSD, mais s'il n'est pas disponible, on peut utiliser des trucs plus standard, c'est juste plus chiant. Pour le coup, j'ai l'avantage d'avoir les accès root sur tous mes systèmes :°
[^] # Re: des pistes
Posté par freem . En réponse au message Sudo su - user sur un serveur distant // Scripting. Évalué à 5.
Pourquoi utiliser "sudo su"? Ça me semble moyennement pertinent, non? Juste un sudo devrait faire le taf?
Sinon, compte tenu des contraintes de l'OP, à savoir pas d'installation possible sur les machines distantes, je conseillerais l'usage d'un outil de déploiement sans agent (agentless).
J'ai déjà utilisé un peu Rex, mais pas Ansible qui est plus connu:
* Rex, nécessite perl et un serveur ssh sur la cible;
* ansible, nécessite python et un serveur ssh sur la cible;
J'ai opté pour Rex, parce que mes cibles sont sous Debian (perl obligatoire) et je voulais réduire au maximum le nombre de dépendances. Ansible étant plus connu, il est probablement plus simple de trouver de l'aide.
Pour l'usage que j'ai eu, j'ai trouvé Rex assez facile à utiliser cela dit (même si je n'ai pas eu vraiment le temps de l'apprivoiser complètement).
C'est plutôt pratique: on peut configurer des tâches, des cibles, et des groupes de cibles. À partir de là, il est possible d'invoquer facilement une ou plusieurs tâches spécifiques sur un nombre variables de groupes ou de cibles, y compris en parallèle.
Pour régler le problème des machines accessibles uniquement par une «machine proxy», il est possible d'utiliser les rebonds ou les «proxycommand» ssh, par exemple avec une configuration ssh dans ce goût là:
Juste un commentaire sur l'extrait plus haut: mes cibles à moi, elles sont derrière des liens GPRS, du coup pas d'accès direct.
Les cibles établissent donc un tunnel inversé, non pas vers un port de la machine distante, mais vers un fichier de socket UNIX dont le nom dépend de la cible: ça facilite l'allocation de l'identifiant, vu que ce fichier est généré en fonction de l'identifiant de la cible. Et puis, pas besoin de se souvenir si ma_cible_1 utilise le port 2222 ou 2223: il suffit de lister les fichiers.
Ça implique le netcat d'openBSD, mais s'il n'est pas disponible, on peut utiliser des trucs plus standard, c'est juste plus chiant. Pour le coup, j'ai l'avantage d'avoir les accès root sur tous mes systèmes :°