Permettre la détection d’un disque à chaud

Récemment, j’ai eu une petite mésaventure avec une de mes VM: l’hôte a perdu un datastore stocké sur un SAN. Ça a bien viandé la VM, du coup, j’en ai viré le disque virtuel correspondant (ça n’était pas le disque système) et j’ai rebooté.

Quand le SAN est revenu d’entre les morts, j’ai rajouté à chaud ce datastore, mais ça n’a eu aucun impact sur la VM: pas de plantage (ouf), mais pas de nouveau disque.

Du coup, j’ai googlé un peu, et je suis tombé sur cet article d’où j’ai tiré cette commande (à lancer en root sur la VM) qui permet de dire au kernel de rescanner les bus SCSI dès fois qu’il y ait de nouveaux périphériques:

echo "- - -" > /sys/class/scsi_host/host*/scan

Ensuite, avec dmesg, on constate que le disque est bien reconnu:

[41672.511543] scsi 2:0:1:0: Direct-Access     VMware   Virtual disk     1.0  PQ: 0 ANSI: 2
[41672.511557] scsi target2:0:1: Beginning Domain Validation
[41672.512473] scsi target2:0:1: Domain Validation skipping write tests
[41672.512476] scsi target2:0:1: Ending Domain Validation
[41672.512559] scsi target2:0:1: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 127)
[41672.514544] sd 2:0:1:0: [sdb] 2097152000 512-byte logical blocks: (1.07 TB/1000 GiB)
[41672.514577] sd 2:0:1:0: [sdb] Write Protect is off
[41672.514580] sd 2:0:1:0: [sdb] Mode Sense: 61 00 00 00
[41672.514633] sd 2:0:1:0: [sdb] Cache data unavailable
[41672.514636] sd 2:0:1:0: [sdb] Assuming drive cache: write through
[41672.514990] sd 2:0:1:0: [sdb] Cache data unavailable
[41672.514993] sd 2:0:1:0: [sdb] Assuming drive cache: write through
[41672.516113] sd 2:0:1:0: Attached scsi generic sg2 type 0
[41672.877777]  sdb: sdb1
[41672.878075] sd 2:0:1:0: [sdb] Cache data unavailable
[41672.878078] sd 2:0:1:0: [sdb] Assuming drive cache: write through
[41672.878156] sd 2:0:1:0: [sdb] Attached SCSI disk

Perdition (proxy pop/imap/sieve)

L’idée est d’accéder aux services de messagerie (pop/imap/sieve) depuis une machine en DMZ. Cette machine ne disposera pas d’un serveur POP/IMAP ni d’un accès au stockage des mails. Pour que l’utilisateur accède à ses emails, on passera donc par un proxy: perdition.

Dans les contraintes que l’on s’ajoute, on veut que les services ne soient utilisables qu’en mode sécurisé (TLS ou SSL).

Continue reading

OpenVPN: log et fail2ban

Récemment, j’ai eu à monter un serveur OpenVPN.

Personnellement, quand je monte ce type de services, j’aime bien avoir trois choses:

  • un moyen de bloquer les bourrins qui tentent de brute-forcer le service (en général, fail2ban fait bien le boulot);
  • un moyen d’avoir des logs lisibles rapidement/facilement (logwatch) ;
  • un moyen de ne pas avoir des fichiers de logs de 12km de longs (logrotate).

Le problème, c’est que par défaut, ces outils ne gèrent pas ou mal OpenVPN. Cet article n’explique pas comment installer et configurer un serveur VPN, juste comment configurer logrotate, fail2ban et logwatch.

Continue reading