Dès qu’on a plus d’un serveur à gérer il est intéressant de pouvoir centraliser les logs des différentes machines pour en simplifier l’administration. C’est relativement facile avec rsyslog. Ce mini tuto va nous permettre de monter un serveur de logs sous Debian, les logs étant stockées dans une base MySQL.

Configuration du serveur de logs

Si ce n’est pas encore fait, installer et configurer les paquets mysql-client et mysql-server. On installe ensuite les pagets requis par rsyslog :

aptitude install rsyslog rsyslog-doc rsyslog-mysql

La configuration de rsyslog-mysql se fait automatiquement à la fin de l’installation par dbconfig. Avec les options par défaut on aboutit à la création d’une base MySQL nommée Syslog, contenant 2 tables SystemEvents et SystemEventsProperties. L’utilisateur rsyslog@localhost aura le contrôle total sur cette base. Ces informations de connexion sont stockées dans /etc/rsyslog.d/mysql.conf :

### Configuration file for rsyslog-mysql
### Changes are preserved
 
$ModLoad ommysql
*.* :ommysql:localhost,Syslog,rsyslog,motdepasse

On active ensuite la réception des logs distantes en éditant /etc/rsyslog.conf et en décommentant les lignes correspondantes :

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514
 
# provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

On redémarre le démon rsyslog :

/etc/init.d/rsyslog restart

Le serveur est maintenant configuré pour enregistrer les logs dans la base, et il écoute sur le port 514 les messages entrant. On peut vérifier que la table MySQL est bien alimentée avec les logs locales :

mysql -u rsyslog -p -Bsr -e "SELECT Message FROM SystemEvents LIMIT 0,20" Syslog

Attention, si le serveur de logs se trouve derrière un routeur, il faudra penser a activer les règles NAT qui vont bien (redirection du traffic UDP et TCP 514->514 vers le serveur de logs).

Configuration des serveurs distants

Il faut maintenant configurer les autres serveurs pour qu’ils envoient leurs logs au serveur de log. Dans l’exemple j’utilise ici aussi rsyslog mais ça fonctionne aussi avec syslog ou syslog-ng (avec un paramétrage différent).

Installation du paquet :

aptitude install rsyslog

Création d’un répertoire de travail

mkdir /var/spool/rsyslog

On ajoute les lignes suivantes à la fin du fichier /etc/rsyslog.conf (adapter l’adresse du serveur ):

# Envoi des logs au serveur de logs
$WorkDirectory /var/spool/rsyslog  # default location for work (spool) files
$ActionQueueType LinkedList   # use asynchronous processing
$ActionQueueFileName srvrfwd  # set file name, also enables disk mode
$ActionResumeRetryCount -1    # infinite retries on insert failure
$ActionQueueSaveOnShutdown on # save in-memory data if rsyslog shuts down
*.*       @@adresse.du.serveur.de.logs:514

On redémarre le démon, et c’est tout :

/etc/init.d/rsyslog restart

Installation de LogAnalyser

Retour au serveur de logs pour installer l’interface web Adiscon LogAnalyser qui va nous permettre de visualiser et d’analyser nos messages syslog. On suppose qu’un serveur Apache et PHP 5 sont déjà installés sur le serveur. A l’heure où j’écris la dernière version stable de LogAnalyser est la 3.2.1.

Téléchargement et décompression de l’archive:

wget http://download.adiscon.com/loganalyzer/loganalyzer-3.2.1.tar.gz
tar -xvzf loganalyzer-3.2.1.tar.gz

On crée un répertoire loganalyser à la racine du serveur web:

mkdir /var/www/loganalyser

On copie les fichiers LogAnalyser requis dans ce répertoire:

