walk-hoary

Archives pour la catégorie Tutoriel

Crontab si facile !

Crontab

Cron est à GNU ce que at est à MS Windows, il s’agit du système de programmation des tâches de base fournit par l’OS.

Chaque utilisateur peut modifier ses propres tâches en tapant crontab -e. Les tâches exécutées sont bien évidement lancées sous l’utilisateur du cron.

La visualisation

crontab -l permet simplement de visualiser la liste des tâches pour l’utilisateur.

La purge

crontab -r permet vider les tâches de l’utilisateur.

L’édition

En tapant crontab -e , vous tomberez sur l’édition du fichier correspondant à votre cron. La syntaxe est assez simple.

Voici la première ligne que l’on peut trouver.
#m h dom mon dow command
nous pouvons par déduction découvrir sa signification.
m comme Minute
h comme Hour
dom comme Day Of Month
mon comme Month
dow comme Day Of Week (0 = dimanche)

Des exemples

Lancer une commande :

Tous les jours à 14h30
#m h dom mon dow command
30 14 * * * ~/commande.shTout les Lundi à minuit
#m h dom mon dow command
0 0 * * 1 ~/commande.sh

Tous les 1ers de chaque mois à minuit
#m h dom mon dow command
0 0 1 * * ~/commande.sh

Tous les 3 minutes
#m h dom mon dow command
*/3 0 * * * ~/commande.sh

A 6h et 18h
#m h dom mon dow command
* 6,18 * * * ~/commande.sh

Toutes les minutes de 19h à 20h le vendredi
#m h dom mon dow command
* 19-20 * * 5 ~/commande.sh

Allons plus loin

La présence du fichier /etc/cron.allow donnera la liste des utilisateurs autorisés à utiliser cron, dans le cas ou ce fichier n’existe pas, tout le monde peut y acceder. Le fichier /etc/cron.deny à l’inverse, interdira les utilisateurs souhaités.

Vous pouvez aussi utiliser les parametres spéciaux :

@reboot exécution au démarrage du système
@yearly exécution une fois par an (ou @annually)
@monthly exécution une fois par mois
@weekly exécution une fois par semaine
@daily exécution une fois par jour (ou @midnight)
@hourly execution une fois par heure

Envoyer la sortie standard vers une adresse email

~/commande.sh | mail -s « sujet du mail » email@dom.tld

Vous pouvez bien sûr utiliser la redirection standard et d’erreur dans votre commande.

Bonne programmation !

Tags: , ,

Screen, domptez le multi-tache en ligne de commande

Cet article s’adresse à vous si vous travaillez sur vos serveur à distance.

Je pars du principe que vous connaissez déjà le système de la manipulation des processus ; ctrl + c pour suspendre, ctrl + z pour suspendre, fg pour recuperer en avant plan, bg pour dé-suspendre en arriere plan et jobs…

nohup

Nohup est une commande qui permet de garder une autre commande passée en paramètre même si vous fermez votre console ou coupez la connexion avec le serveur.Nohup génere un fichier nohup.out qui recupere la sortie standard de la commande passée en paramètre.

screen

Screen est un programme, dont on peut comparer à une console ; en lancant screen, vous vous retrouvez comme dans une nouvelle console. Vous pouvez lancez plusieurs screens comme vous le souhaitez.

Voici les commandes :

screen Crée un nouvel environement shell

screen wget http://www.serveur.tld/file.txt Lance la commande wget… dans un nouveau screen

screen -r [id_du_screen_facultatif] Recupere un envirenement, si il en existe plusieurs, vous verez la liste des screens

Quel interet me direz vous ? Et bien vous pouvez à l’aide de divers raccourcis naviguer à travers les screens. Simplement avec le raccourcis ctrl + a puis votre touche de commande :

ctrl + a puis d Quit le screen sans le terminer

ctrl + a puis \ Quit le screen et le termine

ctrl + a puis maj + s Divise votre screen en 2 vues

ctrl + a puis tab Bascule d’une partie à l’autre

ctrl + a puis c Ouvre un shell dans la vue en cours

ctrl + a puis «  Vous demande quelle vue utiliser dans la vue en cours

ctrl + a puis un_nombre Choisis le numero de vue à utiliser dans la vue en cours

ctrl + a puis maj + a Renomme la vue en cours

Bref vous comprendrez ici l’avantage de screen, vous pouvez recuperer votre shell depuis n’importe où.

Tags: , , ,

Comment sauvegarder votre serveur ?

Posséder ou gérer un serveur c’est bien, mais en oublier ses sauvegardes c’est mal !

Je vous propose ici une méthode pour faire des sauvegardes complètes et incrémentales très simples pour vos données. Je vous parlerais de la sauvegarde du système par la suite.

Que sauvegarder ?

On va s’occuper uniquement des données modifiables par vous et vos application, je parle bien sûr de vos scripts, bases de données et tout ce qui est hors système.

Quand sauvegarder ?

Cela va dépendre de la vitesse de changement de vos données, il va de soi que nous n’aurons pas besoin d’une sauvegarde toute les heures pour un site personnel.
Personnellement, j’estime à 2 heures de perte maximum pour mes bases de données et 24H pour les fichiers.

Où sauvegarder ?

Sauvegarder sur la même machine n’a qu’un intérêt très limité, en cas d’erreur humaine sur la machine ou accident matériel, nous perdons la machine et ses sauvegardes.
Il est donc important de placer ses sauvegardes sur un support géographiquement décalé par rapport à la machine à sauvegarder.

De quel façon sauvegarder ?

Nous utiliserons ssh pour réaliser nos transferts d’un serveur à l’autre. Le serveur de sauvegarde lancera de lui même les opérations par tache cron.

