Articles plus anciens

Nous avons vus comment allumer un PC à distance avec le Wake On Lan, voici maintenant comment l’éteindre à distance.

Dans tous les cas le PC qui lancera l’ordre d’extinction est un PC Linux. On peut cependant décrire 2 cas :

 

Éteindre un PC Linux

Cela se fera via SSH :

 

 ssh user_distant@machine_distante sudo shutdown -h now

 

Le problème de cette commande est qu’elle demande la mot de passe de l’utilisateur distant, on pourra cependant aisément contourner ce problème avec la connexion SSH par clé.

Enfin il faudra que l’utilisateur distant soit déclaré dans sudoer et que la commande shutdown puisse être exécutée sans saisie du mot de passe sudo.

Pour cela sur la machine décrite comme machine distante, en étant connecté avec votre utilisateur principal (qui peut bien sur être l’utilisateur utilisateur_distant), faire un petit

 

sudo visudo

 

Et ajouter les lignes suivantes :

Cmnd_Alias     SHUTDOWN = /sbin/shutdown
user_distant            ALL = NOPASSWD: SHUTDOWN

On autorise ici utilisateur_distant à lancer la commande shutdown sans saisir de mot de passe.

Edit 264/06/2011 : Voir aussi mon article Allumer / éteindre un PC sous Linux à distance (scripts)

 

Éteindre un PC Windows

Dans ce cas on utilisera le protocole RPC, dont l’implémentation Linux est fournie avec Samba.

On fera alors un simple :

 

net rpc shutdown -f -I machine_distante -U utilisateur_distant%mot_de_passe -t 10 -C "Arrêt en cours..."

 

Je n’ai pas approfondi les droits que devait avoir l’utilisateur distant dans Windows, puisque dans mon cas il était administrateur (comme souvent sous Windows)


Cet article est le premier d’une série dans la lignée de la série sur rSnapshot, j’y décrirai succinctement les étapes mise en œuvre pour sauvegarder un PC sous Windows à partir d’un PC sous Linux.

Succinctement, puisque je les rédige à partir de mes anciennes notes d’installations que je ne peux pas vérifier puisque je n’ai plus de machine sous Windows.


Première étape, installer et paramétrer Samba.


L’installation se fait via un simple :

sudo aptitude install samba



Vient ensuite la configuration, pour cela tout se fait dans le fichier /etc/samba/smb.conf

Ci dessous un extrait de celui que j’avais paramétré  (j’étais sous Gutsy, le format on donc pu changer)


#======================= Global Settings =======================
[global]
   workgroup = WORKGROUP
   server string = %h server (Samba, Ubuntu)
   security = user
   encrypt passwords = true
   invalid users = root
#======================= Share Definitions =======================
[homes]
   comment = Home Directories
   writable = yes
   hide dot files = yes
[Multimedia]
   comment = Partage multimédia
   path = /multimedia
   guest ok = no
   writable = yes
   browseable = yes
[Sauvegarde]
   comment = Partage Sauvegarde
   path = /Sauvegarde
   guest ok = no
   writable = yes
   browseable = yes



Les points d’intérêt de ce fichier :

  • workgroup : mettre ici le groupe de travail dans lequel votre PC Windows est.
  • security : user, permet  de faire le lien entre l’utilisateur Windows et un utilisateur Linux. Il faudra donc avoir un utilisateur ayant le même nom sous Windows et Linux.
  • [Multimedia]/[Sauvegarde] : nom du partage sur la machine Linux a créer pour Windows, ce n’est pas obligatoire si vous utilisez Samba pour un accès dans l’autre sens (Linux –> Windows)


Pour  connaitre le workgroup sous Windows :  

  • sous XP : clic droit sur « poste de travail », Propriétés , onglet « nom de l’ordinateur », zone groupe de travail.
  • sous Windows 7 : clic droit sur Ordinateur, Propriétés, zone groupe de travail

Si vous ne voyez pas groupe de travail mais domaine à la place, ce paramètrage ne fonctionnera pas



On re-démarre Samba pour prendre en compte les configuration :


sudo /etc/init.d/samba restart 


Et voila, je vous l’avais dit le paramétrage est basique…



Rque :

Sous Gutsy, il fallait explicitement ajouter les utilisateurs Linux voulus dans la base des utilisateurs Samba avec la commande suivante :

smbpasswd -a yoann


Le mot de passe à saisir est propre à Samba il peut donc être différent du mot de passe Linux




Après avoir mis en place une stratégie de sauvegarde avec rSnapshot, il est intéressant de recevoir a chaque lancement de ce dernier, un rapport.


Il y a la solution simple consistant à rediriger la sortie standard de rsnapshot vers un mail, mais on peut faire plus propre/beau en utilisant le script perl rsnapreport.


