Travailler à distance

• https://ensiwiki.ensimag.fr/index.php?title=Travailler_%C3%A0_distance

Accès depuis l'extérieur, VPN

Les machines (PC et serveurs) de l'UFR IM2AG et de Polytech sont presque toutes sur un réseau privé. Pour y accéder depuis l'extérieur, la première étape est d'utiliser le VPN.

Il y a quelques exceptions :

• Le site web site public, l'intranet et le webmail sont accessible via un navigateur sans VPN. Les deux derniers vous demanderont bien sûr un mot de passe.

• La machine mandelbrot.e.ujf-grenoble.fr est accessible via SSH (cf. ci-dessous) sans VPN. On peut s'en servir comme d'un rebond SSH vers d'autres machines (cf. section SSH ci-dessous).

Webmail

Lorsque vous êtes à distance, vous pouvez quand même lire vos emails en utilisant un simple navigateur. Le serveur webmail se trouve à https://zimbra.univ-grenoble-alpes.fr/.

Outils pour l'accès distant aux machines

Par SSH : scp, rsync, sftp, sshfs, lftp

Le moyen le plus simple d'accéder aux machines à distance est bien sûr par SSH. Pour une utilisation avancée, voyez également la page Clés SSH.

SSH ne se limite pas à un terminal distant cependant ; il peut servir de transport chiffré, donc sécurisé, pour d'autres programmes : scp, rsync, sftp et sshfs, entre autres.

• vous devriez avoir appris à vous servir de scp et de sftp durant le Stage Unix de rentrée. En résumé, pour transférer des fichiers d'une machine vers ou depuis un serveur (disons mandelbrot.e.ujf-grenoble.fr), on peut faire sftp mandelbrot.e.ujf-grenoble.fr ou sftp utilisateur@mandelbrot.e.ujf-grenoble.fr, puis utiliser les commandes sftp get et put pour télécharger et téléverser (i.e. envoyer) des fichiers. Par exemple :

pc$ sftp mandelbrot.e.ujf-grenoble.fr 
Connected to mandelbrot.e.ujf-grenoble.fr.
sftp> ls
Desktop            Mail               coucou.txt
sftp> get coucou.txt
Fetching /home/user/coucou.txt to coucou.txt
/home/user/coucou.txt
sftp> exit
ensipc01$ cat coucou.txt
coucou

• Si le principe de sftp vous plait mais que vous trouvez l'outil trop rudimentaire, regardez du côté de lftp qui permet beaucoup plus de choses (en particulier le transfert d'un répertoire complet avec la commande mirror).
• rsync est une version largement améliorée de scp (le principal avantage : si on recopie un répertoire qui a déjà été recopié plus tôt, rsync ne recopie que ce qui a changé). Par exemple, pour récupérer tout le contenu de votre compte dans le répertoire ~/polytech/ de votre machine personnelle, faites (depuis votre machine perso) :

  rsync -av votre-login@mandelbrot.e.ujf-grenoble.fr : ~/polytech/

  Plus de détails sur cette page ou bien sûr dans man rsync.

• Sous Linux, après avoir éventuellement installé sshfs, il suffit de faire (sur votre machine personnelle) :

  sshfs mandelbrot.e.ujf-grenoble.fr : ~/polytech/

  pour monter votre répertoire HOME dans le répertoire ~/polytech/ chez vous (i.e. les modifications que vous ferez dans ~/polytech sont transférées sur mandelbrot.e.ujf-grenoble.fr au fur et à mesure que vous les faites). Cf. sshfs dans la documentation d'Ubuntu par exemple.

Rebond SSH pour éviter d'avoir besoin du VPN

La plupart des machines de l'UGA ne sont pas directement accessibles depuis l'extérieur. Une solution pour y accéder est d'utiliser le VPN. Si on ne souhaite pas utiliser le VPN, on peut tout de même se connecter via SSH aux machines comme mandelbrot.e.ujf-grenoble.fr . Plusieurs solutions :

• Encapsuler deux connections à la main :

[moi@mamachine ~]$ ssh im2ag-mandelbrot.e.ujf-grenoble.fr
[nomp@im2ag-mandelbrot ~]$ ssh im2ag-oracle.e.ujf-grenoble.fr
[nomp@im2ag-oracle ~]$ 

• La même chose, en une ligne :

[moi@mamachine ~]$ ssh nomp@im2ag-mandelbrot.e.ujf-grenoble.fr -t ssh im2ag-oracle
[nomp@im2ag-oracle ~]$ 

• Ajouter (une bonne fois pour toutes) les deux sections suivantes au fichier ~/.ssh/config (à créer s'il n'existe pas) de la machine qui lance le SSH (i.e. le client) :

Host imag
  HostName mandelbrot.e.ujf-grenoble.fr
  User /votrelogin-nomp/

On peut ensuite utiliser ssh normalement vers imag

[moi@mamachine ~]$ ssh imag
im2ag-mandelbrot:~
[XX:XX:XX]/votrelogin/$

Continuer l’exécution d'un processus entre plusieurs connections : screen

