HOAB

Problem :

I was creating a simple cron job to connect to from remote-server-1 to remote-server-2.

Testing the job with direct call or run-parts was OK

# direct call to my script
/home/admin/myscript.sh

# or with run-parts
run-parts -v –-test /etc/cron.hourly

But when called from cron I had a : Permission denied (publickey).

Solution :

First, trying to reproduce in cron environment with this command line (extract from there)

I finally reproduce the problem.

So I add -vvv options to my ssh connection to get more details : still not enough clue : permission is refused.

Then I decided to compare my ssh connection from bash command line :

remote-server-1@myuser > ssh -vvv remote-server-2

What a surprise :

- it uses my personal key to connect to remote-server-2 instead of remote-server-1 key !

- my personal key is deployed on remote-server-1 and remote-server-2

So when I run the connection, it works because it uses my personal key but when ran from cron environment it uses remote-server-1 key and this one was not declared on remote-server-2.

SSH is able to use your connection key in priority to try to connect to another server...

Le problème :

La machine virtuelle se connecte en VPN à une autre machine qui propose des services (mysql, apache)

Le but est d'avoir sous mon environnement de développement Linux, accès à cet environnement distant. Le VPN n'est compatible qu'avec Windows, donc lancement d'une machine virtuelle, connexion au VPN, connexion à la machine...

Et ensuite ?

Solution :

La machine virtuelle est en mode "Accès par pont", elle a donc sa propre adresse IP, (ex : 192.168.1.108) (cf cet article).

Via Putty (ou mRemoteNG), déclarer les tunnles suivants :

Source port : 3340

Destination : localhost:3306 (si la base mysql est directement sur la machine distante)

Mode : Local / IPV4

Cela permet depuis linux d'accéder à la base via : 192.168.1.108:3340

Explication : Putty établit un pont entre la machine distante et une port bindé sur l'adresse IPv4 de la machine virtuelle. Cette adresse étant accessible depuis l'environnement de développement.

Le problème :

Je n'ai pas toujours la possibilité de déposer ma clé publique sur les serveurs distants auxquels je me connecte.

Heureusement SSHpass est là, mais comme indiqué dans la documentation, il ne s'embête pas à essayer de cacher le mot de passe.

Je n'utilise pas les solutions comme PAC Manager car leur shell intégré est moins bien que le shell que j'utilise.

Solution :

SSHpass propose l'option "-e" qui permet de lire le mot de passe depuis une variable d'environnement.

Je créé un script de connexion dans mon répertoire ~/.ssh

export SSHPASS=<mypassword>
sshpass -e ssh <myuser>@<server>

Voici le résultat du ps :

5133  5132  0 11:43 pts/0    00:00:00 sshpass -e ssh <myuser1>@server1
8892  8891  0 15:31 pts/2    00:00:00 sshpass -e ssh <myuser2>@server2

Le problème :

Déployer à partir de Jenkins, une application fraichement buildée sur des serveurs distants (avec des scripts en tout genre, mise à jour bdd, fichiers, autres)

Solution :

Il est possible de tout faire dans Jenkins à l'aide des plugins (Publish over SSH et SSH Credentials), mais c'est fastidieux et lent de tester/maintenir ses scripts ainsi.

Je préfère, et de loin, avoir mes scripts disponibles sous un shell pour les tester efficacement et pourquoi pas, les réutiliser ailleurs. Dans ce cas, le plugin de base pour exécuter un script suffit.

Quelques problèmes se sont posés, d'où quelques bonnes pratiques à avoir :

1. utiliser des clés publiques / clés privées pour ne pas avoir à gérer les mots de passe dans Jenkins.
2. séparer les jobs de builds des jobs deploy et les organiser avec MultiJob
3. stocker les scripts sous votre SVN / Git (Jenkins permet de déployer une arborescence dans un sous-répertoire)
   • par exemple : url SVN des scripts => à extraire dans ./deploy
4. dans la partie build : déterminer automatiquement la version et stocker là dans un fichier. Cela permet de pointer sur le trunk plus facilement
5. dans la partie deploy :
   • retourner un code à Jenkins en fin de script pour indiquer si le build est OK ou KO
   • utiliser les variables d'environnements locales (Jenkins), distantes.

# tracer l’environnement local (script Jenkins) avec 
env > /path/to/env_jenkins.txt

# tracer l'environnement distant avec : 
ssh $SERVEUR_DIST << FIN
	env > ~/env_distant.txt
FIN

# passer les variables d'un environnement à l'autre (bash remplace les variable locales (Jenkins) au moment de transférer le script) :
ssh $SERVEUR_DIST << FIN
	echo $VARIABLE_JENKINS
	echo \$VARIABLE_DISTANT
FIN

• comme tout bon script :
  • tester les arguments
  • mettez des logs
  • mettez des messages d'erreurs clairs
  • tester les codes retours de vos commandes : ça ne coute rien !

if [ $? -ne 0 ] ; then exit 1; fi

Merci capt'ain Obvious dirons-nous, mais au moins c'est écrit.
En effet toute cette artillerie peut avoir à fonctionner toutes les nuits, ça merdera forcément, autant que la panne soit facile à identifier.