Ce script est inclu dans le package rsnapshot depuis la version 1.3.0,  il se trouve archivé dans /usr/share/doc/rsnapshot/examples/utils/rsnapreport.pl.gz.


Le copier et le dé-tarrer à l’endroit de votre choix.


Son usage est simple il suffit de renvoyer la sortie de rsnapshot vers l’entrée du script.


Il faudra cependant avoir préalablement activé les statistiques sur rsync.


Pour cela dans le fichier de configuration de rsnapshot, on ajoutera –stats à l’argument rsync_long_args :

rsync_long_args --delete --numeric-ids --delete-excluded --stats



Voici ensuite mon utilisation de rsnapreport :

rsnapshot -v -c rsnapshot.conf daily > /var/log/svc/rsnapshot.log 2>&1
cat  /var/log/svc/rsnapshot.log | rsnapreport.pl | mail -s Sauvegarde adresse_mail



Ce qui me donne des rapports comme celui-ci :

SOURCE                          TOTAL FILES   FILES TRANS      TOTAL MB     MB TRANS   LIST GEN TIME  FILE XFER TIME
--------------------------------------------------------------------------------------------------------------------
sweethome:/home/mon_user              18577           237      22290.64       499.48   0.001 seconds   0.000 seconds



Sources :

http://www.maxsworld.org/index.php/how-tos/rsnapshot-backups

http://psomas.wordpress.com/2009/07/19/rsnapshot-tipstricks/




Si vous utilisez rSnapshot pour sauvegarder le home d’une machine distante via SSH et sudo vous serez probablement confronté à l’echec de la sauvegarde avec un message semblable à celui-ci :

rsync: readlink "/home/username/.gvfs" failed: Permission denied (13)


Il semble que cela soit dû à un bug dans le package gvfs.

Pour contourner le problème, il suffit ndas la configuration de rsnapshot, d’ajouter une règle d’exclusion qui sera transmise à rsync.


Cela peut se faire via l’argument exclude :

exclude .gvfs

ou via rsync_long_args :

rsync_long_args --delete --numeric-ids --delete-excluded --exclude='.gvfs'



Sources :

http://ubuntuforums.org/showthread.php?t=791693

http://www.nabble.com/-home-%3Cuser%3E-.gvfs-causing-problems-for-rsync-td20318088.html



Lorsque l’on veut faire une sauvegarde d’une machine distante avec rSnapshot, on a plusieurs choix :

  • Monter un partage Samba
  • Monter un partage NFS
  • Passer à travers SSH


La dernière solution à bien sûr ma préférence :

  • sécurisé
  • j’ai déja openssh-server d’installé sur les machines à sauvegarder, je n’ai donc rien d’autre à installer.



Au niveau utilisateur j’ai créé  :

  • un utilisateur sur le serveur de sauvegarde (sweetBox) qui lancera rSnapshot : on l’appelera user_rsnapshot
  • un utilisateur sur la/les machines à sauvegarder (swettHome) : on l’appelera user_distant


L’utilisateur user_rsnapshot a un repertoire dont il est propriétaire sous /var/log à des fin de log.


Remarque : cet article appliqué a sudo marche tout aussi bien si vous l’appliquez à rsync directement.



Connexion SSH sans mot de passe


On se basera sur l’article Simplifier les connexions SSH dont je rappelle ici les grandes lignes

  • connexion avec user_rsnapshot
  • génération d’une paire de clé
  • copie de la clé publique généré dans le authorized_key de user_distant
  • connexion à l’ordinateur distant avec user_distant afin d’ajouter l’empreinte de l’ordinateur distant à sauvegarder dans la liste des ordinateurs connus



Configuration de rSnapshot


Création d’un fichier de configuration rsnapshot dans le home de user_rsnapshot, voir pour cela voir Sauvegarde avec rSnapshot.


Dans la section sauvegarde de ce fichier, mettre une ligne de la forme (avec des tabulations) :

backup       user_distant@machine_a_sauvegarder:/repertoire_a_sauvegarder       destination


La syntaxe de la source est la même syntaxe que lors de la copie de fichier via scp, enfin la destination est optionnelle (penser tout de même à mettre la tabulation)



Test


Faire un test en modifiant par exemple votre fichier de configuration pour ne sauvegarder qu’un petit répertoire (le Bureau par exemple), ainsi le test sera plus rapide que si lancez directement la sauvegarde de tous votre home de x Go.


Lancer rSnapshot :

rsnapshot -v -c fichier.conf daily


Normalement tout devrait bien se passer (pas de message d’erreur) et la connexion SSH devrait se faire demander de mot de passe.



Restriction SSH et sauvegarde avec sudo


On va désormais paramétrer la machine à sauvegarder pour n’autoriser la connexion SSH que lors de la sauvegarde et faire en sorte que rsync côté client (c’est à dire la machine sauvegardé) tourne en sudo permettant ainsi la sauvegarde de tous les répertoires voulus sur la machine clientes y compris ceux pour lesquelles l’utilisateur user_distant n’a pas de droits.