La commande screen permet d'avoir une session de travail en terminal qui "survit" à une déconnexion au serveur. C'est pratique quand vous voulez lancer un processus long (compilation, jeux de tests...) sur un serveur, puis vous déconnecter du serveur sans que cela tue le processus pour autant, et enfin vous reconnecter et retrouver votre processus.

La commande screen vous ouvre un nouveau terminal, dans lequel vous pouvez démarrer les processus que vous désirer. Vous pouvez ensuite vous détacher de screen avec C-a d (i.e., appuyer sur Control-a puis sur d). Vous pouvez alors quitter votre session sur le serveur. Quand vous vous reconnecter au serveur, vous pouvez vous réattacher avec la commande screen -r.

pcserveur:~$ screen
pcserveur:~$ cd tp
pcserveur:~/tp$ processus_long &
# ^a d (appuyer sur Control-a, puis d pour se detacher)
pcserveur:~$

# ... je ferme ma session pcserveur, je rentre chez moi ...

pc-perso$ ssh pcserveur
pcserveur:~$ screen -r
pcserveur:~/tp$
# de retour dans screen, processus_long n'a pas été tué entre temps !

Travail sur machine personnelle, tests sur serveur avec rsync

L'option de ceux qui aiment leur petit confort à eux, sur leur machine, avec leur config, bref. Une solution adaptée à ceux qui travaillent majoritairement sur leur machine et ne font que tester sur les machines distantes est d'utiliser rsync pour transmettre les changements sur le serveur :

1. Éditez, compilez, testez chez vous.
2. Utilisez rsync pour mettre à jour la copie de votre travail sur le serveur.
3. Utilisez un shell ssh pour relancer les tests sur celui-ci.

Points forts :

• Votre environnement, vos outils, vos configurations.
• Si vous effectuez l'étape 2 suffisamment souvent, vous disposez d'une copie redondante de vos données, sauvegardée chaque nuit, etc. en plus de votre copie locale. Bon plan backup à peu de frais si vous n'avez rien d'autre.
• Travail aussi bien chez vous, qu'en salle machine, qu'en salle de TD si les salles machines sont trop occupées.

Points faibles :

• Méthode de travail biaisée vers votre machine personnelle.
• Demande de configurer son environnement personnel pour pouvoir y effectuer les travaux demandés.
• Demande une bonne organisation, en particulier, si vous n'écrivez pas de scripts de tests (semi-)automatisés que vous pouvez relancer en une commande sur le serveur Ensimag, vous perdrez en productivité (et gagnerez en risque d'erreur) à reproduire les tests sur deux machines différentes.
• Possibilité d'incompatibilité entre ce qui est fonctionne sur votre machine et ce qui fonctionne sur le serveur distant. Il faut faire attention, et savoir un petit peu où regarder pour ne pas se faire avoir. Plus votre système est exotique / éloigné de celui du serveur, plus il faudra être vigilant.

Conseils :

• Plutôt pour ceux qui se sentent à l'aise avec le système.
• Faites vous des scripts pour automatiser les choses fastidieuses.

Travail sur machine personnelle et sur serveur en utilisant Git

Cette section suppose que vous savez déjà vous servir de Git.

Git étant un gestionnaire de versions distribué, il peut vous permettre de travailler sur deux machines en même temps, en maintenant un dépôt sur chacune, synchronisés avec git pull ou git push, selon ce qui est pratique. Afin de garder des logs sains, travaillez sur une branche temporaire, dans laquelle vous pourrez commit selon le besoin. Lorsque vous êtes satisfait des changements sur la version de temporaire et souhaitez effectuer un vrai commit, revenez sur votre branche de développement principale et effectuez un git merge --squash ; et voilà ! cela vous fera un beau gros commit, un seul.

Pour résumer, préparer le terrain :

$ git branch work
$ git checkout work

De chez vous :

$ git checkout work  # si ce n'est déjà fait
$ git pull
$ $EDITOR ...        # faites vos changements
$ git commit -a
$ git push

Du serveur :

$ git checkout work  # si ce n'est déjà fait
$ $EDITOR ...        # faites vos changements
$ git commit -a

Pour faire un vrai commit :

$ git checkout master
$ git merge --squash work
$ git commit

Points forts :

• Pareil que la méthode rsync.
• De plus, permet de travailler aux deux endroits également.
• Combine le processus de duplication à celui de développement utilisant le gestionnaire de versions (à supposer que vous en utilisiez un de base) : vous avez en plus le versionnement de vos fichiers gratuitement !

Points faibles :

• Pareil que pour la méthode rsync, mais non biaisée.
• Pas vraiment pour débutant, ou alors débutant bien motivé et prudent (lisez : faites un backup de vos données avant d'utiliser Git n'importe comment dessus).

Conseils :

• Rien de spécial, Si vous vous lancez là-dedans, vous savez probablement ce que vous faites de toute façon. :)
• Ah si, lorsque vous êtes sous pression et devez effectuer des tests rapidement (p.ex. deadline de rendu de TP), rsync est plus simple et il est moins facile de faire des bêtises avec ; cela va plus vite de l'utiliser.