# uname -a

Switch

Mot-clé -

Fil des billets

samedi 29 août 2015

Postfix : configure postmaster, hostmaster, and abuse catchall for RFC compliance

Par Mathieu le samedi 29 août 2015, 18:02 - Hacks

This short howto will show you how to set up a catchall for common required email addresses. Some mail servers are testing if mail is accepted on this addresses to detect spammymail servers. Hostmaster address can also be used for domain Trading, to check the ownership of the domain.

1. Create a file named /etc/postfix/regexp-catchall.cf with the following content:

# Catchall to comply with RFC standards
/^postmaster@/    youshouldreadit@mydomain.com
/^hostmaster@/    youshouldreadit@mydomain.com
/^abuse@/         youshouldreadit@mydomain.com

Replace youshouldreadit@mydomain.com with a mail address you actually read.

2. Open /etc/postfix/main.cf and locate (or create) the line virtual_alias_maps, and add at the end regexp:/etc/postfix/regexp-catchall.cf, for instance:

virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf, regexp:/etc/postfix/regexp-catchall.cf

3. Restart Postfix.

Warning : read comment #4 for issues with this setup.

7 commentaires

mercredi 10 juin 2015

Linux : déterminer la taille réelle d'un fichier creux

Par Mathieu le mercredi 10 juin 2015, 18:12 - Hacks

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

Configurer un backup incrémental avec duplicity, rsync, et backupninja sous Debian

Par Mathieu le mardi 9 juin 2015, 14:37 - Hacks

English version.

Introduction

Si vous savez ce qu'est un backup, vous devriez savoir qu'il y a plusieurs types de backups :

  • Un backup complet copie tous les fichiers, en espérant que votre disque de backup soit assez grand pour accueillir plus d'un backup.
  • Un backup incrémental commence par faire un backup complet, puis les fois suivantes n'enregistre que les "différences" sur les fichiers modifiés.

É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.

Les outils

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 !

Lire la suite...

4 commentaires

samedi 6 juin 2015

Nagios : quick and dirty patch to enable (force) SSL on check_mysql_health

Par Mathieu le samedi 6 juin 2015, 16:10 - Hacks

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

Migrate an OpenVPN configuration to Debian 8 (Jessie) with systemd

Par Mathieu le samedi 23 mai 2015, 10:32 - Hacks

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.

The main topic : systemd

What changes

  • 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 !

What doesn't change

  • 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).

Run your OpenVPN configuration

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.

Start your VPN at boot

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...

Meanwhile, in Debian Apache package

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 ?

Sources

5 commentaires

- page 3 de 6 -