lundi 10 août 2015
Par Mathieu le lundi 10 août 2015, 21:45
Cachet is an opensource status page. It displays incidents, manually or automaticaly created to inform users of what is going on the monitored service.
Note that Cachet does not do any monitoring, that’s why Nagios will be used to send incidents events through its API.
The code can be downloaded at : https://github.com/mpellegrin/nagios-eventhandler-cachet
mercredi 10 juin 2015
Par Mathieu le mercredi 10 juin 2015, 18:12
Pour référence, et parce que c’est parfois utile de connaître la taille réelle d’un fichier creux.
Pour afficher la taille déclarée :
$ ls -lh nomdufichier -rw-r--r-- 1 root root 401G Jun 10 18:09 nomdufichier
Pour afficher la taille réelle :
$ du -h nomdufichier 60G nomdufichier
Rappel : un fichier creux est un fichier dont la taille déclarée pour le système est différente de la taille effective sur le disque. C’est particulièrement utile pour créer des fichiers à écriture aléatoire (par exemple des fichiers téléchargés par P2P), ou des disques de machines virtuelles (qcow2, vmdk).
Un fichier creux s’obtient en déclarant un index de fin de fichier plus grand que la taille effectivement “remplie” par le fichier sur le disque.
mardi 9 juin 2015
Par Mathieu le mardi 9 juin 2015, 14:37
Si vous savez ce qu'est un backup, vous devriez savoir qu'il y a plusieurs types de backups :
Évidemment, un backup complet est plus simple à restaurer, puisque ce sont les fichiers, et rien que les fichiers ; alors que le backup incrémental a un format de fichier spécial lui permettant de représenter les "diffs" à chaque sauvegarde. Mais considérant le gain d'un backup incrémental en bande passante, vitesse, et espace disque , votre solution pour un backup régulier devrait être le backup incrémental.
Duplicity est un logiciel libre similaire à rdiff-backup. Duplicity permet de créer un backup incrémental. Duplicity peut également chiffrer les fichiers, pour pouvoir les envoyer en toute sécurité sur un service de stockage distant. Dans une configuration classique, Duplicity est utilisé conjointement avec rsyc pour optimiser les temps de transfert vers le stockage distant, mais vous pouvez très bien utiliser un disque de stockage local, un serveur FTP, ou un cloud Amazon E3 pour y envoyer vos sauvegardes. Comme le titre l'indique, dans cet exemple j'utiliserai rsync.
Et les bases de données ? Les bases de données ne peuvent pas être sauvegardées simplement en copiant les fichiers de données, car cela peut provoquer une corruptio de données, et vous aurez des bases inutilisables dans vos sauvegardes. Il nous faudrait donc un script qui dump toutes les bases de données avant de sauvegarder ces fichiers de dump via notre méthode de sauvegarde préférée.
Bonne nouvelle : backupninja sait faire tout cela. Backupninja est une sorte de "backup-master" : il est capable de récupérer des données depuis différentes sources (fichiers, bases de données...) et les envoyer à différentes destinations (backup simple, duplicity...), il suffit juste d'écrire les fichiers de configuration correspondants !
Dans cet exemple, nous utiliserons donc backupninja pour récupérer nos fichiers et nos bases de données, et les envoyer pour un backup incrémental Duplicity, stocké sur un serveur SSH distant, en utilisant rsync.
C'est parti !
samedi 6 juin 2015
Par Mathieu le samedi 6 juin 2015, 16:10
Sometimes you don’t want to set up a VPN just to safely monitor your MySQL servers. Because SSL should be implemented in check_mysql_health, here is a quick and dirty patch for SSL connexion. I assume you already configured your MySQL server to use SSL if client wants to (or if user requires ssl).
File /usr/lib/nagios/plugins/check_mysql_health at line 1863, after the following block :
} else {
$self->{dsn} .= sprintf ";host=%s", $self->{hostname};
$self->{dsn} .= sprintf ";port=%s", $self->{port}
unless $self->{socket} || $self->{hostname} eq 'localhost';
$self->{dsn} .= sprintf ";mysql_socket=%s", $self->{socket}
if $self->{socket};
Add these lines :
$self->{dsn} .= ";mysql_ssl=1";
$self->{dsn} .= ";mysql_ssl_client_key=/etc/ssl/mysql/client.key";
$self->{dsn} .= ";mysql_ssl_client_cert=/etc/ssl/mysql/client.crt";
$self->{dsn} .= ";mysql_ssl_ca_file=/etc/ssl/mysql/ca.crt";
Where /etc/ssl/mysql/client.key is the path to client key, /etc/ssl/mysql/client.crt the path to client certificate, and /etc/ssl/mysql/ca.crt the path to the CA certificate.
It should work, while there is still no “SSL switch” on that plugin.
EDIT : actually there is an undocumented param named “—mycnf” which should allow you to enable SSL for client connection in a prettier way.
samedi 23 mai 2015
Par Mathieu le samedi 23 mai 2015, 10:32
This article could have been avoided if the Debian documentation was up-to-date. Actually it is not, and the solution came from Fedora documentation for OpenVPN.
Debian 8 uses systemd by default, and it implies several changes, in particular the way you start/stop your services.
A new fancy command now manage the startup : systemctl (don't mess with the sysctl command used for network configuration !)
The startup dependencies are no longer in the LSB headers in startup scripts (way too simple, boy), the dependencies are stored as symlinks in subdirectories located in /etc/systemd/* . Note that /etc/systemd/ contains some static configuration files, and that the real services configuration files are stored in /lib/systemd/* (this is where the symlinks from /etc/systemd/* points to).
Some services have been split from monolithic startup to dynamic. It means that you potentially have to enable and run multiple "services" in order to actually start the full "service". For instance, OpenVPN no longer runs every available configuration in /etc/openvpn/*.conf , you have to explicitely activate each *.conf file as a service in systemd !
You can still start your services with service servicename start.
The init scripts in /etc/init.d/* still exists, and some are still usable (monolithics services).
While you can still use the command openvpn --config /etc/openvpn/yourconfigfile.conf, you should do it with systemd. If your configuration file is /etc/openvpn/sample.conf, you should start your VPN connexion with systemctl start openvpn@sample.service .
Note that service openvpn@sample start also works.
Again, the auto startup was too simple. You now have to enable every *.conf file at boot. Enable you newly sample.conf at startup with the command systemctl enable openvpn@sample.service
This actually creates a symlink in /etc/systemd/system/multi-user.target.wants/openvpn@sample.service pointing to /lib/systemd/system/openvpn@.service
Ok, it's simpler for dynamic loads, but who needs to dynamically enable and disable configuration at boot ? If I want a different configuration, I simply write different files in the right folder...
You can enable and disable VirtualHosts by using the /etc/apache2/sites-available/ and /etc/apache2/sites-enabled/ folders. No hidden features, no boot startup configuration, all configuration files in /etc/programname/ . Way too simple ?
Hey, what if we had to configure a startup script for every VirtualHost ? Should be fun, don't you think ?
« billets précédents - page 5 de 12 - billets suivants »