Se connecter (physiquement ou en SSH) sur la machine à sauvegarder avec l’utilisateur user_distant.



Script de validation de la commande SSH


Créer un script où vous le souhaitez que l’on nommera (au choix) validate-rsync, y copier ceci :



#!/bin/sh
 
case "$SSH_ORIGINAL_COMMAND" in
 *\&*)
 echo "Rejected"
 ;;
 *\(*)
 echo "Rejected"
 ;;
 *\{*)
 echo "Rejected"
 ;;
 *\;*)
 echo "Rejected"
 ;;
 *\<*)
 echo "Rejected"
 ;;
 *\`*)
 echo "Rejected"
 ;;
 *\|*)
 echo "Rejected"
 ;;
 rsync\ --server*)
 sudo $SSH_ORIGINAL_COMMAND
 ;;
 *)
 echo "Rejected"
 ;;
 esac



Ce script test la variable d’environnement $SSH_ORIGINAL_COMMAND (créée lors de la connexion SSH) et rejette toutes les connexions SSH dont la commande est différente de rsync –server.

La connexion SSH est donc impossible pour les usage autre que la sauvegarde.



Appel du script de validation


Il faut maintenant indiquer a SSH d’appeller ce script lors de la connexion, cela se fait dans authorized_keys.

Nous avons vus dans Simplifier les connexions SSH que nous pouvions grâce à authorized_keys limiter les connexions SSH à certaine adresse IP, nous allons ici rediriger notre connexion SSH vers notre script de validation :

Éditer votre fichier authorized_keys :

vim ~/.ssh/authorized_keys


Et ajouter au début le mot-clé command suivi du chemin vers votre script de validation :


from="192.168.1.222",command="/home/user_distant/bin/validate-rsync" ssh-rsa AAAAB3NzaC1yc2EAAA  ... VJpj9cjzjPTyYcXgGiQ== user_distant@machine_a_sauvegarder 



Exécution en tant que sudo


Pour que votre sauvegarde puisse accéder à tous les répertoire de votre filesystem, il faut que rsync soit lancé en sudo.

Dans le script validate-rsync ci-dessous vous pourrer remarque que lorsque que la commande SSH est accepter, on ne se contente pas de l’exécuter, mais on a précédé la variable d’environnement $SSH_ORIGINAL_COMMAND de sudo


rsync\ --server*)
 sudo $SSH_ORIGINAL_COMMAND
 ;;


Il faut ensuite paramétrer le fichier sudoer pour autoriser votre utilisateur à lancer rsync via sudo sans demander de mot de passe.


Si votre utilisateur user_distant n’est pas déjà autorisé dans sudo (ce qui est certainement le cas si vous venez juste de le créer pour la sauvegarde), il vous faudra vous connecter avec votre utilisateur principal (ou faire un su).

On entre ensuite dans le fichier sudoer via visudo :


sudo visudo



Et ajoutera une ligne du genre :

svc ALL = NOPASSWD: /usr/bin/rsync


Indiquant que l’utilisateur user_distant à le droit d’utiliser sudo sans mot de passe (NOPASSWD) pour la commande rsync et ce quel que soit la machine sur laquelle il est (ALL)


Test


Sur le serveur de sauvegarde , re-lancer rSnapshot comme lors du test précédent :

rsnapshot -v -c fichier.conf daily


Il ne devrait pas y avoir de changement par rapport au test précédent si ce n’est que vous pouvez désormais suavegarde le home ou le bureau d’un uatilisateur autre que l’utisateur user_distant.


On va en plus faire un test pour valider le bridage SSH en saisissant la commande :


ssh user_distant@machine_distante ls


Au lieu de nous donner le contenu d’un répertoire (normalement le home de user_distant), on a :


 Rejected


Nous indiquant que la connexion SSH est interdite pour autre chose de la sauvegarde avec rsync.




Sources :

Le site de référence : http://troy.jdmz.net/rsnapshot/

Modification du précédent pour appliquer le sudo : http://www.pervasive-network.org/SPIP/Backup-incremental-avec-rsnapshot

http://www.ruzee.com/blog/2008/11/using-rsnapshot-for-file-and-database-backups

http://blog.innerewut.de/2005/6/3/follow-up-on-remote-filesystem-snapshots-with-rsnapshot

http://www.maxsworld.org/index.php/how-tos/rsnapshot-backups

http://blog.mageekbox.net/?post/2008/11/07/Mise-en-place-de-sauvegardes-%C3%A0-l-aide-de-rsnapshot

http://blog.innerewut.de/2005/5/25/remote-filesystem-snapshots-with-rsnapshot

http://geekfault.org/2009/05/16/rsnapshot/