Nous allons dans cette exemple faire une sauvegarde par jour, et conserver les sauvegardes des 2 derniers jours, 2 dernières semaines, et 2 derniers mois.
Le principe est simple et a déjà fait ses preuves, nous utilisons les hardlinks :

  1.  On imagine que une sauvegarde de la veille existe déjà sur le serveur des sauvegardes.
  2. On déplace la sauvegarde de la veille dans « backup_J-1 »
  3. On duplique ce répertoire avec des hardlinks, notre copie sera donc très légère par rapport à une sauvegarde complète, mais tout le fichiers sont présents.
  4. On synchronise cette copie avec la machine à sauvegarder

Pour les bases de données, j’utilise un script qui crée une archive par base de données ; le script a la faculté de découvrir toutes les bases de l’utilisateur employé.

Le script

Voici mon script lancé une fois par jour :
#!/bin/shdirbackups='/home/user/backups'
dirtoarchive='user@machine:/home/linuxquimp'
targetdumps=$dirbackups/day-1/mysql
bdduser=user_bdd
bddpass='pass_bdd'
bddhost='machine'

#Deplacement des archives
mv $dirbackups/day-3 $dirbackups/day-3-deleted
rm -rf $dirbackups/day-3-deleted
mv $dirbackups/day-2 $dirbackups/day-3
mv $dirbackups/day-1 $dirbackups/day-2
mv $dirbackups/day $dirbackups/day-1

# Creation de la copie de day-1/ sur day/
mkdir -p $dirbackups/day
cp -al $dirbackups/day-1/* $dirbackups/day/
rm -rf $dirbackups/day/mysql

# Synchronisation
rsync --delete --stats --rsync-path=/home/user/cron/rsync-2.6.9/rsync $dirtoarchive/ $dirbackups/day

databases=(`echo 'show databases;' | mysql -h $bddhost -u $bdduser --password=$bddpass | grep -v ^Database$`)
test -d $targetdumps || mkdir -p $targetdumps
for d in "${databases[@]}"; do
if [[ $d != 'tmp' && $d != 'test' && $d != 'information_schema' ]]
then
mysqldump --host=$bddhost --user=$bdduser --password=$bddpass --quick --add-drop-table --all ${d} | gzip > $targetdumps/${d}.sql.gz
fi
done

Rien de ne vous empeche d’utiliser la partie qui sauvegarde les bases de données dans un cron lancé plusieurs fois par jour/ par heure.

Je pense que vous aurez compris qu’il faille aussi toute les semaines et tout les mois lancer les autres scripts qui permettent de deplacer les backups dans les bons repertoires.

Toute les 2 heures :
#!/bin/sh

dirtoarchive='user@machine:/home/linuxquimp'
targetdumps=$dirbackups/day/mysql
bdduser=user_bdd
bddpass='pass_bdd'
bddhost='machine'

databases=(`echo 'show databases;' | mysql -h $bddhost -u $bdduser --password=$bddpass | grep -v ^Database$`)
ladate=(`date +%F_%H-%M-%S`)
test -d $targetdumps || mkdir -p $targetdumps
for d in "${databases[@]}"; do
if [[ $d != 'tmp' && $d != 'test' && $d != 'information_schema' ]]
then
mysqldump --host=$bddhost --user=$bdduser --password=$bddpass --quick --add-drop-table --all ${d} | gzip > $targetdumps/${d}_$ladate.sql.gz
fi
done

Toute les semaines avant le backup du jour :
Dans ce script je supprime les dumps mysql faits chaque heure
#!/bin/sh
dirbackups='/home/user/backups'

# deplacement des archives

rm $dirbackups/week-2
mv $dirbackups/week-1 $dirbackups/week-2
mv $dirbackups/day-3 $dirbackups/week-1

#Suppression des dump horaires database
#rm -rf $dirbackups/week-1/mysql
rm $dirbackups/week-1/mysql/*_*-*-*_*-*-*.sql.gz

Tous les mois avant le backup de la semaine :
#!/bin/sh
dirbackups='/home/user/backups'

#deplacement des archives
mv $dirbackups/month-3 $dirbackups/month-3-deleted
rm -rf $dirbackups/month-3-deleted
mv $dirbackups/month-2 $dirbackups/month-3
mv $dirbackups/month-1 $dirbackups/month-2
mv $dirbackups/week-2 $dirbackups/month-1

Il y a surement des erreurs mais le principe est là… 😉

Tags: , , , , ,

Authentification automatique par SSH sans mot de passe

Simplement avec un système de certificat.

Voici comment ça fonctionne

Imaginons un poste client et un poste serveur, nous tentons évidement d’etablir une connexion ssh du client vers le serveur.
Habituellement, nous tapons la commande : ssh user@machine , puis on entre le mot de passe.

Pour éviter cela, nous allons faire 2 choses :

  1. Créer un jeu de clés (clé publique et clé privée) sur le client
  2. Copier la clé publique du client sur le serveur.

Voici comment procéder

Générer le jeu de clé/certificat sur le client

ssh-keygen -t dsa
On vous demandera où placer ce jeu, répondez par default.
On vous demandera une passphrase pour crypter votre certificat, vous pouvez ne rien mettre si vous estimez que vous seul pouvez acceder à votre compte local du client.

Copiez la clé publique sur le serveur

ssh-copy-id -i ~/.ssh/id_dsa.pub user@machine
Cette commande ne fait qu’ajouter votre clé publique dans un fichier sur le serveur. Voici une commande équivalente :
cat ~/.ssh/id_dsa.pub | ssh user@machine "cat - >> ~/.ssh/authorized_keys"

Voila, vous pouvez desormais vous identifier sur le serveur sans mot de passe.

Tags: , , , ,

Je n'aime pas les boîtes noires.