Pour bien configurer un serveur, il existe plusieurs façons, chaque administrateur ayant la plupart du temps sa propre conf en fonction de ses habitudes et celles de ses users.

Je vous propose ici quelques petits tips à mettre en place sur votre serveur pour voir un peu se qui s’y passe.

Connexion SSH

Il est toujours intéressant de connaître les connexions ssh des utilisateurs sur votre serveur, que ce soit pour des statistiques ou tout simplement surveiller les différentes connexions pour par exemple intervenir rapidement en cas d’intrusion.

Pour cela, il existe un moyen très simple avec l’utilisation de sshrc. Dans le man, il est dit :

/etc/ssh/sshrc
Commands in this file are executed by ssh when the user logs in,
just before the user's shell (or command) is started.
See the sshd(8) manual page for more information.

Nous allons donc y introduire un petit bout de script qui enverra un mail automatiquement.

#!/bin/sh
DATE=`date "+%d-%m-%Y %H:%M"`
IP=`echo $SSH_CONNECTION | awk '{print $1}'`
REVERSE=`dig -x $IP +short`
 
# Message + envoi du mail
echo "USER : $USER
IP : $IP
ReverseDNS : $REVERSE
Date : $DATE
 
" | mail -s "[SSH] $DATE - Connexion de $USER" your_email@domaine.com

A chaque connexion ssh d’un utilisateur, vous recevrez un mail contenant diverses informations. Je souligne au passage qu’un authentification ssh par clef est toujours plus sûre ;)

Modifications de fichiers

Il existe plusieurs applications (plus ou moins performantes) permettant de voir les fichiers modifiés sur votre serveur. Ici, un petit script tout bête qui va vous permette de voir les modifications effectuées depuis X jours sur votre serveur dans un ou plusieurs répertoires donnés.

Bien entendu c’est une surveillance basique, rien de comparable avec un contrôleur d’intégrité (tripwire par exemple), mais cela peut s’avérer très pratique, notamment pour retrouver rapidement une erreur faite dans un script après une modification, mais aussi pour vérifier qu’aucune modification externe n’est faite sur des fichiers sensibles.

#!/bin/sh
DATE=`date "+%d-%m-%Y %H:%M"`
LAPS=1
INFOS="Liste des fichiers modifiés :\n"
for i in `find /etc/ -mtime -$LAPS` `find /home/user/ -mtime -$LAPS`; do
        if [ -f $i ]; then
                INFOS="$INFOS\n$i"
        fi;
done
echo $INFOS | mail -s "[MODIF] $DATE - Fichiers modifies" your_email@domaine.com

N.B : Une vérification est faite pour n’avoir que les fichiers et non les répertoires + fichiers.

Dans l’instruction for i in … ; do vous pouvez mettre plusieurs répertoire en utilisant `find /rep/ -mtime -$LAPS`.

Une fois le script créé, il vous suffit de mettre en place un cron (ici à 23h59 tous les jours) qui le lancera automatiquement et vous avertira par mail des changements.

59 23 * * * /path/to/your/script

Consommation de bande passante

Savoir qui consomme le plus de bande passante sur un serveur est souvent très intéressant, je vous propose donc ici un petit script qui va vous permettre de recevoir par mail les informations concernant les hôtes qui consomment le plus de bande passante, ici sur les 10000 derniers paquets.

#!/bin/sh
DATE=`date "+%d-%m-%Y %H:%M"`
tcpdump -c 10000 -ni eth0 | perl -lane 'END{@keys=sort{$h{$a}  <=> $h{$b}} keys %h;for(reverse(@keys)){printf("%32s => %i\n", $_, $h{$_}) if($h{$_}>100);}} $h{$F[1]}++;' | mail -s "[BP] $DATE - Consommation bande passante" your_email@domaine.com

A noter que pour faire plaisir à Vincent, j’ai utilisé du perl et non du python ^^

Une fois le script en place, un petit ajout dans le cron et c’est partit. Vous pouvez le faire tourner autant de fois que vous voulez, cela dépend surtout du traffic de votre serveur, ici 4 fois par jour soit toutes les 6 heures.

* */6 * * * /path/to/your/script

Voilà, si cela vous intéresse, il y aura surement d’autres tips à venir et surtout n’hésitez pas à demander si vous cherchez un petit truc particulier ou si vous avez des remarques.

Et comme à son habitude, Symfony fait bien les choses car il intègre par défaut une option de déploiement basé sur cette technologie. Pour l’utiliser, il suffit de disposer de rsync sur les serveurs source et final. En général il suffit d’un:

apt-get install rsync

Ensuite, éditez votre fichier config/properties.ini comme ceci, en remplaçant les paramètres selon vos informations:

[preprod]
  host=192.168.10.202                   #ip du serveur de destination
  port=22                               #port utilisé pour la connexion ssh, 22 est le port par défaut
  user=root                             #utilisateur qui se connectera au serveur de destination
  dir=/var/www/vhosts/monsite/httpdocs  #dossier qui recevera le projet symfony sur le serveur de destination
  type=rsync                            #le type de deploiement
  pass=                                 #indique qu'il y a un mot de passe (il faudra le taper lors de la connexion)

Un autre fichier config/rsync_exclude.txt permet d’exclure certains fichiers ou groupe de fichiers

.svn
/web/uploads/*
/cache/*
/log/*
/web/*_dev.php
.DS_Store
.cache
.project
.settings
/web/*Plugin

Personnellement, une fois le projet déployé une fois, j’y ajoute également config/ProjectConfiguration.class.php contenant le lien vers votre installation de symfony, qui diffère parfois entre dev et prod.
Concernant la règle /web/*Plugin qui regroupe les dossiers web des plugins, le problème vient des liens symboliques qui doivent être changés si le chemin de l’installation de symfony n’est pas identique en dev et en prod. Je les exclus donc du rsync et les republie après le rsync sur le serveur de prod via la ligne:

php symfony plugin:publish-assets

Voilà, c’est fini, il suffit maintenant de lancer la commande suivante à la racine de votre projet:

php symfony project:deploy preprod

preprod étant le nom que vous lui aurez donné le fichier ini. Cette commande ne fait qu’une simulation du transfert, pas d’inquiétude. Si tout se passe bien, vous pouvez lancer la commande finale:

php symfony project:deploy preprod --go

Et vous assistez alors à la copie quasi instantanée de votre projet.