cp -a loganalyzer-3.2.1/src/* /var/www/loganalyser

On rend le user Apache propriétaire du dossier:

chown -R www-data:www-data /var/www/loganalyser

Avec un navigateur on se rend ensuite à l’adresse http://adresse.du.serveur.de.logs/loganalyser et on configure LogAnalyser en suivant les instructions de l’assistant.
Consulter le fichier /var/www/loganalyser/INSTALL pour des instructions détaillées si besoin.

Une remarque pour conclure, la table MySQL SystemEvents peut se remplir rapidement et devenir très volumineuse. Un petit script de purge placé en cron permettra d’éviter les mauvaises surprises:

#!/bin/bash
# Purge mensuelle des logs de la base MySQL Syslog
RETENTION=180 # Durée de rétention des logs (en jours)
# Paramètres MySQL
MYSQL_HOST="localhost"
MYSQL_DB="Syslog"
MYSQL_USER="rsyslog"
MYSQL_PASSWD="motdepasse"
# Suppression des enregistrements MySQL
sql="DELETE FROM SystemEvents WHERE DATEDIFF(NOW(), DeviceReportedTime) > $RETENTION"
mysql -h $MYSQL_HOST -u $MYSQL_USER -p$MYSQL_PASSWD -e "$sql" -B -s $MYSQL_DB

Liens

Using the syslog receiver module
Reliable Forwarding of syslog Messages with Rsyslog
Writing syslog messages to MySQL

Ce memo me sert pour configurer WebDAV avec cryptage SSL sur un serveur Apache. J’utilise WebDAV pour offrir un accès fichiers aux webmasters des sites que j’héberge, c’est plus souple et plus sûr que le FTP. Cette config est très basique, Webdav permet un paramétrage très fin des autorisations, notamment avec la directive <Limit …>

Une des contraintes de Webdav est que le serveur Apache doit avoir les droits en lecture-écriture sur tous les répertoires et fichiers partagés. Il faut donc veiller à ce que le user sous lequel s’exécute Apache (www-data dans mon cas) en reste propriétaire. C’est pourquoi les concepteurs de Webdav recommandent de ne pas utiliser d’autre protocole pour accéder à ces fichiers. C’est à mon humble avis un peu excessif, mais il faut y faire attention, un upload fait par SSH ou FTP n’aura probablement pas les bons droits.

Requis

• Apache 2
• Openssl
• Un compte sur cacert.org

Installer les modules Apache

a2enmod ssl
a2enmod dav
a2enmod dav_fs
a2enmod dav_lock
a2enmod rewrite
/etc/init.d/apache2 force-reload

Générer le certificat SSL

Dans le répertoire /etc/ssl/private :

openssl req -nodes -new -keyout mondomaine.key -out mondomaine.csr

On peut passer toutes les questions sauf « Common Name (eg, YOUR name) », où il ne faut surtout pas mettre son nom mais le nom du domaine.

cat mondomaine.csr

Copier la sortie dans le presse-papier
Sur le site cacert.org aller sur Certificat de domaine / Nouveau
Demander un certificat de classe 3
Coller le csr
Récupérer le certificat dans le presse-papier et le coller dans /etc/ssl/private/mondomaine.crt

finir par :

chmod 600 mondomaine.*

Recopier le certificat racine CACert Classe 3 dans le magasin de certificats /etc/ssl/certs sous le nom cacert_class3.crt

Il est aussi possible d’utiliser un certificat autosigné, comme expliqué ici par exemple. L’avantage du certificat CACert est qu’il est issu d’une autorité certes non commerciale mais reconnue. Si le certificat racine de CACert n’est pas présent sur les postes clients on peut le télécharger ici

Configurer Apache

Attention, un seul serveur virtuel SSL par adresse IP!

Hors serveur virtuel, ajouter les directives :

NameVirtualHost *:80
NameVirtualHost *:443
DAVMinTimeout 600
DAVDepthInfinity On

Dès qu’on a mis en place le SSL, il faut que tous les serveurs virtuels soient assignés à un port, 80 pour http ou 443 pour https.

ex :

<VirtualHost *:80>
...
</VirtualHost>

Déclarer le serveur virtuel

On crée le fichier /etc/apache2/sites-availables/webdav :

<VirtualHost *:80>
ServerName mondomaine
# Force SSL
RewriteEngine on
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [R,L]
</VirtualHost>
<VirtualHost *:443>
ServerName mondomaine
ServerAdmin webmaster@mondomaine
SSLEngine On
SSLCACertificateFile /etc/ssl/certs/cacert_class3.crt
SSLCertificateFile /etc/ssl/private/mondomaine.crt
SSLCertificateKeyFile /etc/ssl/private/mondomaine.key
DocumentRoot /var/www
<Directory />
Options -Indexes FollowSymLinks
AllowOverride none
</Directory>
<Directory /var/www/site1>
Options Indexes
AllowOverride none
Order allow,deny
allow from all
DAV on
AuthName "Administration site Site 1"
AuthType Basic
AuthUserFile /etc/apache2/htpasswd-webdav
<Limit GET POST PROPFIND PUT DELETE PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
Require user utilisateur1
</Limit>
</Directory>
<Directory /var/www/site2>
Options Indexes
AllowOverride none
Order allow,deny
allow from all
DAV on
AuthName "Administration site Site 2"
AuthType Basic
AuthUserFile /etc/apache2/htpasswd-webdav
<Limit GET POST PROPFIND PUT DELETE PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
Require user utilisateur2
</Limit>
</Directory>
ErrorLog syslog
LogLevel warn
CustomLog /var/log/apache2/access_dav.log combined
</VirtualHost>

Créer la base utilisateurs

htpasswd -c /etc/apache2/htpasswd-webdav utilisateur1
New password:
Re-type new password:
Adding password for user utilisateur1
htpasswd /etc/apache2/htpasswd-webdav utilisateur2
New password:
Re-type new password:
Adding password for user utilisateur2

Donner les droits d’accès à Apache

chown www-data /etc/apache2/htpasswd-webdav
chmod 660 /etc/apache2/htpasswd-webdav

Configurer le firewall

Ouvrir le port TCP 443

Le moment de vérité!

on active le site :

a2ensite webdav
/etc/init.d/apache2 reload

S’il n’y a pas d’erreur il ne reste plus qu’a tester le partage avec un client Webdav : Dossiers Web sous Windows, le kio webdavs:// avec Konqueror (attention webdav:// ne fonctionne pas en SSL), le client intégré à Mac OS X, etc…

Liens

Le site officiel webdav

WP-Print 2.2 était incompatible mais Lester Chan à développé de nouvelles versions de ses plugins compatibles avec WP 2.5. La version WP-Print 2.3 beta 2 semble bien fonctionner, à vous de le dire. J’attends la version finale pour faire la traduction, ça reste donc en anglais pour le moment. Pour les admins WordPress qui font la mise à jour WP-Print, pensez à mettre aussi à jour les permaliens sinon ça marche pas.

A l’usage j’ai eu quelques soucis avec la nouvelle interface de téléchargement de médias, Ajaxisée et Flashifiée à mort. Quand j’essayais d’uploader un fichier, rien ne se passait. Il y a toute une page (en anglais) qui recense les problèmes avec cette nouvelle interface. Pour ma part j’ai du faire les manips suivantes :

• Modifier le fichier .htaccess à la racine du blog et rajouter les lignes :

</IfModule>
<IfModule mod_security.c>
<Files async-upload.php>
SecFilterEngine Off
SecFilterScanPOST Off
</Files>
</IfModule>

• Mettre à jour le plugin Flash pour Firefox. Sous Ubuntu, c’est flashplugin-nonfree dans les dépots medibuntu.

• Le serveur non critique, type LAMP ou serveur mail, sur lequel est installé un nombre limité de paquets ne présentant pas à priori d’incompatibilités, et qui ne nécessite pas une administration paranoïaque.
• Le poste de travail d’un utilisateur qui ne veut ou ne peut pas s’occuper des mises à jour.

Dans ces 2 cas il peut être intéressant que les mises à jour de sécurité s’appliquent automatiquement, sans pour autant automatiser le passage aux nouvelles versions, autrement plus risqué.

Voilà comment j’ai fait :

Installation du paquet unattended-upgrades

apt-get install unattended-upgrades

Editer /etc/apt/apt.conf.d/50unattended-upgrades

// Paquets à mettre à jour (origine, archive)
Unattended-Upgrade::Allowed-Origins {
"Ubuntu gutsy-security";
// Décommenter pour automatiser les changements de version, pour ceux qui savent ce qu'ils font
//    "Ubuntu gutsy-updates";
};
 
// Liste des paquets ne devant pas être mis à jour (exemple)
Unattended-Upgrade::Package-Blacklist {
"nagios-nrpe-plugin";
"nagios-plugins";
"nagios-plugins-basic";
"nagios-plugins-standard";
"nagios2";
"nagios2-common";
"nagios2-doc";
};

Editer ou créer /etc/apt/apt.conf.d/10periodic et ajouter :

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Dans les versions précédentes d’Ubuntu, on peut trouver ces paramètres regroupés avec les autres dans /etc/apt/apt.conf, la tendance actuelle semble être d’utiliser un fichier par fonctionnalité activée dans /etc/apt/apt.conf.d/, et pourquoi pas.
Et voilà c’est tout, la tâche cron quotidienne apt se chargera des mises à jour de sécurité. Les actions sont loggées dans /var/log/unattended-upgrades/

Edit du 7 juin 2011

Depuis Gutsy les choses ont bien évolué et même si la méthode décrite ci-dessus reste adaptée à un serveur, c’est plus simple d’utiliser l’interface graphique pour les machines de bureau :

• Ouvrir le gestionnaire de mise à jour (Menu Système / Administration)
• Dans l’onglet Mises à jour, cocher la case Installer les mises à jour de sécurité sans confirmation
• Valider, et c’est fait.

Créer un répertoire de blog temporaire

mkdir blognew

Dans ce répertoire extraire la dernière version stable de WordPress (attention au point à la fin de la commande svn)

cd blognew
svn co http://svn.automattic.com/wordpress/trunk .

Recopier à la main les éléments personnalisés (.htaccess, wp-config.php, wp-content/, etc…) du répertoire de blog actuel vers le nouveau

Sauvegarder la base de données

Renommer les répertoires :

mv blog blog.save
mv blognew blog

Lancer le script de mise à jour (il n’y avait pas de mise à jour de la base pour cette version) :

http://tavie.onsenfout.com/wp-admin/upgrade.php

La prochaine mise à jour (2.3.2 ?) pourra être effectuée avec la commande :

cd blog
svn update