blog/2025
1
Fork 0
Code Issues Activity

Récupération d'articles d'archives

Browse Source
This commit is contained in:
Richard Dern
2026-03-29 03:00:47 +02:00
parent 060119c91c
commit ecc25fe7cf
592 changed files with 17498 additions and 8153 deletions
Download Patch File Download Diff File Expand all files Collapse all files

59
content/interets/informatique/2012/02/04/faire-fonctionner-xmpp-avec-status-net/index.md Normal file
View File

@@ -0,0 +1,59 @@
---
comments_url: https://com.richard-dern.fr/post/511
date: '2012-02-04 01:59:00'
links:
- lang: fr
name: Page d'origine sur Archive.org
url: https://web.archive.org/web/20120221102629/http://ingnu.fr/2012/02/04/faire-fonctionner-xmpp-avec-status-net/
tags:
- StatusNet
- XMPP
title: Faire fonctionner XMPP avec status.net
weather:
humidity: 53
illuminance: 0.0
precipitations: false
pressure: 1030.8
source:
- open-meteo
temperature: -9.8
wind_direction: 46
wind_speed: 9.9
---
Cela fait maintenant quelques temps que j'enquiquine mes followers sur [social.ingnu.fr](https://web.archive.org/web/20120221102629/https://social.ingnu.fr/ingnu/all) à propos de XMPP qui déconne sévèrement avec la release 1.0.1 de [status.net](https://web.archive.org/web/20120221102629/http://status.net/) : déconnections intempestives, mauvaise gestion de la file d'attente, etc.
La [page](https://web.archive.org/web/20120221102629/http://publications.jbfavre.org/statusnet/optimize-statusnet-nginx-php-fpm-apc-memcache.fr) de [Jean-Baptiste Favre](https://web.archive.org/web/20120221102629/http://www.jbfavre.org/) m'a permis de creuser un peu plus, bien que ne parlant pas de XMPP.
Il aborde tout de même quelques directives de configuration à propos des files d'attente qui m'ont échappé, directives que j'ai adapté pour mieux coller (selon moi) à une debian et à placer dans le fichier *config.php* :
```php
$config['daemon']['piddir'] = '/var/run/';
$config['daemon']['user'] = 'www-data';
$config['daemon']['group'] = 'www-data';
```
Warning : Attention à adapter *user* et *group* si chez vous ils sont différents.
À cela, il faut rajouter les lignes relatives à XMPP :
```php
addPlugin('xmpp', array(
'user'=>'identifiant du robot',
'server'=>'nom de domaine',
'password'=>'mot de passe',
'resource'=>'ce que vous voulez',
'encryption'=>true,
));
```
Maintenant, l'étape la plus "difficile".
En l'état, vous pouvez être à peu près certain que ça ne marchera pas.
Un contributeur au projet propose un patch, [que vous pouvez télécharger ici](https://web.archive.org/web/20120221102629/http://status.net/sites/default/files/issues/statusnet-1.0.1-inox.txt).
Enregistrez-le à la racine de votre instance de status.net et nommez-le par exemple statusnet.patch, puis saisissez les commandes suivantes :
```bash
sed -i "s#statusnet-1\.0\.1#\./#" statusnet.patch
patch -p1 < statusnet.patch
```
Normalement, tout devrait fonctionner à merveille désormais.

148
content/interets/informatique/2012/02/05/creer-son-propre-cloud-introduction/index.md Normal file
View File

@@ -0,0 +1,148 @@
---
comments_url: https://com.richard-dern.fr/post/512
date: '2012-02-05 17:34:00'
dossier:
- Créer son propre Cloud
links:
- lang: fr
name: Page d'origine sur Archive.org
url: https://web.archive.org/web/20120225102811/http://ingnu.fr/2012/02/05/creer-son-propre-cloud-introduction/
tags:
- Firewall
- iptables
title: Introduction
weather:
humidity: 42
illuminance: 1267.0
precipitations: false
pressure: 1027.0
source:
- open-meteo
temperature: -6.8
wind_direction: 72
wind_speed: 11.4
weight: 1
---
Je parle beaucoup sur ingnu du fait que [Google c'est le mal](https://web.archive.org/web/20120225102811/http://ingnu.fr/2011/12/25/pourquoi-google-cest-le-mal/), qu'il faut utiliser des [alternatives libres](https://web.archive.org/web/20120225102811/http://ingnu.fr/2011/12/29/quelles-sont-les-alternatives-a-google/), et que [le Cloud, c'est de la merde](https://web.archive.org/web/20120225102811/http://ingnu.fr/2012/01/19/il-faut-arreter-avec-le-cloud/).
Pour être tout à fait cohérent, il me fallait proposer des articles traitant concrètement de la mise en place de ces alternatives, et c'est pour cela que j'ai créé la rubrique "[Créer son propre cloud](https://web.archive.org/web/20120225102811/http://ingnu.fr/category/creer-son-propre-cloud/)", dont cet article constitue le premier maillon pour vous aider à construire votre serveur grâce aux Logiciels Libres.
Il y a quatre prérogatives : n'utiliser que des Logiciels Libres, assurer la confidentialité de vos données, assurer la sécurité de votre serveur, s'affranchir de tout service géré par une entreprise.
Nous considérerons que vous disposez déjà d'un système GNU/Linux, de préférence fraîchement installé, brut de décoffrage.
Je me baserai sur un système [Debian GNU/Linux](https://web.archive.org/web/20120225102811/http://www.debian.org/) (que je maîtrise bien mieux que les autres), il faudra alors adapter certaines de mes notes à votre cas précis (notamment en ce qui concerne les commandes d'installation de paquets).
La toute première étape après l'installation du système d'exploitation est d'imposer une politique de sécurité stricte.
Nous commençons donc par créer un script permettant la mise en place d'un pare-feu et qui s'exécutera à chaque démarrage de la machine.
```bash
mkdir /scripts
cd /scripts
```
Le répertoire /scripts que nous venons de créer contiendra un certains nombre de fichiers, que nous créerons au fil des articles.
Dans un premier temps, nous ne créons que le script du firewall :
```bash
nano firewall
```
```text
#!/bin/sh
IPT=/sbin/iptables
IF_EXT=eth0
IP_SSH=xxx.xxx.xxx.xxx
${IPT} -t mangle -F
${IPT} -t nat -F
${IPT} -F
${IPT} -t mangle -X
${IPT} -t nat -X
${IPT} -X
${IPT} -Z
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
${IPT} -P INPUT DROP
${IPT} -P OUTPUT ACCEPT
${IPT} -P FORWARD ACCEPT
${IPT} -A FORWARD -i lo -o lo -j ACCEPT
${IPT} -A INPUT -i lo -j ACCEPT
${IPT} -A OUTPUT -o lo -j ACCEPT
${IPT} -A INPUT -p tcp ! --syn -m state --state NEW,INVALID -j REJECT
${IPT} -N SPOOFED
${IPT} -N SERVICES
${IPT} -A SPOOFED -s 127.0.0.0/8 -j DROP
${IPT} -A SPOOFED -s 169.254.0.0/12 -j DROP
${IPT} -A SPOOFED -s 172.16.0.0/12 -j DROP
${IPT} -A SPOOFED -s 192.168.0.0/16 -j DROP
${IPT} -A SPOOFED -s 10.0.0.0/8 -j DROP
${IPT} -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
${IPT} -A SERVICES -p tcp --dport 22 -s ${IP_SSH} -j ACCEPT
##### Configuration personnalisée #####
##### Fin : Configuration personnalisée #####
${IPT} -A OUTPUT -j ACCEPT
${IPT} -A INPUT -m state --state ESTABLISH,RELATED -j ACCEPT
${IPT} -A INPUT -j SPOOFED
${IPT} -A INPUT -i ${IF_EXT} -j SERVICES
#################################
# Anti spam #
#################################
FILE="/tmp/drop.lasso"
URL="http://www.spamhaus.org/drop/drop.lasso"
[ -f $FILE ] && /bin/rm -f $FILE || :
cd /tmp
wget $URL
blocks=$(cat $FILE | egrep -v '^;' | awk '{ print $1}')
${IPT} -N droplist
for ipblock in $blocks
do
${IPT} -A droplist -s $ipblock -j LOG --log-prefix "DROP List Block"
${IPT} -A droplist -s $ipblock -j DROP
done
${IPT} -I INPUT -j droplist
${IPT} -I OUTPUT -j droplist
${IPT} -I FORWARD -j droplist
/bin/rm -f $FILE
```
Dans un premier temps, on défini quelques variables.
La plus importante est IP_SSH, c'est votre adresse IP, l'adresse depuis laquelle vous allez vous connecter au serveur via ssh.
Notice : Il est vital de s'assurer que cette variable est correctement renseignée, sans cela, vous serez incapable d'accéder au serveur une fois le script exécuté !
Ensuite, on purge les règles (pour pouvoir exécuter plusieurs fois le fichier sans que cela ne les alourdisse), on met en place une politique par défaut (rien ne doit pouvoir rentrer sans autorisation), on créé les chaînes SPOOFED et SERVICES qui vont nous permettre de séparer le trafic et de sécuriser les accès, on met en place des règles personnalisées (pour le moment, aucune), et on installe un blocage du SPAM en bonus.
Théoriquement, ce script est tout à fait utilisable tel quel.
Au fil des articles, on ajoutera des directives spécifiques au niveau du commentaire "Configuration personnalisée".
On se servira de la chaîne SERVICES pour y affecter les services hébergés par notre machine.
Important : Le "bonus block" relatif au spam va nous permettre, directement au niveau d'iptables, de dropper purement et simplement toute tentative de connexion depuis les adresses fournies par [spamhaus](https://web.archive.org/web/20120225102811/http://www.spamhaus.org/).
Dans le cas extrême où vous vous retrouviez bloqué, incapable de vous connecter en ssh à votre serveur, essayez de voir si votre hébergeur vous offre la possibilité de passer par un KVM virtuel.
Cela vous permettra de reprendre la main sur votre serveur le temps de configurer correctement le pare-feu.
Et dans le cas où le KVM est indisponible, voyez si votre hébergeur vous propose de démarrer un système de secours.
Pour information, les deux possibilités vous sont offertes chez [online](https://web.archive.org/web/20120225102811/http://www.online.net/).
Il ne reste plus qu'à enregistrer, chmoder, exécuter, et patienter jusqu'au prochain article :
```bash
chmod +x firewall
./firewall
```

362
content/interets/informatique/2012/02/05/installer-et-configurer-un-serveur-dns/index.md Normal file
View File

@@ -0,0 +1,362 @@
---
comments_url: https://com.richard-dern.fr/post/513
date: '2012-02-05 17:56:00'
dossier:
- Créer son propre Cloud
links:
- lang: fr
name: Page d'origine sur Archive.org
url: https://web.archive.org/web/20120622184230/http://ingnu.fr/2012/02/05/installer-et-configurer-un-serveur-dns/
tags:
- Bind
- DNS
title: Installer et configurer un serveur DNS
weather:
humidity: 42
illuminance: 1267.0
precipitations: false
pressure: 1027.0
source:
- open-meteo
temperature: -6.8
wind_direction: 72
wind_speed: 11.4
weight: 2
---
Le deuxième article de [cette nouvelle rubrique](https://web.archive.org/web/20120622184230/http://ingnu.fr/category/creer-son-propre-cloud/) traite logiquement de la mise en place d'un serveur DNS.
À moins que vous n'ayez recours à l'outil de gestion de vos DNS proposé par votre registrar et qu'il ne vous bride pas, vous devrez passer par l'étape du serveur DNS, d'autant qu'il nous permettra par la suite de faire bien d'autres choses que simplement faire pointer un domaine sur une IP...
Nous utiliserons le serveur [bind](https://web.archive.org/web/20120622184230/http://www.isc.org/software/bind).
Nous allons tout d'abord l'installer sur le serveur principal en tant que maître.
Si vous disposez d'un second serveur, vous pourrez le configurer en tant qu'esclave pour assurer la continuité du service.
Important : *exemple.fr*
## Pare-feu
Tout d'abord, reprenons le script de pare-feu que [nous avons configuré précédemment](https://web.archive.org/web/20120622184230/http://ingnu.fr/2012/02/05/creer-son-propre-cloud-introduction/).
```bash
nano /scripts/firewall
```
Entre les lignes :
```text
##### Configuration personnalisée #####
```
Et :
```text
##### Fin : Configuration personnalisée #####
```
Rajoutez les lignes suivantes :
```text
${IPT} -A SERVICES -p tcp --dport 53 -j ACCEPT
${IPT} -A SERVICES -p udp --dport 53 -j ACCEPT
```
Nous ouvrons donc le port 53 en TCP et en UDP.
Normalement, seul le protocole UDP est utilisé pour les requêtes, mais le protocole TCP est utilisé également pour les transferts de zones dont nous aurons besoin plus tard.
Il est donc important d'ouvrir les connexions aux deux types de protocoles, à moins que vous ne configuriez pas un serveur esclave.
Nous pourrions également spécifier directement l'adresse du serveur esclave afin d'éviter toute demande de transfert directement depuis iptables :
```text
${IPT} -A SERVICES -p tcp --dport 53 -s 2.2.2.2 -j ACCEPT
${IPT} -A SERVICES -p udp --dport 53 -j ACCEPT
```
## **Serveur maître**
Pour installer bind, rien de plus simple :
```bash
apt-get install bind9 dnsutils
```
Le paquet [dnsutils](https://web.archive.org/web/20120622184230/http://packages.debian.org/squeeze/dnsutils) contient notamment les outils *nslookup* et *dig*, qui nous serviront par la suite à tester notre installation.
Rendez-vous dans le répertoire de configuration de bind :
```bash
cd /etc/bind
/etc/init.d/bind9 stop
```
On créé le fichier le définition de notre domaine :
```bash
nano db.exemple.fr
```
```text
$TTL 86400
@ IN SOA ns.exemple.fr. postmaster.exemple.fr. (
2012020501
2D ; Refresh
15M ; Retry
3W ; Expire
86400 ) ; Negative Cache TTL
IN NS ns.exemple.fr.
IN NS ns2.exemple.fr.
IN A 1.1.1.1
ns IN A 1.1.1.1
ns2 IN A 2.2.2.2
```
Quelques explications s'imposent.
Dans la ligne relative au *SOA*, on déclare le serveur DNS autoritaire pour la zone (*ns.exemple.fr*) et l'adresse email du responsable (*postmaster.exemple.fr*, le "@"de l'adresse étant remplacé par un". ").
Ensuite, on attribue un numéro de série au fichier; ce numéro ne s'invente pas : il s'agit de la date (au format *YYYYMMDD*) suivi d'un nombre compris entre 00 et 99.
Pour plus de clarté, on va appeler ce nombre la "clé".
Si vous disposez de plusieurs domaines, vous pouvez utiliser le premier chiffre de la clé comme identifiant pour un domaine particulier (par exemple, *"j'attribuerai toujours un 1 au domaine exemple.fr, et un 2 au domaine exemple2.fr*"), tandis que le second chiffre de la clé vous servira à indenter les modifications survenues dans ce fichier pour le jour donné.
Par exemple, vous faites 4 modifications sur le fichier *db.exemple.fr*, et 7 sur le fichier *db.exemple2.fr*, en date d'aujourd'hui.
Vous pouvez attribuer les numéros de série suivants à vos fichiers : *2012020514* et *2012020527*.
Important : [ZoneCheck](https://web.archive.org/web/20120622184230/http://www.afnic.fr/fr/produits-et-services/services/zonecheck/)
Les valeurs suivantes (*refresh*, *retry*, etc.) devraient convenir à la majorité des situations.
Nous définissons ensuite les deux serveurs DNS associés au nom de domaine : *ns.exemple.fr.* et *ns2.exemple.fr.*
Ensuite, nous indiquons que le serveur principal a pour adresse IP 1.1.1.1, puis nous associons les adresses 1.1.1.1 et 2.2.2.2 aux deux serveurs de noms.
Une fois que vous avez adapté cet exemple à votre propre domaine, vous pouvez enregistrer et fermer.
Théoriquement, dans une installation de base de bind sur une debian stable, le fichier *named.conf* contient la ligne suivante :
```text
include "/etc/bind/named.conf.local";
```
Si ce n'est pas le cas, rajoutez-là :
```bash
echo "include \"/etc/bind/named.conf.local\";" >> named.conf
```
Et modifiez le fichier *named.conf.local* :
```bash
nano named.conf.local
```
Ce fichier va contenir les directives de configuration pour un domaine particulier, en l'occurrence, exemple.fr (et/ou exemple2.fr).
C'est une bonne pratique de configuration à laquelle passe la majorité des applications, cela permet de clarifier les choses, et de s'y retrouver facilement.
Mettez donc le contenu suivant dans ce fichier :
```text
zone "exemple.fr" {
type master;
file "/etc/bind/db.exemple.fr";
};
```
On défini notre instance de bind comme étant maître pour ce domaine, et on lui indique le fichier de configuration correspondant.
Enregistrez et fermez ce fichier une fois modifié.
Redémarrez ensuite bind, pour procéder à quelques tests :
```bash
/etc/init.d/bind9 restart
nslookup exemple.fr
```
Vous devriez obtenir la sortie suivante :
```text
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: exemple.fr
Address: 1.1.1.1
```
Vous noterez qu'à cause de la propagation des DNS, votre domaine n'est peut être pas encore disponible depuis l'extérieur.
N'hésitez pas à tester (en utilisant la même commande) régulièrement depuis une machine qui n'héberge pas le serveur bind.
Si la commande précédente vous retourne une sortie similaire, c'est que votre domaine est correctement configuré (du point de vue de bind en tout cas).
En l'état actuel des choses, bind devrait donc être en mesure de répondre à des requêtes portant sur votre domaine, bien qu'encore aucun domaine "utile" ne soit créé.
## **Serveur esclave**
Pour faire fonctionner deux instances de bind sur le modèle de maître/esclave, on commence par compléter un peu la configuration du serveur maître.
On reste donc sur la même machine, pour créer une clé de transfert :
```bash
dnssec-keygen -a HMAC-MD5 -b 512 -n HOST <localhost>.exemple.fr.
```
*dnssec-keygen* est un outil livré avec bind.
Grâce à la commande suivante, on génère une clé en utilisant l'algorithme HMAC-MD5, d'une longueur de 512 bits, pour un hôte particulier (-n HOST), en l'occurrence, celui indiqué à la fin.
Remplacez *<localhost>* par le nom d'hôte du serveur.
Par exemple, j'ai appelé mon serveur "minerva", sur le domaine ingnu.fr.
La commande qui s'applique à mon cas devient donc :
```bash
dnssec-keygen -a HMAC-MD5 -b 512 -n HOST minerva.ingnu.fr.
```
On génère une clé pour un hôte donné, mais *dnssec-keygen* permet bien d'autres choses que nous n'utiliserons pas ici.
Notamment, vous pouvez choisir un algorithme différent, ou créer une clé pour toute une zone.
Pour l'heure, nous souhaitons avoir la possibilité de transférer de manière sécurisée les données de zones (dans notre exemple, le fichier *db.exemple.fr*) de notre serveur maître vers le serveur esclave que nous configurerons plus tard.
Cette commande est donc suffisante pour le moment.
A l'issue de l'exécution de cette commande (qui peut durer une vingtaine de secondes), deux nouveaux fichiers ont été créés.
Ils commencent par la lettre K majuscule, et portent respectivement l'extension *.key* et *.private*.
Le premier fichier contient une ligne qu'il est possible de rajouter dans un fichier de zone, tandis que le second contient quelques détails sur la création de la clé.
Nous n'utiliserons dans notre cas précis aucun des deux dans son état actuel.
Cependant, il peut être utile de les conserver pour un usage ultérieur.
La seule chose qui nous intéresse est la clé en elle-même qui figure dans les deux fichiers.
Utilisez la commande *cat* sur le fichier *.private*, et copiez la clé qui apparaîtra.
Créez ensuite le fichier *transfer.conf* :
```bash
nano transfer.conf
```
```text
key "TRANSFER" {
algorithm hmac-md5;
secret "la clé que vous avez copié";
};
server 2.2.2.2 {
keys {
TRANSFER;
};
};
```
Dans ce fichier, nous ajoutons une clé au "trousseau" de bind, qui ne sera destinée qu'au transfert des zones entre le maître et l'esclave.
Si un cas se présente où nous devrons diffuser d'autres clés, nous en génèrerons de nouvelles, pour éviter toute interférence.
Ensuite, nous affectons cette clé au serveur esclave, 2.2.2.2.
Incluez ce fichier à votre configuration, puis modifiez le fichier *named.conf.local* :
```bash
echo "include \"/etc/bind/transfer.conf\" >> /etc/bind/named.conf
nano named.conf.local
```
```text
zone "exemple.fr" {
type master;
file "/etc/bind/db.exemple.fr";
allow-transfer { 2.2.2.2; };
};
```
Nous avons rajouté la ligne *allow-transfer { 2.2.2.2; };* qui nous permet d'éviter que n'importe qui puisse transférer nos zones sur son serveur.
Redémarrez bind :
```bash
/etc/init.d/bind9 restart
```
Désormais, lorsque le serveur maître redémarrera, il notifiera automatiquement le(s) serveur(s) esclave(s) de tout changement, et initiera le transfert des zones de manière sécurisée.
Passons maintenant à la configuration du serveur esclave à proprement parlé.
Sur la machine qui hébergera ce serveur, installez bind :
```bash
apt-get install bind9 dnsutils
```
Nous avons créé le fichier *transfer.conf* sur le serveur maître.
Le même fichier doit être créé sur la machine esclave, avec une petite nuance.
```bash
cd /etc/bind
/etc/init.d/bind9/stop
nano transfer.conf
```
```text
key "TRANSFER" {
algorithm hmac-md5;
secret "la clé que vous avez copié";
};
server 1.1.1.1 {
keys {
TRANSFER;
};
};
```
Vous noterez qu'il s'agit exactement du même fichier, y compris la même clé, mais que l'adresse IP de la clause *server* change.
Dans la configuration du serveur esclave, c'est l'adresse IP du serveur maître qu'il faut indiquer.
Ensuite, comme pour la configuration du serveur maître, on ajouter ce fichier à la configuration de bind :
```bash
echo "include \"/etc/bind/transfer.conf\" >> /etc/bind/named.conf
```
Modifions ensuite le fichier *named.conf.local* pour y ajouter la configuration de votre (vos) domaine(s) :
```text
zone "exemple.fr" {
type slave;
file "/var/cache/bind/db.exemple.fr";
masters { 1.1.1.1; };
allow-notify { 1.1.1.1; };
};
```
Nous indiquons ici que le fichier de zone *db.exemple.fr*, une fois transféré, sera stocké dans le dossier */var/cache/bind*, qui devrait déjà être créé.
Si ce n'est pas le cas, il faut le créer, et donc tous les cas, lui attribuer les bons droits :
```bash
mkdir -p /var/cache/bind
chown -R bind:bind /var/cache/bind
chmod -r 644 /var/cache/bind
```
Il suffit maintenant de redémarrer bind pour que les modifications soient prises en compte.
```bash
/etc/init.d/bind9 restart
```
Consultez immédiatement les journaux utilisés par bind :
```bash
tail -100 /var/log/syslog
```
Il se peut que vous y trouviez une erreur à propos de l'heure qui n'est pas synchronisée.
Installez sur les deux serveurs le paquet [ntpdate](https://web.archive.org/web/20120622184230/http://packages.debian.org/squeeze/ntpdate), puis synchronisez les horloges avant de redémarrer bind :
```bash
apt-get install ntpdate
ntpdate 0.fr.pool.ntp.org
/etc/init.d/bind9 restart
```
Testez maintenant votre serveur :
```text
nslookup
> server 127.0.0.1
Default server: 127.0.0.1
Address: 127.0.0.1#53
> exemple.fr
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: exemple.fr
Address: 1.1.1.1
```
Vous disposez désormais de l'une des pièces maîtresses de votre propre serveur.
La configuration de base que nous avons mis en place aujourd'hui va être complétée et sécurisée au fil des articles à venir, pour qu'au final, vous disposiez d'une solution complète vous permettant de vous affranchir des services offerts par Google, Twitter, facebook et bien d'autres.
Le serveur que nous allons monter avec ces articles va vous permettre de reprendre le contrôle de vos données.
Alors à bientôt pour le prochain article, qui traitera de la deuxième pierre angulaire de votre Cloud personnel et Libre : le serveur mail.

280
content/interets/informatique/2012/02/06/creation-de-sa-propre-autorite-de-certification/index.md Normal file
View File

@@ -0,0 +1,280 @@
---
comments_url: https://com.richard-dern.fr/post/514
date: '2012-02-06 03:23:00'
dossier:
- Créer son propre Cloud
links:
- lang: fr
name: Page d'origine sur Archive.org
url: https://web.archive.org/web/20120618100138/http://ingnu.fr/2012/02/06/creation-de-sa-propre-autorite-de-certification/
tags:
- Autorité
- Certification
- Certificats
- OpenSSL
title: Création de sa propre autorité de certification
weather:
humidity: 57
illuminance: 0.0
precipitations: false
pressure: 1027.9
source:
- open-meteo
temperature: -10.4
wind_direction: 73
wind_speed: 8.7
weight: 3
---
J'avais [initialement](https://web.archive.org/web/20120618100138/http://ingnu.fr/2012/02/05/installer-et-configurer-un-serveur-dns/) prévu d'aborder dans un troisième article la configuration d'un serveur mail, mais il fallait d'abord que j'explique comment mettre en place une autorité de certification, puisque nous allons nous en servir dans la configuration du serveur mail, mais aussi pour bien d'autres services que nous verrons ultérieurement.
À l'issue de cet article, vous aurez à disposition une série de scripts qui vous permettront de mettre rapidement et facilement en place des certificats pour tous types d'applications.
L'autorité de certification et les certificats vous permettront de chiffrer les données qui vont transiter sur votre cloud personnel.
Ainsi, si une personne malintentionnée cherchait à espionner ce qui transite entre votre propre machine et votre serveur, elle ne pourrait pas exploiter les données qu'elle récolterait.
C'est une solution fiable, même si tout chiffrement peut être "cassé".
Il faut simplement garder à l'esprit que vous n'êtes pas une banque, et que les données que vous allez stocker sur votre serveur n'ont de valeur que pour vous.
Personne ne cherchera donc à passer des semaines ou des mois à casser le chiffrement de vos certificats...
Notice : En revanche, ils seront bien utiles pour chiffrer les données qui transitent sur votre réseau.
Important : [VeriSign](https://web.archive.org/web/20120618100138/http://www.verisign.com/ssl/index.html?tid=gnps)
Créons tout d'abord un répertoire dédié à nos scripts :
```bash
mkdir -p /scripts/certificate_authority
```
Vérifions ensuite que nous disposons bien du paquet nécessaire :
```bash
apt-get install openssl
```
Nous allons créer les premiers certificats, matérialisant l'autorité de certification.
Les certificats spécifiques à certains services seront signés par cette autorité.
Pour commencer, on va se créer un fichier de configuration personnalisé :
```bash
cp /etc/ssl/openssl.cnf /scripts/certificate_authority/
cd /scripts/certificate_authority
nano openssl.cnf
```
On édite ce fichier pour y modifier les variables suivantes :
- Dans la catégorie *[CA_default]*, mettez les valeurs suivantes :
```text
dir = /scripts/certificate_authority
certs = $dir/
crl_dir = $dir/
database = $dir/index.txt
new_certs_dir = $dir/
certificate = $dir/ca.crt
serial = $dir/current_serial
crlnumber = $dir/current_crl
crl = $dir/crl.pem
private_key = $dir/ca.key
RANDFILE = $dir/.rand
```
- Dans la catégorie *[req_distinguished_name]*, renseignez les valeurs suivantes :
- *countryName_default*
- *stateOrProvinceName_default*
- *localityName_default*
- *0.organizationName_default*
- *emailAddress_default*
Enregistrez puis fermez ce fichier.
On va ensuite créer le fichier *create_ca*, qui aura pour but de créer l'autorité de certification.
L'autorité de certification n'est à créer qu'une seule fois, mais le fait de créer un script pour le faire permettra, en cas de besoin, de retrouver les commandes nécessaires.
À noter que nous allons créer un certificat dont la validité est de 10 ans (3650 jours).
```bash
nano create_ca
```
```text
#!/bin/bash
base=`dirname $0`
echo "Étape 1 : Création de la clé"
openssl genrsa -des3 -out "$base/ca.key" 1024
echo "Étape 2 : Génération de la demande de certificat"
openssl req -config "$base/openssl.cnf" -new -key "$base/ca.key" -out "$base/ca.csr"
echo "Étape 3 : Génération du certificat"
openssl x509 -days 3650 -signkey "$base/ca.key" -in "$base/ca.csr" -req -out "$base/ca.crt"
chmod 0400 ca.key
```
```bash
chmod 700 create_ca
```
Cette dernière commande nous assure que personne à part *root* ne peut exécuter ce fichier.
Ce que nous allons faire immédiatement :
```bash
./create_ca
```
Après vous avoir demandé un mot de passe (qu'il est impératif de renseigner), quelques questions vont vous être posées.
La plupart contient déjà les réponses pré-replies dans le fichier *openssl.cnf* que nous avons édité plus tôt.
Seule la variable *Organizational Unit Name* est à spécifier (mettez ce que vous voulez, par exemple "*Certificate Authority*"), et la variable *Common Name*, qui devrait contenir votre nom de domaine principal.
Une fois la commande exécutée et les variables spécifiées, trois nouveaux fichiers ont été créés dans le répertoire de travail (*/scripts/certificate_authority*) : *ca.csr* (la demande de certificat), *ca.crt* (le certificat principal) et *ca.key* (la clé privée).
On peut désormais créer de nouveaux certificats, à l'aide d'un nouveau script :
```bash
nano make_request
```
```text
#!/bin/bash
app=$1
domain=$2
base=`dirname $0`
if [ "$app" == "" ]
then
echo "Vous devez spécifier un nom d'application ou de service"
exit
fi
if [ "$domain" == "" ]
then
echo "Vous devez spécifier un nom de domaine"
exit
fi
if [ ! -d "$base/$app" ]
then
mkdir "$base/$app"
fi
echo "Étape 1 : Création de la clé"
openssl genrsa -des3 -out "$base/$app/$domain.key" 1024
echo "Étape 2 : Création de la demande de certificat"
openssl req -config "$base/openssl.cnf" -new -key "$base/$app/$domain.key" -out "$base/$app/$domain.csr"
echo "Souhaitez-vous créer une clé sans mot de passe ? (o/n) [n]"
read answer
if [ $answer = o -o $answer = O ]
then
cp "$base/$app/$domain.key" "$base/$app/$domain.key-withpass"
openssl rsa -in "$base/$app/$domain.key-withpass" -out "$base/$app/$domain.key"
chmod 0440 "$base/$app/$domain.key-withpass"
fi
chmod 0440 "$base/$app/$domain.key"
```
```bash
chmod +x ./make_request
```
L'objectif de ce script va être de générer une demande de certificat pour une application donnée et un domaine donné.
Cela nous permettra de générer des certificats différents selon les applications et les domaines, mais il est tout à fait possible (bien que déconseillé) de générer un seul certificat et de s'en servir dans toutes nos applications.
Ce script s'utilisera de la manière suivante :
```bash
./make_request <application> <domaine>
```
Ce script va également nous permettre de créer des clés sans mot de passe, ce qui sera utile avec apache.
Créons ensuite le script qui va nous permettre de demander la signature d'une demande précédente :
```text
nano sign_request
```
```text
#!/bin/bash
app=$1
domain=$2
base=`dirname $0`
serial=0
if [ "$app" == "" ]
then
echo "Vous devez spécifier un nom d'application ou de service"
exit
fi
if [ "$domain" == "" ]
then
echo "Vous devez spécifier un nom de domaine"
exit
fi
if [ ! -d "$base/$app" ]
then
echo "Aucun certificat n'a été généré pour l'application spécifiée"
exit
fi
if [ ! -f "$base/$app/$domain.csr" ]
then
echo "Aucun certificat n'a été généré pour le domaine spécifié"
exit
fi
if [ -f "$base/current_serial" ]
then
serial=`cat "$base/current_serial"`
fi
serial=$(($serial+1))
openssl x509 -req -days 3650 -in "$base/$app/$domain.csr" -CA "$base/ca.crt" -CAkey "$base/ca.key" -set_serial $serial -out "$base/$app/$domain.crt"
echo "$serial" > "$base/current_serial"
echo "Souhaitez-vous supprimer la requête initiale ? ($domain.csr) (o/n) [o]"
read answer
if [ "$answer" != "n" -a "$ans" != "N" ]
then
rm "$base/$app/$domain.csr"
fi
```
```bash
chmod 700 sign_request
```
La syntaxe est la même que précédemment :
```bash
./sign_request <application> <domaine>
```
La signature du certificat va générer un fichier portant l'extension *.crt* : c'est celui-ci qui sera notamment utilisé à travers les applications.
La procédure pour créer un certificat valide est donc la suivante.
Nous admettrons pour l'exemple que nous travaillons avec apache.
```bash
./make_request apache exemple.fr
./sign_request apache exemple.fr
```
Cela aura pour conséquence de créer un répertoire apache dans le répertoire */scripts/certificate_authority*, qui contiendra vos certificats, demandes, et clés spécifiques à apache.
Vous disposez désormais d'un ensemble complet d'outils pour générer facilement les certificats dont vous aurez besoin plus tard, et notamment lors de la mise en place du serveur mail, prochaine étape de la création de votre cloud personnel.

723
content/interets/informatique/2012/02/06/installation-de-son-propre-serveur-mail/index.md Normal file
View File

@@ -0,0 +1,723 @@
---
comments_url: https://com.richard-dern.fr/post/515
date: '2012-02-06 17:53:00'
dossier:
- Créer son propre Cloud
links:
- lang: fr
name: Page d'origine sur Archive.org
url: https://web.archive.org/web/20120621224105/http://ingnu.fr/2012/02/06/installation-de-son-propre-serveur-mail/
tags:
- Amavis
- ClamAV
- Dovecot
- IMAP
- Postfix
- SMTP
title: Installation de son propre serveur mail
weather:
humidity: 46
illuminance: 1393.7
precipitations: false
pressure: 1028.7
source:
- open-meteo
temperature: -7.7
wind_direction: 65
wind_speed: 9.5
weight: 4
---
Le quatrième article de la [nouvelle rubrique](https://web.archive.org/web/20120621224105/http://ingnu.fr/category/creer-son-propre-cloud/) va donc traiter de l'installation de son propre serveur mail, élément indispensable de la chaîne de communication.
Il existe déjà de nombreux tutoriels sur Internet, parfois très bien faits, parfois incomplets ou inadaptés.
Je ne prétends pas que mon article sera mieux que les autres, j'espère seulement qu'il trouvera son public.
Notre serveur mail devra être sécurisé : nous ferons appel au chiffrement, ainsi qu'à diverses applications permettant de filtrer spam et virus, le plus efficacement possible, sans pour autant bloquer les correspondances légitimes (il m'est arrivé que certaines personnes utilisant un serveur SMTP wanadoo (sic) se retrouvent bloquées par mon serveur, à cause d'un non respect du protocole SMTP...).
Nous utiliserons le serveur SMTP [postfix](https://web.archive.org/web/20120621224105/http://www.postfix.org/), aux côtés duquel tournera le serveur IMAP [dovecot](https://web.archive.org/web/20120621224105/http://dovecot.org/).
Le filtrage sera confié à [Spamassassin](https://web.archive.org/web/20120621224105/http://spamassassin.apache.org/), [amavis](https://web.archive.org/web/20120621224105/http://www.amavis.org/) et [clamav](https://web.archive.org/web/20120621224105/http://www.clamav.net/lang/en/).
Nous aurons recourt à une base de données de type [MySQL](https://web.archive.org/web/20120621224105/http://www.mysql.com/).
Même si vous ne gérerez qu'un seul domaine, virtualiser les utilisateurs et les domaines n'est pas plus consommateur de ressources : MySQL (ou tout autre serveur de bases de données, j'aurai pu traiter de [postgreSQL](https://web.archive.org/web/20120621224105/http://www.postgresql.org/) s'il ne me manquait pas de l'expérience) sera installé tôt ou tard, autant l'utiliser tout de suite.
Et si par la suite vous acquérez un autre domaine et que vous vouliez proposer un service mail pour ce domaine, vous n'aurez pas de migration fastidieuse à effectuer.
Lorsque debconf vous demandera un mot de passe pour MySQL (et par extension, chaque fois que vous devrez saisir un mot de passe dans les prochains articles), vous devriez considérer utiliser un [générateur de mot de passe](https://web.archive.org/web/20120621224105/http://randompassword.com/).
En utilisant un tel outil, vous pourrez générer des mots de passe complexes, de la longueur et de la complexité que vous voulez.
Sous debian donc, on installe les paquets suivants :
```bash
apt-get install amavisd-new arj bzip2 cabextract clamav clamav-freshclam clamav-daemon cpio dovecot-imapd gzip lha mysql-server p7zip pax postfix postfix-mysql postfix-pcre ripole rpm spamassassin tar unrar-free unzip xz-utils zip zoo
```
Outre postfix, dovecot, l'anti-virus et l'anti-spam, on installe également quelques utilitaires appelés par amavis/clamav pour analyser les pièces jointes aux futurs mails qui seront envoyés ou reçus par votre serveur.
On passe ensuite à la configuration de MySQL.
## MySQL
debconf vous a probablement demandé de choisir un mot de passe pour l'utilisateur root (celui de MySQL).
Vous devez maintenant créer un nouvel utilisateur pour la première base de données que nous allons créer, et qui sera exploitée par notre serveur mail.
```bash
mysql -u root -pVotreMotDePasse
```
Notice : *-p*
Saisissez alors les commandes suivantes, en remplaçant *NouveauMotDePasse* par un nouveau mot de passe, différent de celui de root (là encore, pensez à utiliser le générateur de mots de passe) :
```text
CREATE USER 'MailServer'@'localhost' IDENTIFIED BY 'NouveauMotDePasse';
GRANT USAGE ON * . * TO 'MailUser'@'localhost' IDENTIFIED BY 'NouveauMotDePasse';
CREATE DATABASE IF NOT EXISTS `MailServer` ;
GRANT ALL PRIVILEGES ON `MailServer` . * TO 'MailServer'@'localhost';
```
Nous avons créé un nouvel utilisateur nommé *MailServer*, et une base de données dans laquelle il a tout privilège.
Créons ensuite la structure :
```text
USE MailServer;
```
```text
CREATE TABLE `access_sender` (
`source` varchar(128) CHARACTER SET utf8 NOT NULL DEFAULT '',
`access` varchar(128) CHARACTER SET utf8 NOT NULL DEFAULT '',
`created` datetime NOT NULL,
`modified` datetime NOT NULL,
`active` tinyint(1) NOT NULL DEFAULT '1',
UNIQUE KEY `source` (`source`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='Virtual Sender Restrictions';
CREATE TABLE `aliases` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`source` varchar(255) CHARACTER SET utf8 NOT NULL,
`destination` varchar(255) CHARACTER SET utf8 NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
CREATE TABLE `domains` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(255) CHARACTER SET utf8 NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
CREATE TABLE `users` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`email` varchar(255) CHARACTER SET utf8 NOT NULL,
`password` varchar(32) CHARACTER SET utf8 NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
quit;
```
Nous avons créé respectivement la table qui contiendra les adresses emails toujours autorisées à nous envoyer quelque chose, quelle que soit la politique de filtrage de notre postfix, la table contenant les futurs alias, celle contenant les domaines et enfin celle qui contiendra nos utilisateurs.
La base de données est configurée, nous pouvons passer à la suite.
## Postfix
Pour que Postfix utilise la base de données que l'on vient de créer, il faut créer quelques fichiers de configuration que nous allons placer dans le répertoire */etc/postfix/mysql* :
```bash
/etc/init.d/postfix stop
mkdir /etc/postfix/mysql
```
Créez ensuite les fichiers suivants (n'oubliez pas de renseigner à chaque fois la variable *password* avec le mot de passe que vous avez attribué à l'utilisateur *MailServer*) :
```bash
cd /etc/postfix/mysql
nano alias.cf
```
```text
user = MailServer
password =
hosts = 127.0.0.1
dbname = MailServer
query = SELECT destination FROM aliases WHERE source='%s'
```
```bash
nano domains.cf
```
```text
user = MailServer
password =
hosts = 127.0.0.1
dbname = MailServer
query = SELECT 1 FROM domains WHERE name='%s'
```
```bash
nano email2email.cf
```
```text
user = MailServer
password =
hosts = 127.0.0.1
dbname = MailServer
query = SELECT email FROM users WHERE email='%s'
```
```bash
nano maps.cf
```
```text
user = MailServer
password =
hosts = 127.0.0.1
dbname = MailServer
query = SELECT 1 FROM users WHERE email='%s'
```
```bash
nano senders_whitelist.cf
```
```text
user = MailServer
password =
hosts = 127.0.0.1
dbname = MailServer
query = SELECT access FROM access_sender WHERE source='%s' AND active = '1'
```
Nous venons simplement de créer les fichiers permettant de communiquer avec les tables créées précédemment.
Modifions ensuite la configuration principale de postfix, à commencer par le fichier *main.cf*.
Nous allons créer une nouvelle configuration en partant de rien, on va donc déplacer le fichier d'origine et en créer un nouveau :
```bash
cd ../
mv main.cf main.cf.orig
nano main.cf
```
Copiez-y ensuite la configuration suivante :
```text
mynetworks = 127.0.0.0/8
# Dovecot settings
virtual_transport = dovecot
dovecot_destination_recipient_limit = 1
# MySQL settings
virtual_mailbox_domains = mysql:/etc/postfix/mysql/domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql/maps.cf
virtual_alias_maps = mysql:/etc/postfix/mysql/alias.cf,mysql:/etc/postfix/mysql/email2email.cf
# SASL
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
# TLS
smtp_tls_CAfile = /scripts/certificate_authority/ca.crt
smtpd_tls_CAfile = /scripts/certificate_authority/ca.crt
smtpd_tls_cert_file = /scripts/certificate_authority/exemple.fr.crt
smtpd_tls_key_file = /scripts/certificate_authority/exemple.fr.key
smtpd_tls_received_header = yes
tls_random_source = dev:/dev/urandom
smtp_tls_security_level = may
smtpd_tls_security_level = may
smtp_use_tls = yes
smtpd_use_tls = yes
smtpd_tls_auth_only = no
#smtpd_tls_wrappermode = yes
smtpd_tls_loglevel = 1
# Filtering
content_filter = smtp-amavis:[127.0.0.1]:10024
receive_override_options = no_address_mappings
# Restrictions
unknown_address_reject_code = 554
unknown_hostname_reject_code = 554
unknown_client_reject_code = 550
unverified_sender_reject_code = 554
smtpd_helo_required = yes
strict_rfc821_envelopes = yes
smtpd_recipient_restrictions =
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
check_helo_access pcre:/etc/postfix/helo_checks.pcre,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
check_sender_access mysql:/etc/postfix/mysql/senders_whitelist.cf,
reject_rbl_client zen.spamhaus.org
```
Important : *main.cf*
Il faut créer le fichier *helo_checks.pcre*.
En utilisant les expressions rationnelles, cela permettra à postfix d'opérer un filtrage sur la commande *helo* du protocole SMTP.
```bash
nano helo_checks.pcre
```
```text
/^localhost$/ 550 Don’t use localhost
/^(base\.)?(exemple\.fr|exemple2\.fr)$/ 550 Don’t use my own domain/hostname
/^\[?88\.190\.15\.133\]?$/
550 Spammer comes to me \
Greets me with my own IP \
His mail I shall not see.
/^[0-9.-]+$/
550 Your software is not RFC 2821 compliant: \
EHLO/HELO must be a domain or an \
address-literal (IP enclosed in brackets)
```
On modifie ensuite le fichier *master.cf* :
```text
nano master.cf
```
Dé-commentez la ligne (située en début du fichier) :
```text
smtps inet n - - - - smtpd
```
Et rajoutez les lignes suivantes :
```text
dovecot unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${recipient}
```
```text
smtp-amavis unix - - n - 2 smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
-o disable_dns_lookups=yes
-o max_use=20
```
```text
127.0.0.1:10025 inet n - n - - smtpd
-o content_filter=
-o smtpd_restriction_classes=
-o smtpd_delay_reject=no
-o smtpd_client_restrictions=permit_mynetworks,reject
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restrictions=reject_unauth_pipelining
-o smtpd_end_of_data_restrictions=
-o mynetworks=127.0.0.0/8
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks
-o local_header_rewrite_clients=
```
Ces lignes servent à interfacer dovecot et amavis avec postfix.
Il nous reste encore à créer les certificats.
```bash
/scripts/certificate_authority/make_request postfix mail.exemple.fr
```
Notice : *Common Name*
*mail.exemple.fr*
Signez ensuite le certificat :
```bash
/scripts/certificate_authority/sign_request postfix mail.exemple.fr
```
La configuration de postfix étant terminée, on s'occupe des filtres.
## Filtres
```bash
/etc/init.d/amavis stop
/etc/init.d/clamav-daemon stop
/etc/init.d/clamav-freshclam stop
adduser clamav amavis
adduser amavis clamav
```
Important : *amavis*
*clamav*
*clamav*
*amavis*
On édite ensuite la configuration de amavis :
```bash
nano /etc/amavis/conf.d/15-content_filter_mode
```
Dé-commentez les lignes dans ce fichier pour qu'il ressemble à ceci :
```text
use strict;
@bypass_virus_checks_maps = (
\%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re);
@bypass_spam_checks_maps = (
\%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re);
1; # ensure a defined return
```
Puis :
```bash
nano /etc/amavis/conf.d/20-debian_defaults
```
Vers la ligne 68, assurez-vous d'avoir les directives de configuration suivantes :
```text
$final_virus_destiny = D_DISCARD; # (data not lost, see virus quarantine)
$final_banned_destiny = D_BOUNCE; # D_REJECT when front-end MTA
$final_spam_destiny = D_BOUNCE;
$final_bad_header_destiny = D_PASS; # False-positive prone (for spam)
```
On bloque ainsi totalement les virus, mais on laisse passer le spam (qui sera tagué par la suite) pour éviter de supprimer du courrier légitime.
On continue :
```bash
nano /etc/amavis/conf.d/50-user
```
```text
use strict;
#
# Place your configuration directives here. They will override those in
# earlier files.
#
# See /usr/share/doc/amavisd-new/ for documentation and examples of
# the directives you can use in this file
#
$sa_spam_subject_tag = '***** SPAM ***** ';
$spam_quarantine_to = undef;
$sa_tag_level_deflt = undef;
$final_spam_destiny=D_PASS;
@lookup_sql_dsn = (
['DBI:mysql:database=MailServer;host=127.0.0.1;port=3306',
'MailServer',
'MotDePasse']);
$sql_select_policy = 'SELECT name FROM domains WHERE CONCAT("@",name) IN (%k)';
#------------ Do not modify anything below this line -------------
1; # ensure a defined return
```
On peut maintenant démarrer les services :
```bash
/etc/init.d/amavis start
/etc/init.d/clamav-daemon start
/etc/init.d/clamav-freshclam start
```
## Dovecot
```bash
/etc/init.d/dovecot stop
cd /etc/dovecot
```
Configurons tout d'abord la connexion au serveur MySQL :
```bash
mv dovecot-sql.conf dovecot-sql.conf-orig
nano dovecot-sql.conf
```
```text
driver = mysql
connect = host=127.0.0.1 dbname=MailServer user=MailServer password=MotDePasse
default_pass_scheme = PLAIN-MD5
password_query = SELECT email AS user, password FROM users WHERE email='%u'
```
Comme d'habitude, pensez à changer le mot de passe, et mettez celui de l'utilisateur MySQL *MailServer*.
Enregistrez puis fermez, avant de modifier la configuration principale :
```bash
mv dovecot.conf dovecot.conf-orig
nano dovecot.conf
```
```text
base_dir = /var/run/dovecot
protocols = imaps managesieve
ssl = yes
ssl_cert_file = /scripts/certificate_authority/dovecot/mail.exemple.fr.crt
ssl_key_file = /scripts/certificate_authority/dovecot/mail.exemple.fr.key
ssl_key_password = MotDePasse
mail_location = maildir:/var/vmail/%d/%n/Maildir
mail_uid = vmail
mail_gid = vmail
mail_privileged_group = mail
protocol imap {
}
protocol managesieve {
login_executable = /usr/lib/dovecot/managesieve-login
mail_executable = /usr/lib/dovecot/managesieve
}
protocol lda {
postmaster_address = postmaster@exemple.fr
auth_socket_path = /var/run/dovecot/auth-master
mail_plugins = sieve
}
auth_executable = /usr/lib/dovecot/dovecot-auth
auth default {
mechanisms = plain login
passdb sql {
args = /etc/dovecot/dovecot-sql.conf
}
userdb static {
args = uid=5000 vid=5000 home/var/vmail/%d/%n
}
user = root
socket listen {
master {
path = /var/run/dovecot/auth-master
mode = 0600
user = vmail
group = vmail
}
client {
path = /var/spool/postfix/private/auth
mode = 0660
user = postfix
group = postfix
}
}
}
plugin {
sieve=/var/vmail/%d/%n/Maildir/sieve/.dovecot.sieve
sieve_dir=/var/vmail/%d/%n/Maildir/sieve
sieve_global_path = /etc/sieve/sieve.global
}
```
Lorsque nous allons générer le certificat et la clé à utiliser avec dovecot, vous aurez la possibilité de créer une clé sans mot de passe.
Si vous choisissez de créer une clé sans mot de passe, commentez la ligne *ssl_key_password = MotDePasse*.
Dans le cas contraire, indiquez le mot de passe utilisé lors de la génération du certificat.
Quelques répertoires vont devoir être créés :
```bash
mkdir /etc/sieve
mkdir /var/vmail
```
On génère les certificats :
```bash
/scripts/certificate_authority/make_request dovecot mail.exemple.fr
/scripts/certificate_authority/sign_request dovecot mail.exemple.fr
```
On créé ensuite l'utilisateur *vmail* :
```bash
addgroup vmail --gid 5000
adduser --system --disabled-password --no-create-home --disabled-login --uid 5000 --gid 5000 vmail
chown -R vmail:vmail /var/vmail
```
On peut désormais redémarrer dovecot :
```bash
/etc/init.d/dovecot restart
```
Nous avons configuré dovecot pour utiliser le plugin *sieve/managesieve*.
Cela nous permettra plus tard de mettre en place des filtres pour la messagerie.
Créons tout de même le fichier de configuration de base pour sieve, dont le rôle va être simplement de déplacer le spam dans le bon répertoire :
```bash
nano /etc/sieve/sieve.global
```
```text
require ["fileinto"];
# rule:[Spam]
if header :contains "Subject" "***** SPAM *****"
{
fileinto "Spam";
}
```
## Quelques tests
Installez le paquet [telnet](https://web.archive.org/web/20120621224105/http://packages.debian.org/fr/squeeze/telnet) si vous ne l'avez pas déjà :
```bash
apt-get install telnet
telnet localhost 25
ehlo exemple.fr
quit
```
Vous devriez avoir une sortie console qui ressemble à ceci :
```text
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 minerva.localdomain ESMTP Postfix
ehlo exemple.fr
250-minerva.localdomain
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
```
Procédez de même avec le port 465, la sortie doit être la même.
Pour tester le serveur IMAP, nous devons créer un premier domaine, puis un premier utilisateur du domaine :
```bash
mysql -u root -pMotDePasse
```
```text
USE MailServer;
INSERT INTO domains (name) VALUES ('exemple.fr');
INSERT INTO users (email, password) VALUES ('test@exemple.fr', MD5('MotDePasse'));
quit;
```
On peut ensuite tester le serveur IMAP :
```bash
openssl s_client -connect localhost:993
```
La dernière ligne affichée devrait ressembler à ceci :
```text
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
```
Suite à quoi, écrivez :
```text
A LOGIN test@exemple.fr MotDePasse
```
La fin de la ligne suivante devrait afficher "Logged in".
Concluez la session avec :
```text
a5 LOGOUT
```
Nous testerons plus tard les anti-virus et anti-spam.
Pour l'heure, nous avons une dernière chose à régler.
## Firewall
```bash
nano /scripts/firewall
```
Entre les lignes :
```text
##### Configuration personnalisée #####
```
Et :
```text
##### Fin : Configuration personnalisée #####
```
Rajoutez les lignes suivantes :
```text
${IPT} -A SERVICES -p tcp --dport 25 -j ACCEPT
${IPT} -A SERVICES -p tcp --dport 465 -j ACCEPT
```
Ce sont les deux ports à ouvrir pour que votre serveur SMTP puisse communiquer avec l'extérieur (et vice-versa).
Important : ```text
${IPT} -A SERVICES -p tcp --dport 993 -j ACCEPT
```
Cette commande permet d'ouvrir le port 993, qui est le port attribué au serveur IMAP sécurisé.
Nous n'utiliserons donc pas le port habituel, le 143.
## DNS
Dernière étape de l'installation de notre serveur mail, la modification de la configuration de notre serveur DNS pour sa prise en compte.
On édite donc le fichier de définition de notre zone :
```bash
nano /etc/bind/db.exemple.fr
```
Et on rajoute à la fin (sans oublier de modifier l'identifiant de l'enregistrement !) :
```text
IN MX 10 mail.exemple.fr.
mail IN A 1.1.1.1
```
Et on redémarre bind :
```bash
/etc/init.d/bind9 restart
```
C'est aussi simple que ça !
La prochaine étape consistera à installer un serveur web sécurisé, et quelques applications utiles, dont un client de messagerie pour jouer avec le serveur mail que l'on vient d'installer.

488
content/interets/informatique/2012/02/07/installation-dun-serveur-http-https/index.md Normal file
View File

@@ -0,0 +1,488 @@
---
comments_url: https://com.richard-dern.fr/post/516
date: '2012-02-07 00:05:00'
dossier:
- Créer son propre Cloud
links:
- lang: fr
name: Page d'origine sur Archive.org
url: https://web.archive.org/web/20120617154444/http://ingnu.fr/2012/02/07/installation-dun-serveur-http-https/
tags:
- Apache
- phpMyAdmin
- Roundcube
title: Installation d'un serveur HTTP/HTTPS
weather:
humidity: 59
illuminance: 0.0
precipitations: false
pressure: 1029.2
source:
- open-meteo
temperature: -11.2
wind_direction: 56
wind_speed: 8.3
weight: 5
---
On continue [notre nouvelle série d'articles](https://web.archive.org/web/20120617154444/http://ingnu.fr/category/creer-son-propre-cloud/).
Après avoir [créer un pare-feu de base](https://web.archive.org/web/20120617154444/http://ingnu.fr/2012/02/05/creer-son-propre-cloud-introduction/) que nous complèterons au fil des articles, après avoir [mis en place une autorité de certification](https://web.archive.org/web/20120617154444/http://ingnu.fr/2012/02/06/creation-de-sa-propre-autorite-de-certification/), puis [un serveur DNS](https://web.archive.org/web/20120617154444/http://ingnu.fr/2012/02/05/installer-et-configurer-un-serveur-dns/) et [un serveur mail](https://web.archive.org/web/20120617154444/http://ingnu.fr/2012/02/06/installation-de-son-propre-serveur-mail/), nous nous attaquons maintenant à l'installation du serveur [apache](https://web.archive.org/web/20120617154444/http://httpd.apache.org/).
Apache devra pouvoir desservir des pages aussi bien en HTTP qu'en HTTPS, permettre l'utilisation de langages comme [PHP](https://web.archive.org/web/20120617154444/http://fr.php.net/) et les scripts CGI, tout en assurant une bonne réactivité et un degrés certain de sécurité.
Un serveur HTTP(S) nous permettra de mettre en place une grande variété de services : dans un premier temps, un outil pour gérer notre base de données et un client mail, puis par la suite, un blog, un wiki, un lecteur de flux RSS, etc.
Il nous permettra également de mettre en place un proxy pour simplifier l'accès à des applications offrant une interface web, partager et accéder aux fichiers, et bien d'autres choses encore.
Rappelons que l'objectif est de s'affranchir de tout outil du Cloud, proposé par de grandes entreprises telles que Google.
Apache en sera un moyen d'y accéder facilement.
Important : _Top Level Domain_
_mail.exemple.fr_
_exemple.fr_
_.fr_
Ce petit rappel effectué, on peut organiser les sites desservis par apache de la manière suivante :
```text
/var/www Racine
/var/www/exemple.fr Racine du domaine
/var/www/exemple.fr/mail Racine du sous-domaine mail
/var/www/exemple.fr/mail/www Racine du site hébergé
/var/www/exemple.fr/mail/log Journaux
/var/www/exemple.fr/www Racine du domaine principal
/var/www/exemple.fr/www/www Racine du site hébergé
/var/www/exemple.fr/www/log Journaux
```
Une telle arborescence permet d'organiser correctement les différents sites qui pourront être desservis par Apache, tout en ayant rapidement à portée de la main les journaux pour chaque sous-domaine.
Cela nous permettra également de confier ces journaux à une application telle que [awstats](https://web.archive.org/web/20120617154444/http://awstats.sourceforge.net/) pour une analyse plus efficace que si tous les journaux étaient regroupés dans le même fichier.
Avant toute chose, installons quelques paquets, stoppons apache, et supprimons les hôtes virtuels par défaut :
```bash
apt-get install apache2 libapache2-mod-php5 php5 php5-mysql php5-mcrypt php-mdb2 php-mdb2-driver-mysql
/etc/init.d/apache2 stop
a2dissite default && rm /etc/apache2/sites-available/default
a2dissite default-ssl && rm /etc/apache2/sites-available/default-ssl
cd /etc/apache2
```
On désactive ensuite totalement la journalisation dans apache :
```bash
rm conf.d/other-vhosts-access-log
nano apache2.conf
```
Commentez la ligne :
```text
ErrorLog ${APACHE_LOG_DIR}/error.log
```
Comme on va également faire appel à SSL, on active le port 443 :
```bash
mv ports.conf ports.conf-orig
nano ports.conf
```
```text
NameVirtualHost *:80
NameVirtualHost *:443
Listen 80
Listen 443
```
On va continuer en créant quatre arborescences différentes, pour quatre sites différents.
Le premier pourrait être simplement qualifié de bonne pratique : afin d'accélérer le chargement des pages, il convient de confier certains éléments à un sous-domaine particulier, desservi par un hôte virtuel ne journalisant pas ses accès, et contenant des éléments statiques, tels que des images ou des scripts.
On économise ainsi plusieurs cycles d'écriture à chaque chargement de page.
## Domaine static
Créons la première arborescence :
```bash
mkdir -p /var/www/exemple.fr/static/www
```
On créé ensuite notre premier hôte virtuel :
```bash
cd /etc/apache2/sites-available
nano static.exemple.fr
```
```text
<VirtualHost *:80>
ServerName static.exemple.fr
ServerAdmin contact@exemple.fr
DocumentRoot /var/www/exemple.fr/static/www
</VirtualHost>
```
Rien de bien sorcier : on déclare un nouvel hôte virtuel écoutant sur toutes les interfaces configurées dans apache (\*) sur le port 80.
On déclare également le nom de domaine affecté à cet hôte virtuel, en indiquant éventuellement (ce n'est pas une obligation) l'adresse email du responsable.
Enfin, la dernière directive défini la racine du site, là où se trouveront les fichiers.
Pour le moment, il n'y en a aucun, mais au moins, on a un hôte virtuel destiné à stocker les fichiers statiques, c'est déjà ça.
## Domaine www
Le domaine (sous-domaine plus exactement) _www_ est un peu particulier dans la mesure où il est plus utilisé par habitude que réel besoin : on se passe très bien de la partie _www_ dans *www.exemple.fr*.
Cela nous donne toutefois deux bonnes occasions : conserver notre arborescence de base saine, et voir comment créer un alias de domaine.
Notre objectif sera de faire en sorte que, peu importe si on accède à notre site principal via `http://exemple.fr` ou `http://www.exemple.fr`, on devra tomber sur la même page.
On aura recours, pour cela, à la directive _ServerAlias_.
On créé donc notre second hôte virtuel avec son arborescence :
```bash
mkdir -p /var/www/exemple.fr/www/{www,log}
nano www.exemple.fr
```
```text
<VirtualHost *:80>
ServerName exemple.fr
ServerAlias www.exemple.fr
ServerAdmin contact@exemple.fr
DocumentRoot /var/www/exemple.fr/www/www
CustomLog /var/www/exemple.fr/www/log/access_log
ErrorLog /var/www/exemple.fr/www/log/error_log
</VirtualHost>
```
Par la même occasion, on en a profité pour spécifier le chemin vers le journal des accès et le journal des erreurs.
Il faudra procéder de même pour tout hôte virtuel créé à l'avenir.
Pour le moment, nous n'utiliserons pas ce domaine : c'est vous qui déciderez ce que vous voulez en faire : blog, portail privé, etc.
## Domaine mysql
Le nom de ce sous-domaine importe peu.
J'ai choisi _mysql_, comme j'aurai pu choisir _pma_, _phpmyadmin_, _admin_ ou tout autre.
Cependant, en consultant régulièrement mes logs, j'ai constaté que certains s'amusent à scanner certains sous-domaines-clés, pour éventuellement tomber sur un script d'administration non-sécurisé.
J'ai vu passer toutes sortes de sous-domaines, mais assez étonnamment, peu tentent _mysql.exemple.fr_.
Ce domaine servira à accéder justement à [phpMyAdmin](https://web.archive.org/web/20120617154444/http://www.phpmyadmin.net/), script php probablement le plus utilisé pour administrer graphiquement ses bases de données.
Outre l'aspect pédagogique de sa présence dans cet article, puisque c'est un bon prétexte à l'introduction à SSL avec apache, ce sera également un outil très pratique pour la création de futures bases de données, mais aussi pour des tâches plus triviales comme la population de notre première base créée, _MailServer_.
Créons l'arborescence et l'hôte virtuel :
```bash
mkdir -p /var/www/exemple.fr/mysql/www
```
```bash
nano mysql.exemple.fr
```
```text
<VirtualHost *:80>
ServerName mysql.exemple.fr
Redirect / https://mysql.exemple.fr/
</VirtualHost>
<VirtualHost *:443>
ServerName mysql.exemple.fr
DocumentRoot /var/www/exemple.fr/mysql/www
SSLEngine On
SSLCertificateFile /scripts/certificate_authority/apache/mysql.exemple.fr.crt
SSLCertificateKeyFile /scripts/certificate_authority/apache/mysql.exemple.fr.key
</VirtualHost>
```
Ici, nous créons un hôte virtuel écoutant sur le port 80, dont l'unique objectif sera de forcer la redirection vers le même hôte virtuel, mais écoutant sur le port 443 (le port HTTPS).
La connexion à _mysql.exemple.fr_ sera donc forcément chiffrée.
On va tout de suite créer le certificat et la clé qui vont bien :
```bash
/scripts/certificate_authority/make_request apache mysql.exemple.fr
/scripts/certificate_authority/sign_request apache mysql.exemple.fr
chown www-data:www-data /scripts/certificate_authority/apache/*
```
Warning : _Common Name_
On va ensuite télécharger et installer phpMyAdmin.
À l'heure où j'écris ces lignes, la dernière version disponible est la 3.4.9.
```bash
cd /usr/src
wget http://freefr.dl.sourceforge.net/project/phpmyadmin/phpMyAdmin/3.4.9/phpMyAdmin-3.4.9-all-languages.tar.gz
tar zxf phpMyAdmin-3.4.9-all-languages.tar.gz
cp -Rv phpMyAdmin-3.4.9-all-languages/* /var/www/exemple.fr/mysql/www/
mkdir /var/www/exemple.fr/mysql/www/config/
chown -R www-data:www-data /var/www/exemple.fr/mysql/www
```
Après avoir décompressé l'archive, on a copié les fichiers extraits dans le répertoire racine du sous-domaine _mysql_, puis on a créé le répertoire _config_ qui va nous servir à paramétrer phpMyAdmin.
Enfin, on a attribué les bons droits à l'ensemble de l'arborescence.
Notice : ```text
chown -R www-data:www-data <fichier ou répertoire>
````
Pour le moment, notre serveur n'est pas accessible depuis l'extérieur, nous nous occuperons donc de la configuration de phpMyAdmin plus tard.
En attendant, créons notre dernier hôte virtuel.
## Domaine mail
Revenons dans le répertoire de configuration des hôtes virtuels :
```bash
cd /etc/apache2/sites-available
````
Et créons la nouvelle arborescence :
```bash
mkdir -p /var/www/exemple.fr/mail/{www,log}
```
Nous allons combiner tout ce que nous avons vu jusqu'à présent pour créer le fichier de configuration de cet hôte virtuel :
```bash
nano mail.exemple.fr
```
```text
<VirtualHost *:80>
ServerName mail.exemple.fr
Redirect / https://mail.exemple.fr/
</VirtualHost>
<VirtualHost *:443>
ServerName mail.exemple.fr
DocumentRoot /var/www/exemple.fr/mail/www
SSLEngine On
SSLCertificateFile /scripts/certificate_authority/apache/mail.exemple.fr.crt
SSLCertificateKeyFile /scripts/certificate_authority/apache/mail.exemple.fr.key
CustomLog /var/www/exemple.fr/mail/log/access_log
ErrorLog /var/www/exemple.fr/mail/log/error_log
</VirtualHost>
```
On créé notre couple clé/certificat :
```bash
/scripts/certificate_authority/make_request apache mail.exemple.fr
/scripts/certificate_authority/sign_request apache mail.exemple.fr
chown www-data:www-data /scripts/certificate_authority/apache/*
```
Warning : _Common Name_
Pour la consultation des mails, on va faire appel à l'excellent [RoundCube](https://web.archive.org/web/20120617154444/http://roundcube.net/), actuellement en version 0.7.1.
```bash
cd /usr/src
wget http://freefr.dl.sourceforge.net/project/roundcubemail/roundcubemail/0.7.1/roundcubemail-0.7.1.tar.gz
tar zxf roundcubemail-0.7.1.tar.gz
cp -Rv roundcubemail-0.7.1/* /var/www/exemple.fr/mail/www/
cp roundcubemail-0.7.1/.htaccess /var/www/exemple.fr/mail/www/
chown -R www-data:www-data /var/www/exemple.fr/mail/www/
```
La configuration de RoundCube peut se faire depuis Internet, mais encore une fois, notre serveur n'est pas encore accessible depuis l'extérieur.
On va donc patienter encore un peu.
On active maintenant nos hôtes virtuels fraîchement créés :
```bash
ln -s /etc/apache2/sites-available/www.exemple.fr /etc/apache2/sites-available/default
a2ensite default
a2ensite www.exemple.fr
a2ensite static.exemple.fr
a2ensite mysql.exemple.fr
a2ensite mail.exemple.fr
/etc/init.d/apache2 start
```
Important : _default_
*www.exemple.fr*
*www.exemple.fr*
Consultez les journaux des différents hôtes (en particulier les journaux d'erreurs) pour vous assurer que tout fonctionne bien du côté d'apache.
## DNS
On édite le fichier de configuration de notre domaine :
```bash
nano /etc/bind/db.exemple.fr
```
A la fin du fichier, rajoutez les lignes suivantes :
```text
www IN CNAME ns
* IN CNAME ns
```
Ces deux lignes définissent un alias (_CNAME_) du domaine _www_ et de tout autre sous-domaine vers l'adresse IP attribuée au sous-domaine _ns_.
Dans notre cas, tous ces sous-domaines pointent vers l'adresse principale de notre serveur (1.1.1.1, pour réutiliser l'exemple de départ).
On redémarre bind :
```bash
/etc/init.d/bind9 restart
```
## Firewall
```bash
nano /scripts/firewall
```
Entre les lignes :
```text
##### Configuration personnalisée #####
```
Et :
```text
##### Fin : Configuration personnalisée #####
```
Rajoutez les lignes suivantes :
```text
${IPT} -A SERVICES -p tcp --dport 80 -j ACCEPT
${IPT} -A SERVICES -p tcp --dport 443 -j ACCEPT
```
## Configuration de phpMyAdmin
Rendez-vous à l'adresse `http://mysql.exemple.fr/setup/` et laissez-vous guider.
Une fois que vous avez modifié votre configuration, déplacez le fichier à la racine :
```text
mv /var/www/exemple.fr/mysql/www/config/config.inc.php /var/www/exemple.fr/mysql/www/
chown www-data:www-data /var/www/exemple.fr/mysql/www/config.inc.php
```
Je vous recommande la lecture de [cette page](https://web.archive.org/web/20120617154444/http://www.phpmyadmin.net/documentation/Documentation.html#config) qui va vous permettre de paramétrer phpMyAdmin beaucoup plus finement que ce que permet l'interface web.
Une fois terminé, supprimez le répertoire _config_ :
```text
rm -r /var/www/exemple.fr/mysql/www/config/
```
## Configuration de RoundCube
Maintenant que phpMyAdmin est installé, il vous sera plus simple de créer l'utilisateur et la base de données pour RoundCube.
Ouvrez donc phpMyAdmin (`http://mysql.exemple.fr`), et cliquez sur l'onglet " _Utilisateurs_ ", puis sur le lien " _Ajouter un utilisateur_ " en bas de page.
Donnez-lui le nom de _RoundCube_, pour le client _localhost_, et générez un mot de passe.
Cochez également la case " _Créer une base de données portant son nom et donner à cet utilisateur tous les privilèges sur cette base_ ".
Rendez-vous ensuite à l'adresse `https://mail.exemple.fr/installer/`.
Sur la première page, vous verrez la liste des dépendances de RoundCube.
S'il en manque l'une ou l'autre, installez-la (via _apt-get install <paquet>_ ou _pear install <paquet>_ si la première méthode ne donne rien) et redémarrez apache.
Une fois que tout est bon, cliquez en bas sur _Next_.
Petit exercice : remplissez les différents champs en prenant en considération que :
- Le port SMTP est le 465 (via tls, pas ssl)
- Le port IMAP est le 993 (via ssl, pas tls)
- L'adresse du serveur est 127.0.0.1
## Touches finales
Une fois RoundCube correctement configuré, créez-vous votre propre adresse email via phpMyAdmin, dans la base de données _MailServer_, et dans la table _users_.
Pensez à sélectionner le type _MD5_ lorsque vous saisirez votre mot de passe.
Par la même occasion, allez dans la table _aliases_, et créez deux enregistrements, dont le champ _source_ sera respectivement _root_ et _postmaster_, et _destination_ l'adresse email que vous venez de vous créer.
Cela vous permettra de recevoir les mails administratifs envoyés automatiquement par les différents services de votre serveur.
[Nous avions précédemment configuré une liste blanche d'expéditeurs](https://web.archive.org/web/20120617154444/http://ingnu.fr/2012/02/05/installer-et-configurer-un-serveur-dns/), toujours autorisés à vous envoyer des mails.
Cette liste correspond à la table _access_sender_ de la base de données _MailServer_.
Nous allons nous servir de RoundCube pour peupler automatiquement cette table, dès que vous enverrez un message.
Éditez la configuration de RoundCube :
```text
nano /var/www/exemple.fr/mail/www/config/main.inc.php
```
Cherchez le terme " _plugins_ " (via la combinaison de touches Ctrl+w).
Complétez la liste présente, en rajoutant :
```text
"automatic_addressbook"
```
Modifiez ensuite le plugin en question :
```text
nano /var/www/exemple.fr/mail/www/plugins/automatic_addressbook/automatic_addressbook.php
```
Aux alentours de la ligne 110, cherchez le code suivant :
```php
foreach($all_recipients as $recipient) {
// Bcc and Cc can be empty
if ($recipient['mailto'] != '') {
$contact = array(
'email' => $recipient['mailto'],
'name' => $recipient['name']
);
```
Rajoutez après :
```php
$con = mysql_connect("localhost", "MailServer", "MotDePasse");
mysql_select_db("MailServer");
mysql_query("insert into access_sender (`source`,`access`) values ('" . $contact["email"] . "','OK')");
mysql_close($con);
```
Pensez à modifier le mot de passe (il s'agit de celui de l'utilisateur _MailServer_).
Enregistrez et fermez.
Désormais, dès que vous écrirez à quelqu'un, son adresse sera automatiquement ajoutée à la liste blanche.
Si vous le souhaitez, vous pouvez également éditer directement cette liste, en modifiant le contenu de la table _access_sender_.
| source | Adresse email à mettre en liste blanche (toujours autorisée à nous contacter, même si son client mail ne respecte pas les standards |
| ------ | ----------------------------------------------------------------------------------------------------------------------------------- |
| access | OK pour autoriser, NULL pour bloquer |
| active | 1 pour activer, 0 pour désactiver |
Vous avez maintenant à votre disposition les fondements les plus importants pour la mise en place de votre cloud.
Votre serveur est sécurisé via un script iptables restrictif, vous disposez d'un serveur de noms de domaine, d'un serveur de base de données, d'un serveur mail, et d'un serveur HTTP(S).
Enfin, vous disposez d'une interface pour gérer facilement votre base de données, et d'un client mail agréable à utiliser.
Dans les prochains articles, nous verrons (dans le désordre) :
- Comment installer une alternative à facebook/twitter/Google+
- Comment installer une alternative à twitpic
- Comment installer une alternative à Google Calendar
- Comment installer une alternative à flickr/Picasa
- Comment stocker des fichiers sur votre serveur comme si celui-ci était sur votre réseau local
- Comment partager des fichiers avec le monde entier
- Comment sauvegarder et restaurer votre serveur

333
content/interets/informatique/2012/02/07/kronolith-une-alternative-a-google-calendar/index.md Normal file
View File

@@ -0,0 +1,333 @@
---
comments_url: https://com.richard-dern.fr/post/518
date: '2012-02-07 21:17:00'
dossier:
- Créer son propre Cloud
links:
- lang: fr
name: Page d'origine sur Archive.org
url: https://web.archive.org/web/20121007072220/http://ingnu.fr/2012/02/07/kronolith-une-alternative-a-google-calendar/
tags:
- Google Calendar
- Horde
- Kronolith
title: 'Kronolith : une alternative à Google Calendar'
weather:
humidity: 64
illuminance: 0.0
precipitations: false
pressure: 1029.2
source:
- open-meteo
temperature: -9.8
wind_direction: 57
wind_speed: 16.4
weight: 6
---
Maintenant que nous avons [installé les bases d'un auto-hébergement](https://web.archive.org/web/20121007072220/http://ingnu.fr/category/creer-son-propre-cloud/), il est temps de mettre en place les [alternatives](https://web.archive.org/web/20121007072220/http://ingnu.fr/2011/12/29/quelles-sont-les-alternatives-a-google/) à tous ces services qui nous traquent, analysent, et revendent nos informations.
En premier lieu, on va s'occuper de Google Calendar.
Notre objectif va être de s'en affranchir, en installant une solution relativement méconnue, injustement boudée au profit d'autres applications plus médiatisées.
Certes, l'installation et la configuration du framework [Horde](https://web.archive.org/web/20121007072220/http://www.horde.org/) et de ses "applications-filles" n'est pas réellement aussi simple qu'un assistant d'installation dans une page web, mais une fois installé, vous vous rendrez compte de sa toute puissance.
Précisons que Horde est un framework, sur lequel reposent bon nombre d'applications.
La plus connue est probablement IMP, dont free fait usage, entre autres, pour permettre aux bénéficiaires d'une adresse @free.fr d'accéder à leurs mails.
Ici, nous reposerons sur ce framework pour installer Kronolith, redoutable de puissance et d'interopérabilité.
## Hôte virtuel
Créons notre hôte virtuel :
```bash
nano /etc/apache2/sites-available/agenda.exemple.fr
```
```text
<VirtualHost *:80>
ServerName agenda.exemple.fr
Redirect / https://agenda.exemple.fr/
</VirtualHost>
<VirtualHost *:443>
ServerName agenda.exemple.fr
DocumentRoot /var/www/exemple.fr/agenda/www
SSLEngine On
SSLCertificateFile /scripts/certificate_authority/apache/agenda.exemple.fr.crt
SSLCertificateKeyFile /scripts/certificate_authority/apache/agenda.exemple.fr.key
CustomLog /var/www/exemple.fr/agenda/log/access.log
ErrorLog /var/www/exemple.fr/agenda/log/error.log
</VirtualHost>
```
Nous avons créé un hôte virtuel non sécurisé redirigeant vers un hôte virtuel sécurisé, nous avons déjà vu le principe.
Créons maintenant les certificats :
```bash
/scripts/certificate_authority/make_request apache agenda.exemple.fr
/scripts/certificate_authority/sign_request apache agenda.exemple.fr
chown www-data:www-data /scripts/certificate_authority/apache/*
```
Warning : _Common Name_
On active le site, et on redémarre apache :
```bash
a2ensite agenda.exemple.fr
/etc/init.d/apache2 restart
```
## Horde
Créons l'arborescence de notre nouveau site :
```bash
mkdir -p /var/www/exemple.fr/agenda/{www,log}
```
Horde est intimement lié aux bibliothèques [PEAR](https://web.archive.org/web/20121007072220/http://pear.php.net/), et c'est une excellente chose : ces bibliothèques de code PHP sont très pointues, largement utilisées, et sont soutenues et maintenues par une large communauté d'utilisateurs.
Quand je dis que Horde est intimement lié à PEAR, c'est aussi parce que Horde dispose de son propre canal sur PEAR.
Cela va nous permettre deux types d'installation :
- Une installation globale
- Une installation locale
Dans le cas d'une installation globale, l'ensemble des bibliothèques et dépendances de Horde sera installé au niveau du système.
Dans une installation locale, Horde fera appel aux bibliothèques installées spécifiquement pour chaque installation.
Dans notre cas, nous procéderons à une installation globale, parce que pour l'heure, nous n'aurons pas d'autre usage de Horde que Kronolith.
Nous verrons plus tard comment basculer sur une installation locale.
```bash
cd /var/www/exemple.fr/agenda/www
```
On met à jour PEAR :
```bash
pear upgrade PEAR
```
On ajoute le dépôt (canal) de Horde :
```bash
pear channel-discover pear.horde.org
```
Et on définit le répertoire d'installation de Horde :
```bash
pear install horde/horde_role
pear run-scripts horde/horde_role
```
Quand le script d'installation vous demandera où installer Horde, répondez :
```text
./
```
Puis on procède finalement au téléchargement des paquets et leur décompression à l'endroit spécifié :
```bash
pear install -a -B horde/horde
```
Une fois terminé, on créé le fichier de configuration initial :
```bash
cp config/conf.php.dist config/conf.php
```
On attribue les bons droits à l'installation :
```bash
chown -R www-data:www-data ./
```
Rendez-vous maintenant dans votre navigateur pour terminer l'installation.
Tout d'abord, créons un nouvel utilisateur dans MySQL, [comme indiqué précédemment](https://web.archive.org/web/20121007072220/http://ingnu.fr/2012/02/07/installation-dun-serveur-http-https/).
Nommez-le _Agenda_, par exemple, et générez un mot de passe.
Mettez toujours "_localhost_" quand phpMyAdmin vous demande l'hôte lors de la création d'un utilisateur, parce que nous n'allons pas ouvrir notre serveur MySQL sur l'extérieur.
Enfin, pensez à cocher la case correspondante à la création d'une base de données portant le nom de cet utilisateur.
Munissez-vous du nom d'utilisateur (_Agenda_) et du mot de passe que vous avez choisi, puis allez sur la page principale de Horde (`http://agenda.exemple.fr`).
Si vous n'êtes pas redirigé automatiquement, allez dans le menu de gauche, _Administration_ > _Configuration_, puis cliquez sur _Horde_.
Avant de configurer quoique ce soit d'autre, allez sur l'onglet "_Database_", et remplissez les champs comme suit :
Et enregistrez.
Parcourez ensuite tous les onglets de configuration, avec pour objectif bien sûr de personnaliser comme vous le souhaitez votre installation, mais surtout choisir comme pilote "_SQL Database_" dans tous les onglets où c'est possible (c'est à dire _Preference System_, _Alarm System_, _DataTree System_, _Groups_, _Permissions_, _Lock System_, _Token System_ et _Virtual File Storage_ - les autres onglets peuvent également demander un pilote de stockage mais on ne le configurera pas).
Warning : _Authentication_
Une fois vos préférences choisies, cliquez sur le bouton "_Générer la configuration de Horde_".
Vous devriez ensuite revenir sur la page principale de l'administration.
Horde va afficher des messages d'erreurs relatifs à la base de données, en vous fournissant plusieurs boutons pour remédier au problème.
Il vous suffit de cliquez dessus pour successivement créer la structure de la base de données, puis la peupler avec les données de base.
Vous n'avez rien d'autre à faire que cliquer sur ces deux boutons pour que tout se mette en place tout seul !
On peut maintenant s'occuper de la question de l'authentification.
Warning : maintenant
```text
cp /var/www/exemple.fr/agenda/www/config/conf.php /var/www/exemple.fr/agenda/ww/config/conf.php-orig
```
Retournez dans _Administration_ > _Configuration_ > _Horde_, onglet "_Authentication_".
Choisissez "_SQL Authentication_" dans le menu _$conf[auth][driver]_.
Laissez "_Horde defaults_" dans le menu qui apparaitra alors.
Warning : _$conf[auth][admins]_
Vous allez créer votre propre compte utilisateur pour pouvoir vous servir de Kronolith.
Actuellement, Horde vous a "auto-identifié" en tant qu'_Administrator_, donc sans mot de passe.
En passant par le pilote SQL pour l'authentification, on est dans l'obligation de créer un nouveau compte, faute de quoi vous ne pourrez jamais vous connecter à Horde...
Donc indiquez le nom d'utilisateur que vous allez créer dans la zone de texte _$conf[auth][admin]_ en haut de la page, et cliquez sur le bouton pour générer la configuration de Horde.
Allez ensuite immédiatement dans _Administration_ > _Utilisateurs_, et créez ce fameux nouveau compte.
Une fois fait, vous pouvez vous déconnecter, puis vous reconnecter avec ce nouveau compte, sans perdre votre statut d'administrateur.
Important : _Administrator_
```text
cp /var/www/exemple.fr/agenda/www/config/conf.php-orig /var/www/exemple.fr/agenda/www/conf.php
```
Une fois que vous êtes connecté avec votre nouveau compte utilisateur, on peut passer à l'installation de Kronolith.
## Kronolith
Si vous n'y êtes pas, retournez dans la racine du site :
```bash
cd /var/ww/exemple.fr/agenda/www
```
L'installation de Kronolith est on ne peut plus simple :
```bash
pear install -a -B horde/kronolith
chown -R www-data:www-data ./
```
Il vous suffit alors d'aller sur la page d'administration de Horde : _Administration_ > _Configuration_, pour mettre à jour les tables correspondantes à Kronolith.
Vérifiez ensuite la configuration de Kronolith (_Administration_ > _Configuration_ > _Kronolith_), puis enregistrez-la.
Kronolith est prêt.
## Configuration et personnalisation
En l'état, tout fonctionne, mais rien n'est personnalisé.
Il me sera impossible de détailler chaque option de configuration tant il y en a.
Mais la grande force de Horde, c'est que ça marche "out-of-the-box".
Après, farfouiller dans les options, c'est plus pour peaufiner, et se créer un fichier de configuration aux oignons.
Cependant, je vous donne tout de même quelques pistes.
Pour commencer, nous avons installé Horde et Kronolith pour servir de calendrier partagé.
Horde vous laisse le choix de l'application à ouvrir au démarrage.
Allez dans _Préférences_ > _Préférences globales_ > _Afficher les préférences_.
Là, le premier menu vous permet de choisir l'application à présenter après la connexion.
Choisissez "_Agenda_".
Ensuite, sachez qu'il est possible d'afficher des agendas distants, dans de nombreux formats.
Vous le verrez en allant dans Organisation > Agenda.
Vous pouvez créer autant d'agenda que vous voulez, et surtout, vous pouvez les partager.
Si vous envisagez de créer plusieurs utilisateurs, chacun aura la possibilité de choisir avec qui il veut partager l'un ou l'autre de ses agendas.
Sachez aussi que vous pouvez importer un agenda iCal existant, autrement dit, rien ne vous empêche de récupérer vos calendriers Google actuels pour les importer dans Kronolith.
Pour aller plus loin avec les évènements, Horde est capable de gérer bien des webservices.
Leur configuration se trouve (vous l'aurez sans doute remarqué) sur la page principale de la configuration de Horde.
## Plusieurs instances de Horde
Nous avons suivi la procédure pour installer une unique instance globale de Horde : il vous sera impossible de créer un nouvel hôte virtuel, et y installer Horde de la même façon.
Si vous avez suivi cette procédure et que finalement vous décidez que vous avez besoin d'avoir plusieurs instances de Horde, vous devrez supprimer l'instance actuelle.
Pour supprimer Horde, utilisez la commande suivante :
```bash
pear uninstall `pear list -c horde | tail -n +4 | awk '{ print "horde/"$1 }'`
```
Placez-vous à la racine du domaine agenda :
```bash
cd /var/www/exemple.fr/agenda
```
Exécutez ensuite les commandes suivantes pour installer les bibliothèques :
```bash
pear config-create /var/www/exemple.fr/agenda/ /var/www/exemple.fr/agenda/pear.conf
pear -c /var/www/exemple.fr/agenda/pear.conf install pear
```
Installez ensuite Horde, depuis la nouvelle instance de PEAR :
```bash
/var/www/exemple.fr/agenda/pear/pear -c /var/www/exemple.fr/agenda/pear.conf channel-discover pear.horde.org
```
Puis :
```bash
/var/www/exemple.fr/agenda/pear/pear -c /var/www/exemple.fr/agenda/pear.conf install horde/horde_role
/var/www/exemple.fr/agenda/pear/pear -c /var/www/exemple.fr/agenda/pear.conf run-scripts horde/horde_role
```
Cette fois, quand le script vous demandera où installer Horde, spécifiez le chemin de fichier complet :
```text
/var/www/exemple.fr/agenda/www
```
Il reste encore à informer apache de l'emplacement des bibliothèques.
Créez ou modifiez le fichier.htaccess du site :
```bash
nano /var/www/exemple.fr/agenda/www/.htaccess
```
```text
php_value include_path /var/www/exemple.fr/pear/php
SetEnv PHP_PEAR_SYSCONF_DIR /var/www/exemple.fr/agenda
```
## Une seule instance de Horde, plusieurs applications
Vous pouvez bien entendu utiliser IMP à la place de [RoundCube](https://web.archive.org/web/20121007072220/http://ingnu.fr/2012/02/07/installation-dun-serveur-http-https/) pour consulter vos messages, et accéder à Kronolith depuis la même instance de Horde, tout en gérant un wiki intégré, etc.
Le nombre et la qualité des applications écrites avec Horde est sans pareil, et sont toutes intégrées les unes aux autres.
Vous pourriez donc avoir envie d'utiliser Horde et pas seulement avec Kronolith.
Dans ce cas, la seule chose à changer dans notre procédure sera de trouver un nom de domaine plus adéquat que "_agenda.exemple.fr_" !
Après, la méthode d'installation et les commandes sont pratiquement les mêmes, quelle que soit l'application à installer.
Juste pour vous donner envie, sachez que parmi les applications intégrées à Horde, vous trouverez :
- IMP, le client de messagerie
- Kronolith, l'agenda partagé
- Nag, le gestionnaire de tâches
- Mnemo, le gestionnaire de notes
- Turba, le gestionnaire de contacts (lui aussi très impressionnant par son interopérabilité)
- Ingo, le gestionnaire de filtres (capable de gérer du procmail, du sieve, du maildrop, etc.)
- Gollem, le gestionnaire de fichiers (capable de se connecter à un partage samba ou nfs distant, en ssh, en FTP, etc.)
- Ansel, la galerie photos
- etc. etc.
Si vous avez suivi la première partie de ce tutoriel, pour installer Horde avec Kronolith dans une instance globale, je suis persuadé que vous allez mourir d'envie d'essayer les autres applications.
Et vous aurez bien raison : Horde est tout simplement la meilleure application web au monde (remarque tout à fait personnelle...)

3
content/interets/informatique/2012/02/07/si-jetais-president/data/images/cover.yaml Normal file
View File

@@ -0,0 +1,3 @@
description: "Couverture originale créée localement pour accompagner la republication de l'article Si j'étais président."
attribution: "Codex"
prompt: "Illustration abstraite éditoriale pour un billet d'opinion informatique, avec panneaux, lignes structurelles et ambiance rétro-web 2012, sans texte, sans logo."

BIN
content/interets/informatique/2012/02/07/si-jetais-president/images/cover.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 88 KiB

52
content/interets/informatique/2012/02/07/si-jetais-president/index.md Normal file
View File

@@ -0,0 +1,52 @@
---
comments_url: https://com.richard-dern.fr/post/517
cover: images/cover.png
date: '2012-02-07 03:34:00'
links:
- lang: fr
name: Page d'origine sur Archive.org
url: https://web.archive.org/web/20120221062015/http://ingnu.fr/2012/02/07/si-jetais-president/
title: Si j'étais président
weather:
humidity: 55
illuminance: 0.0
precipitations: false
pressure: 1028.7
source:
- open-meteo
temperature: -12.4
wind_direction: 45
wind_speed: 10.2
---
Fort de ma nouvelle autorité, je commencerai par montrer au peuple français mon réalisme. Il est impossible de s'imaginer les problèmes du peuple sans soi-même faire partie du peuple. Or, le peuple ne se vautre pas dans la luxure. Le salaire français moyen est légèrement supérieur à 1000€. Comment peut-on comprendre son peuple quand soi-même on gagne près de 20 fois plus? Comment peut-on savoir si toutes les taxes qu'on impose à un pays peuvent être déboursées par ses citoyens?
Ma première action consiste à réduire significativement mon salaire de "dirigeant "du peuple français. Un salaire de 20 000€ mensuels n'est qu'une apparence, un artifice. Cela ne sert qu'à montrer le pouvoir qu'on a sur son peuple. Je déciderai donc de porter mon salaire à 1000€ nets mensuels. Après tout, un "Président "de la république dispose manifestement de bon nombre d'autres avantages. Inutile de gagner plus.
Ma seconde action va être de changer la terminologie du chef du gouvernement. "Président "me semble être doté d'une connotation négative, inspirant la supériorité, l'assise d'un pouvoir sur le peuple. En tant que nouveau chef d'État, je me considère comme le guide du peuple français. Sans majuscule. Parce que si je suis à la tête des français aujourd'hui, c'est pour les guider vers des jours meilleurs.
Ma troisième action va consister à supprimer tous les élus, tous les représentants du peuple. Je supprime les maires, les députés, les sénateurs. Je veux redonner le pouvoir aux français. Je veux que les français participent à nouveau activement à la vie politique du pays. Je crois que si les bureaux de votes se vident, c'est d'une part à cause du nombre d'intermédiaires trop élevé, et d'autre part parce qu'ils ont le sentiment de ne pas être écoutés, que le gouvernement fait de toute manière ce qu'il a décidé, peu importe ce que dit le peuple.
Je veux instaurer une vraie démocratie. LA vraie démocratie. Je veux rendre impossible l'adoption d'une loi, d'un traité, ou d'un décret, sans le consentement du peuple français. Pour y parvenir, je mettrais en place une plateforme permettant à tout un chacun de consulter librement toute proposition qui sera faite, et d'y donner son avis. La proposition ne sera adoptée qu'en cas de majorité absolue. C'est ainsi, et seulement de cette manière, qu'un gouvernement peut être qualifié de démocratique. Pas en permettant à des intermédiaires de répondre du peuple, qui les ont choisi en fonction de campagnes coûteuses, et menées dans l'unique but de se vendre. Je suis persuadé que redonner son pouvoir à la voix des français sera une motivation suffisante pour que le vote redevienne un acte de pure volonté.
La réduction du salaire du chef de l'État, la suppression de ces intermédiaires, la récupération puis la revente des biens appartenant à l'État prêtés aux intermédiaires et jugés somptuaires, permettra de réaliser des économies substantielles. Et pour une fois, pas en saignant les français.
Ma quatrième action sera l'arrêt pur et simple de la coopération avec toute entreprise ou organisme dont les méthodes ou les convictions vont à l'encontre de la liberté de l'individu, qu'il soit français ou résident de pays étranger. Il est intolérable que notre ancien gouvernement ait pu tisser des liens avec des entreprises fournissant des solutions informatiques à des chefs d'États leur permettant d'espionner leur peuple.
Par extension, je supprime tout organisme étatique voué à la seule sécurité du gouvernement au mépris de son peuple. Je récupère une France scindée en deux: le peuple se sent aujourd'hui oppressé, menacé par ses dirigeants, alors que le rôle de tout gouvernement est de protéger son peuple, et il en a toujours été ainsi. Nous vivons des jours sombres, où les peuples n'ont plus aucune estime de leur chef d'État; pire encore, ils le craignent. Tous ne s'avouent pas dictateur, et pourtant, tous sont manipulés par la possession et la richesse.
Je supprime donc la Hadopi, et tous ses employés. Je supprime tout lien avec la société Amesys, et avec toutes les autres entreprises avec lesquelles notre ancien gouvernement a pu être en relation, et dont les activités sont en désaccord avec les droits fondamentaux de l'Homme.
Je supprime également toutes les taxes injustifiées, illégales, immorales, et inutiles. Après tout, les économies réalisées sur la suppression des intermédiaires et la forte réduction de mon salaire et de mes avantages ne peuvent que conduire à une réduction du poids fiscal sur le peuple français. Comment notre ancien gouvernement a-t-il pu se rincer sur le dos de son peuple? Comment peut-on faire preuve d'aussi peu de respect envers le peuple qui l'a choisi?
Parmi les taxes dont je parle, j'évoque notamment les taxes sur les carburants, sur les produits de grande consommation, mais aussi la taxe sur la copie privée, absolument inutile et injustifiée. De quel droit l'État taxe-t-il un produit sur lequel il n'a aucun pouvoir décisionnel? Est-ce que le gouvernement participe à la fabrication du lait? À celle de l'essence? Pourquoi l'État devrait encore toucher presque 50% du prix de vente du pétrole, alors qu'il ne l'extrait pas, ni ne le raffine, ni ne le transporte? De quel droit l'État s'arroge-t-il presque 50% du salaire de ses citoyens, répartis entre impôts, taxes, cotisations obligatoires, etc.? Jusqu'aujourd'hui, qu'a exactement fait l'État pour mériter une telle somme?
Je compte mettre en place une forme de méritocratie. Le rôle du gouvernement est de protéger son peuple. Pas seulement en cas de guerre, mais aussi quand d'autres gouvernements s'attaquent à son intégrité. Et par intégrité, j'entends liberté individuelle. La liberté de vivre, de s'exprimer, de s'indigner, d'être heureux, insouciant, concerné. La liberté d'écrire, de composer, de développer. La liberté d'accéder à toute forme de culture ou de science.
Car c'est en partageant culture et sciences que les civilisations, que LA civilisation humaine a pu se développer, grandir, survivre, jusqu'à conquérir les océans et les étoiles. Notre ancien gouvernement a tout tenté pour empêcher le partage libre de la culture et de la science. Notre ancien gouvernement estimait que certaines civilisations valaient mieux que d'autres. Je crois que c'est précisément ce manque de discernement qui a causé la chute des anciennes civilisations, et des plus grandes. Je crois que c'est la soif de pouvoir et de richesses qui a causé leur déclin. Et c'est précisément ce dans quoi tombent les dirigeants de notre époque.
Après tant d'oppression, tant de mal causé aux peuples, tant de viols de leur liberté et de leur intégrité, il ne peut y avoir qu'un avenir radieux, parce que désormais, il ne peut plus y avoir que des dirigeants bons avec leurs peuples. Et c'est ce à quoi je vais m'employer.
Pour y parvenir, je l'ai dis, le peuple français aura la parole sur toute décision politique; les intermédiaires seront supprimés, tout comme les lois, les organismes et les entreprises allant à l'encontre des libertés; la culture et la science seront libres d'accès à tous: tout le monde pourra contribuer au savoir et à la connaissance. Et je me ferai un devoir d'inciter les autres gouvernements à suivre la même voie, et d'insister jusqu'à leur faire entendre raison. Et si ces gouvernements restent intangibles, nous accueillerons ceux qui veulent vivre libres.
Peut-être suis-je utopiste. Peut-être que vous vous dites que jamais je n'y arriverai. Je pense que la liberté des Hommes vaut bien qu'on essaye. Nous avons longtemps critiqué les chefs d'État, sans vraiment proposer d'alternative, ou, quand on le faisait, elles étaient rejetées. Voulez-vous réellement sacrifier un espoir de retrouver notre liberté, simplement parce que la tâche parait trop ardue? En ce qui me concerne, et en tant que guide, j'ai la force de tenter ma chance, parce que je crois encore en l'Homme, et je crois qu'il est encore capable de bonnes choses.

324
content/interets/informatique/2012/02/08/communiquer-via-xmpp/index.md Normal file
View File

@@ -0,0 +1,324 @@
---
comments_url: https://com.richard-dern.fr/post/519
date: '2012-02-08 00:34:00'
dossier:
- Créer son propre Cloud
links:
- lang: fr
name: Page d'origine sur Archive.org
url: https://web.archive.org/web/20120221004509/http://ingnu.fr/2012/02/08/communiquer-via-xmpp/
tags:
- Prosody
- XMPP
title: Communiquer via XMPP
weather:
humidity: 68
illuminance: 0.0
precipitations: false
pressure: 1028.9
source:
- open-meteo
temperature: -10.5
wind_direction: 57
wind_speed: 17.7
weight: 7
---
On utilise le protocole [XMPP](https://web.archive.org/web/20120221004509/http://xmpp.org/) notamment dans des applications de messagerie instantanées, mais son ouverture permet de l'embarquer dans à peu près tout type d'applications, y compris des réseaux sociaux.
Nous allons installer sur notre cloud personnel un serveur XMPP, qui, bien sûr, va nous permettre de communiquer avec le monde entier, mais dont nous nous servirons également à d'autres fins...
Nous exploiterons le serveur [prosody](https://web.archive.org/web/20120221004509/http://prosody.im/), et son serveur [BOSH](https://web.archive.org/web/20120221004509/http://fr.wikipedia.org/wiki/BOSH), qui va nous permettre de faire appel à une application web pour avoir son propre webchat et créer sa propre communauté.
En outre, nous nous en servirons dans un prochain article consacré à un remplaçant pour Google+/facebook/twitter.
Depuis que j'écris [cette série d'articles consacrés au cloud personnel](https://web.archive.org/web/20120221004509/http://ingnu.fr/category/creer-son-propre-cloud/), j'essaye de proposer des guides mettant en place des solutions évolutives.
Notre [serveur mail](https://web.archive.org/web/20120221004509/http://ingnu.fr/2012/02/06/installation-de-son-propre-serveur-mail/) est capable d'accueillir une infinité (virtuelle) de domaines et d'utilisateurs par exemple.
J'appliquerai le même principe à prosody : vous pourrez disposer d'un nombre illimité de comptes sur un nombre illimité de domaines.
L'installation de prosody ne pose aucun problème, à condition de configurer le dépôt :
```bash
echo "deb http://packages.prosody.im/debian stable main" > /etc/apt/sources.list.d/prosody.list
apt-get update
apt-get install prosody-0.9 liblua5.1-0 liblua5.1-dbi0 liblua5.1-expat0 liblua5.1-filesystem0 liblua5.1-sec0 liblua5.1-socket2 lua-zlib lua5.1
```
Nous utiliserons notre base de données MySQL pour stocker les données de prosody.
On va donc devoir créer un utilisateur dédié, que nous nommerons par exemple _XMPP_.
[Procédez comme d'habitude](https://web.archive.org/web/20120221004509/http://ingnu.fr/2012/02/07/installation-dun-serveur-http-https/) (générez le mot de passe, définissez l'hôte comme étant "_localhost_", et créez la base de données portant le même nom).
## Configuration
On va se passer de la configuration par défaut :
```bash
cd /etc/prosody
/etc/init.d/prosody stop
mv prosody.cfg.lua prosody.cfg.lua-orig
rm conf.avail/* conf.d/*
nano prosody.cfg.lua
```
```text
storage = "sql"
sql = {
driver = "MySQL";
database = "XMPP";
host = "localhost";
username = "XMPP";
password = "VotreMotDePasse";
}
admins { "contact@exemple.fr" }
modules_enabled = {
"roster";
"saslauth";
"dialback";
"disco";
"tls";
"private";
"vcard";
"compression";
"legacyauth";
"version";
"uptime";
"time";
"ping";
"pep";
"register";
"privacy";
"posix";
"bosh";
"groups";
"announce";
"watchregistrations";
};
bosh_ports { "http-bind" }
cross_domain_bosh = true
allow_registration = true;
log = {
{ levels = { "error" }; to = "syslog"; };
{ levels = { "error" }; to = "file"; filename = "/var/log/prosody/prosody.err"; };
{ levels = { min = "info" }; to = "file"; filename = "/var/log/prosody/prosody.log"; };
}
pidfile = "/var/run/prosody/prosody.pid"
Include "/etc/prosody/conf.d/*.lua"
```
Quelques remarques :
- La directive _admins_ permet de renseigner prosody des comptes autorisés à accéder aux fonctions d'administrations. Vous devez y mettre l'adresse du compte que vous allez prochainement vous créer. Cette directive permet notamment, grâce au module _watchregistrations_ d'être tenu informé via message instantané de la création de nouveaux comptes, ce qui est utile si vous affectez la valeur _true_ à la directive _allow_registration_. Si vous ne souhaitez pas autoriser les "étrangers"à s'enregistrer sur votre serveur XMPP, supprimez la ligne"_watchregistrations_" et affectez la valeur _false_ à la directive _allow_registration_
- L'installation par défaut n'inclue pas la directive _Include_ à la fin du fichier
Créons ensuite notre premier hôte virtuel :
```text
nano conf.avail/exemple.fr.cfg.lua
```
```text
VirtualHost "exemple.fr"
enabled = true
ssl = {
key = "/scripts/certificate_authority/prosody/exemple.fr.key";
certificate = "/scripts/certificate_authority/prosody/exemple.fr.crt";
}
Component "conference.exemple.fr" "muc"
```
Vu que nous définissons une clé et un certificat, il faut les créer :
```bash
/scripts/certificate_authority/make_request prosody exemple.fr
/scripts/certificate_authority/sign_request prosody exemple.fr
```
Warning : Lorsque le _Common Name_ vous sera demandé, indiquez le nom de domaine !
Et dans notre cas, acceptez la création d'une clé sans mot de passe !
De la même manière que la commande _a2ensite_ fournie par apache créé un lien symbolique depuis _/etc/apache2/sites-available/_ vers _/etc/apache2/sites-enabled/_ pour l'hôte virtuel concerné, il faut activer les hôtes virtuels dans prosody.
Malheureusement, il n'existe pas de commande du même genre, il faut donc créer ce lien à la main :
```bash
ln -s conf.avail/exemple.fr conf.d/exemple.fr
```
On peut redémarrer prosody :
```bash
/etc/init.d/prosody start
```
Et créer votre premier utilisateur :
```bash
prosodyctl adduser contact@exemple.fr MotDePasse
```
Une fois fait, retournez dans phpMyAdmin pour vérifier que l'utilisateur a été correctement enregistré en base de données.
## Firewall
```bash
nano /scripts/firewall
```
Entre les lignes :
```text
##### Configuration personnalisée #####
```
Et :
```text
##### Fin : Configuration personnalisée #####
```
Rajoutez les lignes suivantes :
```text
${IPT} -A SERVICES -p tcp --dport 5222 -j ACCEPT
${IPT} -A SERVICES -p tcp --dport 5269 -j ACCEPT
```
N'oubliez pas de relancer le script :
```bash
/scripts/firewall
```
## DNS
Éditons le fichier de configuration de notre zone :
```bash
nano /etc/bind/db.exemple.fr
```
Modifiez l'identifiant du fichier de configuration, comme d'habitude, puis ajoutez les lignes suivantes à la fin du fichier :
```text
_xmpp-client._tcp 86400 IN SRV 20 0 5222 exemple.fr.
_xmpp-server._tcp 86400 IN SRV 20 0 5269 exemple.fr.
```
Et redémarrez bind :
```bash
/etc/init.d/bind9 restart
```
Votre serveur est prêt, fonctionnel, et accessible de l'extérieur.
## Installation d'un client XMPP
Il existe une grande variété de clients XMPP, qui s'installent tous très facilement : jetez un oeil à la logithèque de votre distribution préférée pour en trouver.
[Une liste est disponible](https://web.archive.org/web/20120221004509/http://xmpp.org/xmpp-software/clients/) sur le site officiel du protocole XMPP.
Parmi les plus répandus sous GNU/Linux on citera [pidgin](https://web.archive.org/web/20120221004509/http://www.pidgin.im/), [empathy](https://web.archive.org/web/20120221004509/http://live.gnome.org/Empathy), ou encore [kopete](https://web.archive.org/web/20120221004509/http://kopete.kde.org/).
## Installation du webchat
Nous installerons [Jappix](https://web.archive.org/web/20120221004509/https://project.jappix.com/).
Il va nous permettre un certain nombre de choses, et notamment tester le serveur BOSH.
Pour commencer, on va créer un nouveau sous-domaine :
```bash
mkdir-p /var/www/exemple.fr/xmpp/{www,log}
nano /etc/apache2/sites-available/xmpp.exemple.fr
```
```text
<VirtualHost *:80>
ServerName xmpp.exemple.fr.fr
Redirect / https://xmpp.exemple.fr/
</VirtualHost>
<VirtualHost *:443>
ServerName xmpp.exemple.fr
DocumentRoot /var/www/exemple.fr/xmpp/www
SSLEngine On
SSLCertificateFile /scripts/certificate_authority/xmpp.exemple.fr.crt
SSLCertificateKeyFile /scripts/certificate_authority/xmpp.exemple.fr.key
ProxyPass /http-bind/ http://127.0.0.1:5280/http-bind/
ProxyPassReverse /http-bind/ http://127.0.0.1:5280/http-bind/
Header set Access-Control-Allow-Origin "*"
</VirtualHost>
```
Comme d'habitude lors de la création d'un site sécurisé, on créé la paire clé/certificat :
```bash
/scripts/certificate_authority/make_request apache xmpp.exemple.fr
/scripts/certificate_authority/sign_request apache xmpp.exemple.fr
chown www-data:www-data /scripts/certificate_authority/apache/*
```
Warning : Lorsque le _Common Name_ vous sera demandé, indiquez le nom de domaine !
Et dans notre cas, acceptez la création d'une clé sans mot de passe !
```bash
a2ensite xmpp.exemple.fr
/etc/init.d/apache2 restart
```
On télécharge et on installe Jappix :
```bash
cd /usr/src
wget http://codingteam.net/project/jappix/download/file/jappix-spaco-0.9.zip
unzip jappix-spaco-0.9.zip
```
Important : Si vous n'avez pas encore installé le paquet _unzip_ et que vous avez une erreur lors de la décompression de l'archive, installez-le :
```text
apt-get install unzip
```
```bash
cp -Rv jappix/* /var/www/exemple.fr/xmpp/www/
chown -R www-data:www-data
```
Et accédez au site pour le configurer, via `http://xmpp.exemple.fr`.
La première étape va être de créer l'utilisateur administrateur, alors laissez-vous guider par l'assistant.
Vous avez ensuite accès à d'autres options, et particulièrement les hôtes, que vous configurerez comme suit :
| Hôte principal | exemple.fr |
| -------------- | ------------------------------------ |
| Hôte de salons | conference.exemple.fr |
| Hôte pubsub | pubsub.exemple.fr |
| Hôte BOSH | `https://xmpp.exemple.fr/http-bind/` |
Pensez également à configurer la variable "_Salons à rejoindre_"de l'onglet"_Configuration_", en spécifiant le nom d'un salon quelconque, sous la forme *salon@conference.exemple.fr*.
Cochez également les cases relatives au chiffrement et au HTTPS, et la case "_Lien du gestionnaire_".
Enfin, décochez la case "_Verrouiller l'hôte_" si vous souhaitez que des comptes non gérés par votre serveur puissent se connecter.
## Tests
Testez ensuite une première fois la connexion, en cliquant sur le bouton "_Fermer_" tout en haut à droite.
Vous pourrez ensuite revenir à l'interface de configuration depuis le lien "_Gestionnaire_".
Cliquez sur le gros bouton "_Connexion_", indiquez vos identifiants (par exemple, *contact@exemple.fr*) et votre mot de passe.
La connexion devrait être immédiate.
Si ce n'est pas le cas, c'est probablement une question de connexion sécurisée.
Consultez les fichiers journaux de prosody et apache pour tenter de déterminer d'où vient le problème.
Important : Le second test est optionnel : il devrait être effectué si vous permettez à des clients qui n'existent pas sur votre serveur de se connecter.
Si vous avez réussi à vous connecter, nous allons procéder à un second test, visant à vérifier le bon fonctionnement du serveur BOSH pour les clients externes.
Si vous disposez déjà d'un compte XMPP ailleurs que sur votre propre serveur, essayez de vous connecter avec ces identifiants.
Sinon, vous pouvez vous créer rapidement une adresse sur le site [jabber.org](https://web.archive.org/web/20120221004509/http://register.jabber.org/).

700
content/interets/informatique/2012/02/12/une-alternative-a-dropbox/index.md Normal file
View File

@@ -0,0 +1,700 @@
---
comments_url: https://com.richard-dern.fr/post/520
date: '2012-02-12 20:36:00'
dossier:
- Créer son propre Cloud
links:
- lang: fr
name: Page d'origine sur Archive.org
url: https://web.archive.org/web/20120422043827/http://ingnu.fr/2012/02/12/une-alternative-a-dropbox/
tags:
- Apache
- Gollem
- Horde
- Unison
- WebDAV
title: Une alternative à Dropbox
weather:
humidity: 56
illuminance: 0.0
precipitations: false
pressure: 1025.6
source:
- open-meteo
temperature: -7.7
wind_direction: 103
wind_speed: 6.3
weight: 10
---
Stocker des données personnelles après d'un prestataire comme Dropbox (ou dans un autre esprit, MegaUpload) est dangereux, et l'actualité nous l'a clairement montré : la fermeture arbitraire du service entraîne non seulement l'inaccessibilité de vos données, mais en plus, dans le cadre d'une opération anti-piratage, cela peut conduire également à la suppression de ces données, de manière tout aussi arbitraire.
La solution est une fois de plus évidente : héberger chez soi un tel service.
Ce que je vais vous proposer va faire grincer des dents ceux qui espèrent lire un tutoriel sur l'installation de [SparkleShare](https://web.archive.org/web/20120422043827/http://sparkleshare.org/) ou [OwnCloud](https://web.archive.org/web/20120422043827/http://owncloud.org/) (d'autres existent bien sûr).
Je n'en ferai rien.
Mais avant de quitter mon site frustré, laissez-moi juste expliquer mes arguments.
SparkleShare et OwnCloud sont relativement jeunes.
Or, on est censés leur confier des données personnelles, qui, a priori, ne peuvent se permettre d'être corrompues ou insécurisées.
La jeunesse de ces applications fait que, selon moi, elles présentent des risques de sécurité et de fiabilité.
D'autre part, cela nécessite parfois d'installer des dépendances exotiques ou non-libres : SparkleShare requiert mono.
Quant à OwnCloud, son manque de fonctionnalités (dû à sa jeunesse encore une fois) n'en fait pas une solution idéale pour le moment.
Enfin, l'objectif de cette série de tutoriels est aussi de respecter ce qui est probablement le plus célèbre des paradigmes unix : une application pour chaque tâche.
Ce qui veut dire que dans cet article nous verrons comment synchroniser nos documents entre plusieurs machines et proposer un accès générique à ces documents, tandis que dans les prochains articles, nous installerons des applications répondant à des besoins spécifiques, comme la gestion de galeries de photos par exemple.
Ce que je veux, c'est remplir toutes les fonctionnalités attendues d'un tel système, en utilisant uniquement des solutions logicielles éprouvées, standards, ne faisant appel à aucune dépendance exotique supplémentaire qui viendrait ralentir le serveur entier.
En d'autres termes, ma solution convient tout aussi bien aux petits serveurs pas chers qui ne proposent pas une puissance de calcul importante ou un espace disque conséquent, qu'aux serveurs moins modestes capables de faire bien d'autres choses.
Si vous avez tenu jusque là, alors rappelons ce qu'un système tel que Dropbox propose :
- Un espace de stockage accessible depuis n'importe où
- Transferts intelligents pour économiser la bande passante
- Partage de fichiers
- Accès mobile
- Stockage sécurisé
Rien qui ne soit pas accessible à des Logiciels Libres éprouvés !
## Chiffrement
L'intérêt de chiffrer vos données sur le disque de votre serveur peut être sujet à discussion : à quoi bon chiffrer ses données sur le disque du serveur si les communications entre vous-même et votre serveur sont déjà chiffrées ?
D'autant que pour que vous puissiez accéder aux données, il faut qu'elles soient déjà déchiffrées sur le serveur.
Autrement dit, avant que vous vous y connectiez.
C'est notamment le cas lors de l'utilisation d'une partition chiffrée.
Et s'il faut systématiquement ouvrir un shell sur le serveur pour mettre le mot de passe destiné à déchiffrer les données, cela va rapidement devenir pénible, notamment dans le cadre d'un accès depuis un Smartphone.
Le chiffrement des données sur le disque du serveur présente un intérêt dans le cas extrêmement improbable où quelqu'un parviendrait à obtenir un accès shell au serveur.
Si le disque virtuel qu'on a créé n'est pas chiffré, cette personne pourra librement le consulter.
Et si c'est l'État qui saisit votre serveur pour une raison X ou Y, vous êtes dans l'obligation de fournir les moyens nécessaires au déchiffrement du disque.
Et si vous feintez de l'oublier, le cassage du chiffrement ne devrait pas être trop long, compte tenu du fait que la loi vous interdit d'utiliser un encodage sur plus de 1024bits.
Dans tous les cas, le chiffrement au niveau du disque est inutile, encombrant, lourd, et contraignant.
Voilà mon avis personnel sur la question.
Si vous estimez que je me trompe, libre à vous de mettre en place les nombreuses solutions de chiffrement qui s'offrent à vous.
N'oubliez juste pas que [TrueCrypt n'est pas Libre](https://web.archive.org/web/20120422043827/http://www.truecrypt.org/legal/license) (Open Source est un terme trompeur qui ne signifie pas Libre au sens strict entendu par Richard Stallman - et moi).
## Accès aux données
Pour rappel, on n'accèdera pas directement aux fichiers stockés sur le serveur (à l'exception d'un accès par l'interface web).
On stocke les fichiers localement, et on les synchronise avec le serveur.
Cela permet de ne pas ralentir la machine locale qui n'a pas besoin d'attendre d'être connectée au serveur pour travailler avec les fichiers, de travailler sur les données locales même si le serveur est inaccessible et de les synchroniser une fois le serveur de retour en ligne, et d'économiser de la bande passante puisque seules les modifications sont synchronisées.
Pour permettre plus de souplesse, on va stocker les documents des utilisateurs dans leur répertoire personnel, et proposer un répertoire public, accessible plus exactement à tous ceux ayant un compte sur le serveur.
Autrement dit, tout utilisateur qui souhaite avoir ses fichiers sur notre serveur devra avoir un compte Unix local.
Cela nous permettra de conserver, lors des synchronisations, les propriétaires, groupes et permissions appliquées à tout fichier.
## Accès aux données depuis Apache
On va installer [Gollem](https://web.archive.org/web/20120422043827/http://www.horde.org/apps/gollem) pour accéder aux fichiers depuis le navigateur.
Gollem est le gestionnaire de fichiers du framework Horde, que [nous avons déjà vu lors de l'installation de Kronolith](https://web.archive.org/web/20120422043827/http://ingnu.fr/2012/02/07/kronolith-une-alternative-a-google-calendar/).
Si vous avez suivi - comme je l'expliquais - la première partie du tutoriel, vous avez dû installer Horde de manière globale.
Vous savez donc qu'il ne sera pas possible d'installer Gollem de la même manière.
Plusieurs options s'offrent à nous :
- Installer Gollem dans sa propre instance de Horde
- Fusionner l'agenda avec le gestionnaire de fichiers (en renommant par exemple l'hôte agenda.exemple.fr)
- Installer un autre gestionnaire de fichiers (tel que Ajaxplorer et eXtplorer)
Il faut savoir concernant ce dernier point que, à ma connaissance et contrairement à Gollem, les autres gestionnaires de fichiers en ligne ne permettent pas d'avoir recours à des comptes Unix, ce qui est un pré-requis pour conserver les propriétaires, groupes et droits sur les fichiers, pré-requis que nous pourrions remplir en ayant recours à une couche FTP, le gestionnaire de fichiers devenant un simple client FTP pour l'hôte local.
Inutile, puisque nous n'utiliserons pas FTP à l'extérieur du serveur...
Il faut aussi savoir que si vous optez pour la deuxième solution, les personnes ayant accès à l'agenda auront aussi accès aux fichiers et vice-versa.
Nous retiendrons donc la première solution.
Nous allons créer un hôte virtuel sécurisé, comme on a maintenant l'habitude de faire, à la différence que nous allons recourir à l'authentification par certificat en plus du chiffrement.
Cela va vous permettre de contrôler finement l'accès à vos fichiers depuis l'interface web : pour y accéder, il sera obligatoire de disposer d'un certificat client que vous seul pourrez délivrer.
Créons l'arborescence, puis notre hôte virtuel :
```bash
mkdir -p /var/www/exemple.fr/files/{log,www}
nano /etc/apache2/sites-available/files.exemple.fr
```
```text
<VirtualHost *:80>
ServerName files.exemple.fr
Redirect / https://files.exemple.fr/
</VirtualHost>
<VirtualHost *:443>
ServerName files.exemple.fr
DocumentRoot /var/www/exemple.fr/files/www
SSLEngine On
SSLCertificateFile /scripts/certificate_authority/apache/files.exemple.fr.crt
SSLCertificateKeyFile /scripts/certificate_authority/apache/files.exemple.fr.key
CustomLog /var/www/exemple.fr/files/log/access.log
ErrorLog /var/www/exemple.fr/files/log/error.log
php_value include_path /var/www/exemple.fr/files/pear/php
SetEnv PHP_PEAR_SYSCONF_DIR /var/www/exemple.fr/files
</VirtualHost>
```
Nous avons créé un hôte virtuel non sécurisé redirigeant vers un hôte virtuel sécurisé, nous avons déjà vu le principe.
Créons maintenant les certificats :
```bash
/scripts/certificate_authority/make_request apache files.exemple.fr
/scripts/certificate_authority/sign_request apache files.exemple.fr
chown www-data:www-data /scripts/certificate_authority/apache/*
```
Warning : *Common Name*
On active le site, et on redémarre apache :
```bash
a2ensite files.exemple.fr
/etc/init.d/apache2 restart
```
On installe ensuite notre instance de PEAR.
```bash
pear config-create /var/www/exemple.fr/files/ /var/www/exemple.fr/pear.conf
pear -c /var/www/exemple.fr/files/pear.conf install pear
```
On installe Horde :
```bash
/var/www/exemple.fr/files/pear/pear -c /var/www/exemple.fr/files/pear.conf channel-discover pear.horde.org
/var/www/exemple.fr/files/pear/pear -c /var/www/exemple.fr/files/pear.conf install horde/horde_role
/var/www/exemple.fr/files/pear/pear -c /var/www/exemple.fr/files/pear.conf run-scripts horde/horde_role
```
Important : */var/www/exemple.fr/files/www*
```bash
/var/www/exemple.fr/files/pear/pear -c /var/www/exemple.fr/files/pear.conf install -a -B horde/horde
cp /var/www/exemple.fr/files/www/config/conf.php.dist /var/www/exemple.fr/files/www/config/conf.php
chown -R www-data:www-data /var/www/exemple.fr/files
```
Il reste à installer quelques dépendances :
```bash
/var/www/exemple.fr/files/pear/pear -c /var/www/exemple.fr/files/pear.conf install mdb2_driver_mysql
```
Créez ensuite un utilisateur MySQL (reportez-vous à [cet article](https://web.archive.org/web/20120422043827/http://ingnu.fr/2012/02/07/installation-dun-serveur-http-https/) pour le faire via phpMyAdmin) avec sa base de données.
Donnez-lui le nom "*Gollem*" par exemple.
Pour pouvoir utiliser PAM (et donc les comptes Unix locaux), il faut installer le paquet correspondant :
```bash
pecl install pam
```
Et modifier Horde :
```bash
nano /var/www/exemple.fr/files/pear/php/Horde/Auth/Pam.php
```
Changez la ligne 40 :
```php
if (!Horde_Util::extensionExists('pam')) {
```
Pour inclure l'extension *pam_auth* :
```php
if (!Horde_Util::extensionExists('pam') && !Horde_Util::extensionExists('pam_auth')) {
```
Enregistrez.
On doit encore configurer PAM pour être utilisable par Gollem.
Tout d'abord, créons un lien symbolique qui permettra de lier le service PAM de PHP au service PAM de la machine :
```bash
cd /etc/pam.d
ln -s login php
```
Ensuite, il faut que l'utilisateur d'Apache (*www-data*) ait accès au fichier */etc/shadow*.
Simple :
```bash
adduser www-data shadow
```
Puis redémarrez Apache :
```bash
/etc/init.d/apache2 restart
```
Important : */var/log/auth.log*
Configurez ensuite Horde exactement de la même manière que lors de l'installation de Kronolith (là encore, reportez-vous à [cet article](https://web.archive.org/web/20120422043827/http://ingnu.fr/2012/02/07/kronolith-une-alternative-a-google-calendar/)).
Changez seulement les paramètres relatifs à la base de données, et dans l'onglet *Authentification*, affectez la valeur *PAM (Pluggable Authentication Modules) authentication* à la directive de configuration *$conf[auth][driver]*.
Enregistrez, mais ne vous déconnectez pas encore de l'interface d'administration (vous ne pourriez plus y revenir pour le moment).
Installons maintenant Gollem :
```bash
/var/www/exemple.fr/files/pear/pear -c /var/www/exemple.fr/files/pear.conf install -a -B horde/gollem
```
Puis corrigez les droits :
```bash
chown -R www-data:www-data /var/www/exemple.fr/files/
```
Retournez dans Horde, dans *Administration* > *Configuration*, et générez la configuration de Gollem.
Il faut, en revanche, modifier à la main la configuration relative à l'accès aux données.
```bash
cd /var/www/exemple.fr/files/www/gollem/config
mv backends.php backends.php-orig
nano backends.php
```
```php
<?php
$backends['documents'] = array(
'disabled' =--> false,
'name' => 'Documents',
'driver' => 'ssh2',
'hordeauth' => true,
'params' => array(
'hostspec' => 'localhost',
'permissions' => '700'
),
'loginparams' => array(),
'root' => '/home',
'home' => $GLOBALS['registry']->getAuth(),
'attributes' => array(
'type',
'name',
'edit',
'download',
'modified',
'size',
'permission',
'owner',
'group'
)
);
$backends['public'] = array(
'disabled' => false,
'name' => 'Fichiers publics',
'driver' => 'ssh2',
'hordeauth' => true,
'params' => array(
'hostspec' => 'localhost',
'permissions' => '755'
),
'loginparams' => array(),
'root' => '/var/public-docs',
'home' => '/var/public-docs',
'attributes' => array(
'type',
'name',
'edit',
'download',
'modified',
'size',
'permission',
'owner',
'group'
)
);
```
On créé deux backends : une pour les documents personnels, une pour les documents publics.
Il faut donc créer le répertoire qui va bien :
```bash
mkdir /var/public-docs
chmod -R 777 /var/public-docs
```
On attribue tous les droits à ce répertoire pour que n'importe qui puisse y écrire.
Gollem s'occupera de mettre les droits à 755 pour chaque fichiers créé, sachant que Gollem permet à tout utilisateur de modifier les droits sur ses propres fichiers.
Il ne reste plus qu'à tester via l'adresse `http://files.exemple.fr`.
Une fois que tout fonctionne, vous devriez définir un utilisateur Unix qui sera administrateur de Horde.
```bash
nano /var/www/exemple.fr/files/www/config/conf.php
```
Modifiez la ligne :
```php
$conf['auth']['admins'] = array('Administrator');
```
Et mettez à la place de *Administrator* le nom de votre utilisateur unix sur votre serveur.
Ainsi, en vous connectant à Horde, vous aurez accès à l'interface d'administration.
On dispose maintenant d'un espace privé pour chaque utilisateur, d'un espace public commun, et d'un moyen d'y accéder par un navigateur.
Je crois que le plus dur est fait !
## Synchronisation des données
Nous utiliserons [unison](https://web.archive.org/web/20120422043827/http://www.cis.upenn.edu/~bcpierce/unison/) pour synchroniser nos données.
L'avantage procuré par unison est qu'il permet une synchronisation bidirectionnelle, tandis que rsync ne propose qu'une synchronisation unidirectionnelle.
Bien que l'application ne soit plus maintenue, elle reste un élément fondamental de notre système : la synchronisation bidirectionnelle est ce qui va nous permettre d'avoir partout les mêmes fichiers, qu'on les ait modifiés depuis l'interface web, une machine sous GNU/Linux, sous Windows ou sous Mac.
Le fait que l'application ne soit plus maintenue devient du coup un avantage.
Nous utiliserons donc la dernière version stable : la 2.40.63.
Cette version se trouve dans le dépôt *testing* de Debian.
Si vous ne souhaitez pas ajouter ce dépôt à votre configuration (autrement dit, si vous ne voulez pas vous embêter avec l'[apt pinning](https://web.archive.org/web/20120422043827/http://jaqque.sbih.org/kplug/apt-pinning.html)), vous pouvez télécharger le paquet directement depuis [cette page](https://web.archive.org/web/20120422043827/http://packages.debian.org/wheezy/unison).
Si c'est la voie que vous avez choisi, vous utiliserez *dpkg* :
```bash
dpkg -i unison_2.40.63-2_amd64.deb
```
Sinon, *apt-get* :
```bash
apt-get -t testing install unison
```
Sous WIndows et Mac OS, vous trouverez les binaires sur [cette page](https://web.archive.org/web/20120422043827/http://alan.petitepomme.net/unison/index.html).
Pour configurer unison, créons un répertoire qui lui sera dédié dans votre répertoire utilisateur, sur votre propre machine :
```bash
mkdir ~/.unison
```
```text
root = /home/<utilisateur local>/
root = ssh://<utilisateur distant>@exemple.fr//home/<utilisateur distant>/
times = true
auto = true
batch = true
silent = true
```
La première ligne indique la racine des fichiers locaux à copier, ici, votre répertoire utilisateur.
La seconde ligne indique la connexion ssh à utiliser pour synchroniser les fichiers avec le répertoire distant : ici, le *home* de l'utilisateur distant.
Ensuite, nous préservons les dates et heures affectées aux fichiers (*time*), et nous voulons une procédure la plus silencieuse possible.
La première fois que vous exécuterez unison, l'application vous posera des questions relatives à la synchronisation.
Contentez-vous de valider avec la touche Entrée de votre clavier.
Mais avant d'exécuter unison pour la première fois, il faut créer une clé d'accès SSH.
Toujours sur votre propre machine :
```bash
ssh-keygen -t rsa -f ~/.ssh/id_rsa_<nom>
```
Vous remplacerez *<nom>* par une valeur vous permettant de savoir qu'il s'agit de la clé permettant la synchronisation de vos fichiers avec le serveur.
L'idée, c'est de la différencier d'autres clés que vous auriez pu créer avant.
Une fois créée, envoyez-la au serveur :
```bash
ssh-copy-id -i ~/.ssh/id_rsa_<nom> <utilisateur distant>@exemple.fr
```
De même, remplacez les valeurs entre chevrons pour qu'elles correspondent à votre situation.
Dernière étape avant de lancer la première synchronisation, ouvrir le port 22 sur le serveur.
Reprenez notre [script de mise en place du firewall](https://web.archive.org/web/20120422043827/http://ingnu.fr/2012/02/05/creer-son-propre-cloud-introduction/) sur le serveur :
```bash
nano /scripts/firewall
```
Entre les lignes :
```text
##### Configuration personnalisée #####
```
Et :
```text
##### Fin : Configuration personnalisée #####
```
Rajoutez la ligne suivante :
```text
${IPT} -A SERVICES -p tcp --dport 22 -j ACCEPT
```
N'oubliez pas de relancer le script :
```bash
/scripts/firewall
```
Bien qu'en début de script nous spécifions l'adresse IP d'une machine toujours autorisée à se connecter, nous ne prévoyons pas que d'autres machines puissent accéder au port 22 (le port utilisé par SSH).
Vu que, dans le cas de l'utilisation d'un smartphone par exemple, on ne peut pas prévoir l'adresse IP du terminal (parce qu'on peut se connecter depuis une borne wifi inconnue), nous devons ouvrir le port 22 de manière systématique.
Important : [notre série consacrée à la mise en place d'un cloud personnel](https://web.archive.org/web/20120422043827/http://ingnu.fr/category/creer-son-propre-cloud/)
On peut enfin lancer la première synchronisation, qui va se borner à copier vos fichiers locaux sur le serveur distant.
Sur votre machine, lancez simplement :
```bash
unison
```
Et patientez.
Le fichier *default.prf* que nous venons de créer est considéré par unison comme étant un profil.
On peut créer autant de profils que nécessaire.
Par exemple, nous avons créé un espace public sur le serveur, dont nous nous servirons plus tard pour stocker des photos et les gérer avec une galerie.
Nous verrons alors comment configurer unison pour que cette galerie soit synchronisée avec un répertoire local sous un autre profil.
Pour le moment, il nous reste encore à automatiser la synchronisation de nos documents personnels.
## Automatisation
Le problème avec unison (en console sous GNU/Linux), c'est que lors d'une synchronisation, l'application ne vérifie pas si une instance de l'application est déjà en route.
Autrement dit, plusieurs instances de unison peuvent tourner en même temps, ce qui peut poser problème lors de longues copies.
Pour éviter cela, nous allons devoir créer un script qui se charge de cette vérification.
Ce script sera créé sur votre machine avec le super-utilisateur.
En tant que root, créez le script en question :
```bash
mkdir /scripts
nano /scripts/unison-launcher
```
```bash
#!/bin/bash
who=`whoami`
mypid=$$
mydir=`dirname $0`
home="/home/$who"
pidfile="$home/unison.pid"
if [ -f "$pidfile" ]
then
oldpid=`cat "$pidfile"`
oldpidexists=`ps -p $oldpid | grep -v TTY | awk -F " " '{print $1}'`
if [ "$oldpidexists" != "" ]
then
exit
fi
fi
touch "$pidfile"
echo $mypid > "$pidfile"
if [ "$1" == "" ]
then
if [ -f "$home/.unison/default.prf" ]
then
unison default
else
echo "Le profil par défaut est introuvable ($home/.unison/default.prf)"
fi
else
if [ -f "$home/.unison/$1.prf" ]
then
unison $1
else
echo "Le profil $1 est introuvable ($home/.unison/$1.prf)"
fi
fi
rm "$pidfile"
```
Attribuez ensuite les droits d'exécution :
```bash
chmod +x /scripts/unison-launcher
```
Ce script est fait pour permettre la synchronisation de comptes différents sur la même machine.
Il ne reste plus qu'à l'intégrer dans la crontab de chaque utilisateur à synchroniser :
```bash
crontab -e
```
```text
* * * * * /scripts/unison-launcher
```
Vous pouvez passer en argument de ce script le nom d'un profil à charger.
Nous le verrons dans un prochain article.
Notice : *default.prf*
*.unison*
## Vérification
Maintenant que la première synchronisation a été effectuée, rendez-vous dans Gollem pour vérifier (`http://files.exemple.fr`).
Vous devez retrouver tous vos fichiers, avec les bonnes permissions, et appartenant à l'utilisateur sur votre serveur.
Via Gollem, créez un répertoire de test.
Patientez une minute, puis listez les fichiers sur votre propre machine.
Le répertoire en question devrait avoir été créé.
Si tout fonctionne, et que vous disposez d'une autre machine sous GNU/Linux, il vous suffit d'y copier le script */script/unison-launcher* pour synchroniser les utilisateurs de cette machine (après avoir créer les profils par défaut, évidemment).
## Webdav
Webdav va nous permettre de nous synchroniser avec davantage de clients, et notamment les périphériques Android, puisque unison n'existe pas sous Android.
Webdav étant géré par Apache, nous évitons deux écueils : installer une application dédiée (donc faire tourner un service de plus), et ouvrir un port réseau supplémentaire.
Installons tout d'abord quelques dépendances et activons-les :
```bash
apt-get install libapache2-mod-auth-pam
a2enmod auth_pam dav_fs dav
a2dismod userdir
```
Nous devons ensuite modifier un peu la configuration de notre hôte virtuel dans Apache.
```bash
nano /etc/apache2/sites-available/files.exemple.fr
```
Rajoutez les deux lignes suivantes dans la configuration de l'hôte virtuel sécurisé (avant </VirtualHost>) :
```text
Include /etc/apache2/mods-available/userdir.load
Include /etc/apache2/mods-available/userdir.conf
```
Ensuite, on va modifier la configuration du module userdir :
```bash
mv /etc/apache2/mods-available/userdir.conf /etc/apache2/mods-available/userdir.conf-orig
nano /etc/apache2/mods-available/userdir.conf
```
```text
<IfModule mod_userdir.c>
UserDir /home
UserDir disabled root
DAVLockDB /var/lib/apache2/DAVLockDB
<Directory /home/*/>
AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
DAV On
AuthPAM_Enabled On
AuthPAM_FallThrough Off
AuthUserFile /etc/shadow
ForceType text/plain
</Directory>
Alias /public /var/public-docs
<Directory /var/public-docs>
AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
DAV On
AuthPAM_Enabled On
AuthPAM_FallThrough Off
AuthUserFile /etc/shadow
ForceType text/plain
</Directory>
</IfModule>
```
On définit ici que le répertoire utilisateur pour Apache est son home, et on créé un accès au répertoire public.
Afin d'éviter que n'importe qui puisse voir le répertoire d'un autre utilisateur, il faut créer un fichier.htaccess dans chaque répertoire utilisateur.
Ainsi, seul l'utilisateur connecté peut accéder à son propre répertoire.
```bash
nano /home/<utilisateur>/.htaccess
```
```text
AuthPAM_Enabled on
AuthType Basic
AuthName "PAM"
require user <utilisateur>
```
Remplacez *<utilisateur>* par le nom d'utilisateur correspondant au répertoire personnel dans lequel vous mettez ce fichier.
Vous pouvez désormais accéder, via un client dav ou votre navigateur, aux adresses suivantes :
- http://exemple.fr/~utilisateur
- http://exemple.fr/public
## Synchronisation avec un client Android
Maintenant que webdav est en place, on va pouvoir configurer un client sous Android.
Et pour cela, nous allons installer sur le terminal l'application [WebDav File Manager](https://web.archive.org/web/20120422043827/https://market.android.com/details?id=jp.ddo.shigadroid.webdavfilemanager).
Expliquer comment configurer le client sortirait du cadre de cet article déjà bien touffu par ailleurs.
[La page suivante](https://web.archive.org/web/20120422043827/http://shigadroid.web.fc2.com/en/) vous permettra de configurer l'application ainsi que la synchronisation.
Nous verrons, en revanche, dans notre prochain article, comment configurer l'application pour envoyer automatiquement les photos prises avec le terminal vers notre serveur.
## Conclusion
Un tel article mérite bien une conclusion particulière.
Nous avons maintenant mis en place tout ce qu'un service comme Dropbox peut fournir, et peut être même plus encore (nous le verrons dans les prochains articles).
En l'occurrence :
- on peut accéder à nos fichiers depuis un navigateur et via webdav, donc depuis des périphériques nomades
- nos données sont synchronisées donc accessibles depuis n'importe où
- l'accès à nos données se fait seulement via SSH ou SSL, donc les transferts sont sécurisés
- on peut gérer la bande passante allouée à l'accès aux fichiers
- on va pouvoir installer des applications web dédiées à la gestion de certains types de fichiers, de façon plus puissante et plus agréable que tout autre service intégré
- on dispose d'une excellente base pour faire bien d'autres choses avec nos fichiers !
Voilà donc cet article consacré à la mise en place d'une alternative à Dropbox terminé.
Il s'agissait là probablement du plus complexe que nous ayons eu à aborder depuis le début de l'installation de notre cloud personnalisé.
Il est aussi peu probable que les articles suivants soient aussi long et difficiles à intégrer que celui-ci.
Nous avons vu un certain nombre de notions relativement complexes, sans compter les petites modifications à apporter ça et là à des applications existantes ([nous l'avons fait pour status.net](https://web.archive.org/web/20120422043827/http://ingnu.fr/2012/02/08/son-propre-reseau-social-avec-status-net/), nous le faisons ici avec Horde).
Donc, même si vous n'avez pas eu le courage de tout mettre en œuvre, j'espère néanmoins que cet article (et les autres !) vous a intéressé.
Prochainement, nous installerons une application pour partager ses photos, application qui reposera sur le dossier public que nous avons mis en place, et dont la mise à jour sera automatique.
Cerise sur le gâteau : quand vous prendrez une photo depuis votre smartphone, celle-ci sera automatiquement envoyée à la galerie et intégrée, exactement comme avec Google et Picasa, sauf que nous n'aurons recours qu'à des Logiciels Libres !
Ensuite, nous renforcerons la sécurité de notre serveur.
Nous mettrons en place un système de sécurité préventif, autant que défensif.
L'article d'après sera consacré à la sauvegarde et la restauration de notre serveur.
Enfin, je publierai un dernier article, conclusion globale de tout le chapitre sur l'installation d'un cloud personnel.

3
content/interets/informatique/2012/02/13/cest-quoi-le-libre/data/images/cover.yaml Normal file
View File

@@ -0,0 +1,3 @@
description: "Couverture originale créée localement pour accompagner la republication de l'article C'est quoi le Libre ?."
attribution: "Codex"
prompt: "Illustration abstraite éditoriale sur le logiciel libre et l'émancipation numérique, avec symbole d'ouverture, rayons lumineux et ambiance rétro-web 2012, sans texte, sans logo."

BIN
content/interets/informatique/2012/02/13/cest-quoi-le-libre/images/cover.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 105 KiB

41
content/interets/informatique/2012/02/13/cest-quoi-le-libre/index.md Normal file
View File

@@ -0,0 +1,41 @@
---
comments_url: https://com.richard-dern.fr/post/521
cover: images/cover.png
date: '2012-02-13 00:09:00'
links:
- lang: fr
name: Page d'origine sur Archive.org
url: https://web.archive.org/web/20120224015034/http://ingnu.fr/2012/02/13/cest-quoi-le-libre/
tags:
- Libre
- Logiciel
title: C'est quoi le Libre ?
weather:
humidity: 59
illuminance: 0.0
precipitations: false
pressure: 1025.2
source:
- open-meteo
temperature: -8.8
wind_direction: 225
wind_speed: 3.1
---
Je sais qu'il y a beaucoup de sources d'informations pour savoir ce qu'est le Libre ([dont la principale](https://web.archive.org/web/20120224015034/http://www.gnu.org/philosophy/free-sw.html)), mais j'ai toujours constaté avec regret qu'il y a encore beaucoup de gens qui considèrent mal les Libristes, les défenseurs du Libre.
Je les ai vu dire que dans certains domaines, les Logiciels Libres n'arrivent pas à la cheville des logiciels privateurs, sur le plan technique. J'en ai vu dire que les Logiciels Libres n'apportent rien, et ne sont d'aucune utilité face aux logiciels privateurs. J'en ai vu dire que les Logiciels Libres ne sont pas des alternatives viables aux logiciels privateurs, ou aux services web du type Google ou facebook. J'en ai même lu qui disaient que si un auteur de Logiciel Libre voulait insérer dans son code une partie destinée à espionner l'utilisateur, personne ne le verrait.
Alors, j'ai décidé d'essayer autre chose, que dire "les Logiciels Libres c'est mieux, les logiciels privateurs c'est mal".
La plupart des critiques que j'ai lu sont fondées sur l'aspect technique des Logiciels Libres. Or, le fondement même des Logiciels Libres est la liberté justement. Ils n'existent pas simplement pour qu'une alternative à Microsoft Office ou Microsoft Windows existe, ils existent pour apporter la liberté au sein de l'informatique. Ils ont été conçus pour libérer leurs utilisateurs des contraintes arbitrairement et injustement imposées par les éditeurs de logiciels.
C'est à Richard Stallman que l'on doit cette vision du Logiciel Libre. Tout défenseur du Logiciel Libre se doit de connaître et approuver Stallman, tandis que ses détracteurs se doivent de connaître les intentions formulées par Licence Publique Générale.
L'aspect technique des Logiciels Libres est pour ainsi dire secondaire: la priorité est d'accorder des libertés fondamentales aux auteurs et aux utilisateurs de ces logiciels; l'aspect technique ne doit être mis en avant que pour leur valorisation par rapport aux solutions privatrices.
Par exemple, dire que GIMP est une plaisanterie face à Photoshop relève de l'ignorance, puisque cela revient à comparer les deux logiciels sur un plan technique. Or, GIMP n'est pas une réponse technique à Photoshop, c'est une réponse de principe. GIMP existe pour que puisse exister une alternative Libre à Photoshop.
Ce que certains considèrent comme une faiblesse est en réalité une force du Logiciel Libre: puisqu'on veut parler d'aspect technique, la technicité d'un Logiciel Libre est dépendante de sa communauté, forte de plusieurs milliers d'utilisateurs qui sont autant de contributeurs, tandis que la technicité d'un logiciel privateur n'est dépendante que du bon vouloir de l'entreprise qui le publie. Autrement dit, elle n'est motivée que par l'argent.
Ce qui m'amène à poser la question suivante: comment un Libriste peut se considérer comme tel s'il ne voit aucun inconvénient à utiliser une solution privative?

136
content/interets/informatique/2012/02/13/gerer-ses-photos-avec-photoshow/index.md Normal file
View File

@@ -0,0 +1,136 @@
---
comments_url: https://com.richard-dern.fr/post/522
date: '2012-02-13 14:04:00'
dossier:
- Créer son propre Cloud
links:
- lang: fr
name: Page d'origine sur Archive.org
url: https://web.archive.org/web/20120221004519/http://ingnu.fr/2012/02/13/gerer-ses-photos-avec-photoshow/
tags:
- PhotoShow
title: Gérer ses photos avec PhotoShow
weather:
humidity: 63
illuminance: 34842.5
precipitations: false
pressure: 1020.6
source:
- open-meteo
temperature: 0.1
wind_direction: 258
wind_speed: 12.5
weight: 11
---
Maintenant que nous disposons d'[une solution de stockage en ligne](https://web.archive.org/web/20120221004519/http://ingnu.fr/2012/02/12/une-alternative-a-dropbox/), la prochaine étape consistera à mettre en place une application web pour partager ses photos avec le reste du monde.
Bien que de très nombreuses solutions existent, et de très bonne qualité (voir mon article sur [les alternatives à Google](https://web.archive.org/web/20120221004519/http://ingnu.fr/2011/12/29/quelles-sont-les-alternatives-a-google/)), mon choix s'est porté sur une petite application du nom de [PhotoShow](https://web.archive.org/web/20120221004519/http://www.photoshow-gallery.com/).
Je l'ai choisi pour plusieurs raisons.
Tout d'abord, elle ne nécessite aucune base de données.
Ensuite, elle ne nécessite pratiquement aucune maintenance, dans la mesure où les photos sont analysées automatiquement.
Est également automatique la génération des miniatures.
Et malgré sa simplicité, il reste possible de définir tout ou partie de la galerie comme étant privée, dont l'accès sera réservé aux utilisateurs de votre choix, ou simplement protégé par mot de passe.
Enfin, l'arborescence des fichiers n'a pas besoin de se trouver dans l'arborescence du site.
Cela permet d'éviter que n'importe qui (les moteurs de recherche par exemple) puisse aspirer sans vergogne vos photos.
On respecte ainsi une autre prérogative de [ma série d'articles](https://web.archive.org/web/20120221004519/http://ingnu.fr/category/creer-son-propre-cloud/) : préserver la confidentialité de nos données.
## Hôte virtuel
Première chose, comme d'habitude, on s'occupe de l'hôte virtuel dans apache :
```bash
nano /etc/apache2/sites-available/photos.exemple.fr
```
```text
<VirtualHost *:80>
ServerName photos.exemple.fr
Redirect / https://photos.exemple.fr/
</VirtualHost>
<VirtualHost *:443>
ServerName photos.exemple.fr
DocumentRoot /var/www/exemple.fr/photos/www
SSLEngine On
SSLCertificateFile /scripts/certificate_authority/apache/photos.exemple.fr.crt
SSLCertificateKeyFile /scripts/certificate_authority/apache/photos.exemple.fr.key
CustomLog /var/www/exemple.fr/photos/log/access.log
ErrorLog /var/www/exemple.fr/photos/log/error.log
</VirtualHost>
```
Nous avons créé un hôte virtuel non sécurisé redirigeant vers un hôte virtuel sécurisé, nous avons déjà vu le principe.
Créons maintenant les certificats :
```bash
/scripts/certificate_authority/make_request apache photos.exemple.fr
/scripts/certificate_authority/sign_request apache photos.exemple.fr
chown www-data:www-data /scripts/certificate_authority/apache/*
```
Warning : Lorsque le *Common Name* vous sera demandé, indiquez le nom de domaine !
Et dans notre cas, acceptez la création d'une clé sans mot de passe !
On active le site, et on redémarre apache :
```bash
a2ensite photos.exemple.fr
/etc/init.d/apache2 restart
```
## Installation de PhotoShow
On créé l'arborescence du site :
```bash
mkdir -p /var/www/exemple.fr/photos/{www,log,thumbs}
```
Puis on télécharge et on installe PhotoShow :
```bash
cd /usr/src
git clone git://github.com/thibaud-rohmer/PhotoShow.git
cp -R PhotoShow/* /var/www/exemple.fr/photos/www/
chown -R www-data:www-data /var/www/exemple.fr/photos
```
On configure l'application :
```bash
nano /var/www/exemple.fr/photos/www/config.php
```
```php
$config->photos_dir = "/var/public-docs/Photos";
$config->ps_generated = "/var/www/exemple.fr/photos/thumbs";
```
Vous noterez le répertoire */var/public-docs/Photos* qu'il faut créer, et qui contiendra donc vos photos.
```bash
mkdir /var/public-docs/Photos
```
L'application en elle-même est prête, vous pouvez la visiter depuis l'adresse `http://photos.exemple.fr`.
Vous pouvez créer un compte "*anonyme*", ou "*invites*", protégé par mot de passe, si vous ne voulez pas que des personnes non identifiées aient accès à votre galerie.
Vous pouvez aussi simplement la protéger avec un mot de passe, sans avoir besoin de créer un utilisateur particulier.
## Envoyer automatiquement ses photos prises avec un smartphone Android
Facile, si vous avez installé l'application WebDav File Manager comme indiqué dans [mon précédent article](https://web.archive.org/web/20120221004519/http://ingnu.fr/2012/02/12/une-alternative-a-dropbox/) (ou toute autre application Android capable de se synchroniser avec un dépôt WebDav ou SSH).
Il vous suffit de mettre en place une synchronisation entre le répertoire où vos photos sont stockées sur votre smartphone (*DCIM/*) et `https://files.exemple.fr/public/Photos`.
Important : Attention si vous mettez d'autres photos depuis une autre source, ces photos seront aussi copiées sur votre téléphone.
Pour l'éviter, vous pouvez créer un dossier */var/public-docs/Photos/Android*, que vous utiliserez pour la synchronisation.
Le tutoriel d'aujourd'hui est déjà terminé.
Nous avons vu des choses relativement compliquées à mettre en oeuvre, mais c'était aussi pour nous simplifier la vie plus tard.
Je vous avais bien dis que les prochains articles seraient plus simples !

256
content/interets/informatique/2012/02/13/renforcer-la-securite-de-son-serveur/index.md Normal file
View File

@@ -0,0 +1,256 @@
---
comments_url: https://com.richard-dern.fr/post/523
date: '2012-02-13 15:19:00'
dossier:
- Créer son propre Cloud
links:
- lang: fr
name: Page d'origine sur Archive.org
url: https://web.archive.org/web/20120225092126/http://ingnu.fr/2012/02/13/renforcer-la-securite-de-son-serveur/
tags:
- Apache
- Certificat
- Client
- Fail2ban
- iptables
title: Renforcer la sécurité de son serveur
weather:
humidity: 66
illuminance: 35349.3
precipitations: false
pressure: 1019.9
source:
- open-meteo
temperature: 0.5
wind_direction: 267
wind_speed: 14.8
weight: 12
---
Nous voilà sur la dernière ligne droite de notre série d'articles consacrée à la [mise en place d'un cloud personnel](https://web.archive.org/web/20120225092126/http://ingnu.fr/category/creer-son-propre-cloud/).
Nous avons installé à peu près tout ce dont on peut avoir besoin, mais à part un [script de pare-feu](https://web.archive.org/web/20120225092126/http://ingnu.fr/2012/02/05/creer-son-propre-cloud-introduction/) relativement restrictif et une protection anti-spam et anti-virus pour [le serveur mail](https://web.archive.org/web/20120225092126/http://ingnu.fr/2012/02/06/installation-de-son-propre-serveur-mail/), il reste encore quelques petites choses à faire pour sécuriser notre serveur.
Avant toute chose, contrairement à ce que beaucoup de gens recommandent comme bonne pratique, je ne vais pas aborder la question du changement de port pour améliorer la sécurité de notre serveur.
Je pense en effet qu'un simple *nmap* sur l'hôte à tester suffit pour déterminer quels sont les ports ouverts sur une machine, et ce n'est pas en déplaçant ce port que le "pirate" va jeter l'éponge.
Si quelqu'un est vraiment déterminé à récupérer de votre serveur des données auxquelles il n'a pas le droit d'accéder, il y parviendra.
Je mise donc sur une approche différente qu'on va tout de suite mettre en place, et qui repose sur [fail2ban](https://web.archive.org/web/20120225092126/http://www.fail2ban.org/).
Pour mémoire, fail2ban analyse les tentatives de connexion à votre serveur, et blacklist toute IP qui tentera d'accéder à votre serveur sans succès, selon un certain nombre de règles (qui peuvent être bien velues à configurer...).
## fail2ban
Installons l'application :
```bash
apt-get install fail2ban
/etc/init.d/fail2ban stop
```
On configure ensuite l'application :
```bash
mv /etc/fail2ban/jail.conf /etc/fail2ban/jail.conf-orig
nano /etc/fail2ban/jail.conf
```
Le nombre d'applications nécessitant une connexion réseau pour fonctionner est relativement limité sur notre serveur, ce qui va simplifier la configuration de fail2ban, d'autant que la plupart des filtres existe déjà.
Voici un fichier *jail.conf* de référence, correspondant à notre serveur :
```text
[DEFAULT]
ignoreip = 127.0.0.1 xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy
bantime = 600
maxretry = 3
backend = polling
destemail = contact@exemple.fr
banaction = iptables-multiport
mta = sendmail
protocol = tcp
action_ = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]
action_mw = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]
%(mta)s-whois[name=%(__name__)s, dest="%(destemail)s", protocol="%(protocol)s]
action_mwl = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]
%(mta)s-whois-lines[name=%(__name__)s, dest="%(destemail)s", logpath=%(logpath)s]
# Choose default action. To change, just override value of 'action' with the
# interpolation to the chosen action shortcut (e.g. action_mw, action_mwl, etc) in jail.local
# globally (section [DEFAULT]) or per specific section
action = %(action_)s
[ssh]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 6
[ssh-ddos]
enabled = false
port = ssh
filter = sshd-ddos
logpath = /var/log/auth.log
maxretry = 6
[pam-generic]
enabled = true
filter = pam-generic
port = all
banaction = iptables-allports
port = anyport
logpath = /var/log/auth.log
maxretry = 6
[apache]
enabled = true
port = http,https
filter = apache-auth
logpath = /var/www/*/*/log/error.log
maxretry = 6
[apache-multiport]
enabled = true
port = http,https
filter = apache-auth
logpath = /var/www/*/*/log/error.log
maxretry = 6
[apache-noscript]
enabled = true
port = http,https
filter = apache-noscript
logpath = /var/www/*/*/log/error.log
maxretry = 6
[apache-overflows]
enabled = true
port = http,https
filter = apache-overflows
logpath = /var/www/*/*/log/error.log
maxretry = 2
[postfix]
enabled = true
port = smtp,ssmtp
filter = postfix
logpath = /var/log/mail.log
[sasl]
enabled = true
port = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s
filter = sasl
logpath = /var/log/mail.log
[named-refused-tcp]
enabled = true
port = domain,953
protocol = tcp
filter = named-refused
logpath = /var/log/named/security.log
```
Si vous activez le monitoring pour bind, vous devez activer la journalisation :
```bash
nano /etc/bind/named.conf.options
```
```text
logging {
channel security_file {
file "/var/log/named/security.log" versions 3 size 30m;
severity dynamic;
print-time yes;
};
category security {
security_file;
};
};
```
```bash
/etc/init.d/bind9 restart
```
Vous devriez être relativement tranquille avec ce fichier de configuration.
Notice : N'oubliez surtout pas de renseigner correctement votre (vos) adresse(s) IP en début de fichier !
Démarrez ensuite le service :
```bash
/etc/init.d/fail2ban start
```
Désormais, si quelqu'un n'entre pas dans les clous, son adresse IP sera bloquée directement au niveau d'iptables, pour une durée déterminée spécifiée en début de fichier de configuration.
## Un firewall "modulaire"
On va un peu compléter [notre script de pare-feu](https://web.archive.org/web/20120225092126/http://ingnu.fr/2012/02/05/creer-son-propre-cloud-introduction/) pour vous permettre de spécifier vous-même une liste d'adresses IP à bannir.
```bash
nano /scripts/firewall
```
Ajoutez tout à la fin du fichier :
```text
if [ -f "/scripts/firewall.hosts" ]
then
for ip in `cat /scripts/firewall.hosts`; do
${IPT} -A INPUT -s $ip -j DROP
done
fi
```
Créez ensuite le fichier en question :
```bash
touch /scripts/firewall.hosts
```
Vous pouvez maintenant remplir ce fichier avec les adresses IP que vous souhaitez bloquer (une par ligne).
N'oubliez pas de relancer le script une fois vos modifications terminées :
```bash
/scripts/firewall
```
## Accès via certificats clients
Si vous le souhaitez, vous pouvez limiter l'accès à certains de vos sites Internet à certains clients disposant d'un certificat délivré par vous-même.
Notice : Évitez cette restriction sur l'accès webdav : les clients webdav peuvent ne pas gérer les certificats clients.
Il suffit de modifier le fichier de configuration de l'hôte virtuel que vous voulez "protéger", en rajoutant les lignes suivantes :
```text
<Location />
SSLCACertificateFile /scripts/certificate_authority/ca.crt
SSLVerifyClient require
SSLVerifyDepth 4
</Location>
```
Vous créez ensuite un certificat classique :
```bash
/scripts/certificate_authority/make_request apache-client sous-domaine.exemple.fr
/scripts/certificate_authority/sign_request apache-client sous-domaine.exemple.fr
chown -R www-data:www-data /scripts/certificate_authority/apache-client
```
Notice : Dans ce cas, ne créez pas de certificat sans mot de passe.
Il faut ensuite exporter le certificat créé et signé dans un format compatible :
```bash
openssl pkcs12 -export -clcerts -in /scripts/certificate_authority/apache-client/sous-domaine.exemple.fr.crt -inkey /scripts/certificate_authority/apache-client/sous-domaine.exemple.fr.key -out /scripts/certificate_authority/apache-client/sous-domaine.exemple.fr.p12
```
Transmettez ce certificat et son mot de passe au client qui doit accéder au site, client qui devra l'importer dans son navigateur.
Utilisez de préférence SSH pour effectuer ce transfert

211
content/interets/informatique/2012/02/13/trucs-et-astuces-pour-son-serveur-prive/index.md Normal file
View File

@@ -0,0 +1,211 @@
---
comments_url: https://com.richard-dern.fr/post/524
date: '2012-02-13 16:00:00'
dossier:
- Créer son propre Cloud
links:
- lang: fr
name: Page d'origine sur Archive.org
url: https://web.archive.org/web/20120222160009/http://ingnu.fr/2012/02/13/trucs-et-astuces-pour-son-serveur-prive/
tags:
- Astuces
- Trucs
title: Trucs et astuces pour son serveur privé
weather:
humidity: 72
illuminance: 14570.5
precipitations: false
pressure: 1019.2
source:
- open-meteo
temperature: 0.0
wind_direction: 266
wind_speed: 14.1
weight: 13
---
Avant d'aborder un système de sauvegarde et de restauration pour son cloud personnel, je me suis dis que ce serait une bonne idée de compiler dans un article quelques trucs et astuces, relatifs notamment à la surveillance de votre serveur.
C'est l'occasion d'apprendre ou réapprendre à se servir des outils inclus dans toute bonne distribution qui se respecte, mais aussi comment compléter ces outils.
## Monitoring "sur site"
## Journaux
Ce que j'appelle "monitoring sur site", c'est comment surveiller son système depuis un shell.
Un certain nombre de commandes existent pour nous permettre de diagnostiquer le fonctionnement de notre serveur.
Pour commencer, rien ne vaut les journaux.
Concernant notre serveur, voici ceux qui sont principalement à surveiller :
- */var/log/syslog*, probablement le plus important de tous
- */var/log/fail2ban.log*, pour surveiller ce que fail2ban fait
- */var/log/mail.log*, pour surveiller le serveur mail
- */var/www/*/*/log/*, pour surveiller les accès et erreurs sur l'ensemble de vos sites Internet
Pour consulter en temps réel un journal, utilisez la commande suivante :
```bash
tail -f /var/log/syslog
```
Pour consulter les X dernières lignes d'un journal :
```bash
tail -X /var/log/syslog
```
## Processus
Le monitoring sur site implique également la surveillance des processus.
La commande suivante :
```bash
ps aux
```
Vous indiquera l'état des processus au moment où vous lancez la commande.
Pour consulter l'état des processus en temps réel, utilisez la commande :
```bash
top
```
Cette commande vous informe également de l'état de la mémoire, de l'utilisation CPU, et d'autres choses encore.
## Matériel
Si vous hébergez vous-même votre serveur "à la maison", vous pourrez également avoir besoin de quelques capteurs de température :
```bash
apt-get install lm-sensors
sensors-detect
```
De même pour les disques durs :
```bash
apt-get install hddtemp
hddtemp /dev/sd*
```
D'autres informations relatives à votre matériel peuvent être extraites du pseudo système de fichiers */proc* :
```bash
cat /proc/cpuinfo
cat /proc/meminfo
```
## RAID
Si vous bénéficiez d'un raid logiciel, vous pouvez consulter son état de différentes manières :
```bash
cat /proc/mdstat
mdadm --detail /dev/md0
```
## Monitoring distant
Le monitoring distant est effectué depuis une interface web par exemple.
J'ai choisi [phpSysInfo](https://web.archive.org/web/20120222160009/http://phpsysinfo.sourceforge.net/), que je trouve plus agréable à configurer et utiliser que munin, trop centré sur la création de graphs, et relativement compliqué à mettre en œuvre.
## Hôte virtuel
Première chose, comme d'habitude, on s'occupe de l'hôte virtuel dans apache :
```bash
mkdir -p /var/www/exemple.fr/system/www
nano /etc/apache2/sites-available/system.exemple.fr
```
```text
<VirtualHost *:80>
ServerName system.exemple.fr
Redirect / https://system.exemple.fr/
</VirtualHost>
<VirtualHost *:443>
ServerName system.exemple.fr
DocumentRoot /var/www/exemple.fr/system/www
SSLEngine On
SSLCertificateFile /scripts/certificate_authority/apache/system.exemple.fr.crt
SSLCertificateKeyFile /scripts/certificate_authority/apache/system.exemple.fr.key
</VirtualHost>
```
Nous avons créé un hôte virtuel non sécurisé redirigeant vers un hôte virtuel sécurisé, nous avons déjà vu le principe.
Créons maintenant les certificats :
```bash
/scripts/certificate_authority/make_request apache system.exemple.fr
/scripts/certificate_authority/sign_request apache system.exemple.fr
chown www-data:www-data /scripts/certificate_authority/apache/*
```
Warning : Lorsque le *Common Name* vous sera demandé, indiquez le nom de domaine !
Et dans notre cas, acceptez la création d'une clé sans mot de passe !
On active le site, et on redémarre apache :
```bash
a2ensite system.exemple.fr
/etc/init.d/apache2 restart
```
Dans ce cas, il n'y a pas vraiment besoin de tenir des journaux.
## Installation de phpSysInfo
Rien de particulier à signaler : une fois l'application téléchargée et installée dans son répertoire (*/var/www/exemple.fr/system/www*), il suffit juste de la configurer en fonction des blocs que vous souhaitez afficher.
Certaines dépendances peuvent être nécessaires, en fonction des blocs que vous aurez configuré.
L'application vous informera via des messages d'erreurs si des dépendances ne sont pas satisfaites.
Vous pourrez alors aisément les installer.
## Notifications
Si vous faites appel à crontab pour effectuer des tâches routinières, il peut être intéressant d'avoir des rapports par mail.
Il vous suffit d'éditer votre crontab et d'y insérer la ligne suivante :
```text
MAIL="contact@exemple.fr"
```
Nous avons installé [un serveur XMPP](https://web.archive.org/web/20120222160009/http://ingnu.fr/2012/02/08/communiquer-via-xmpp/), on peut également s'en servir comme service de notification.
Ainsi, pour toute application qui permet d'exécuter une commande suivant un évènement donné, on peut demander à cette application d'envoyer un message à un compte XMPP que vous aurez créé à cet effet.
Nous utiliserons pour cela le script *sendxmpp* :
```bash
apt-get install sendxmpp
```
Que l'on utilisera de la manière suivante :
```bash
echo "Votre message" | sendxmpp -u <utilisateur> -p <mot de passe> -j exemple.fr <destinataire>@exemple.fr
```
## Liste des paquets installés
Il peut être utile de récupérer la liste de tous les paquets installés, par exemple dans le cas d'une réinstallation ou d'un mirroring.
Pour récupérer cette liste, on utilisera la commande suivante :
```bash
dpkg -l | grep ii | awk -F ' ' '{print $2}'
```
On peut, du coup, exporter cette liste dans un fichier :
```bash
dpkg -l | grep ii | awk -F ' ' '{print $2}' > packages.list
```
## Conclusion
Plein d'autres choses manquent surement à l'appel.
On ne peut pas tout voir, mais théoriquement, ce qu'on a vu jusqu'aujourd'hui devrait être suffisant pour que vous puissiez jouer avec votre propre cloud.
Important : Ceci dit, avant de vraiment jouer avec, attendez au moins l'avant-dernier article (qui est aussi le prochain), consacré à la sauvegarde et à la restauration de son serveur !

3
content/interets/informatique/2012/02/15/pourquoi-jarrete-facebook-et-twitter/data/images/cover.yaml Normal file
View File

@@ -0,0 +1,3 @@
description: "Couverture originale créée localement pour accompagner la republication de l'article Pourquoi j'arrête facebook et twitter."
attribution: "Codex"
prompt: "Illustration abstraite éditoriale sur les réseaux sociaux, avec bulles de conversation connectées, lignes de réseau et ambiance rétro-web 2012, sans texte, sans logo."

BIN
content/interets/informatique/2012/02/15/pourquoi-jarrete-facebook-et-twitter/images/cover.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 104 KiB

47
content/interets/informatique/2012/02/15/pourquoi-jarrete-facebook-et-twitter/index.md Normal file
View File

@@ -0,0 +1,47 @@
---
comments_url: https://com.richard-dern.fr/post/525
cover: images/cover.png
date: '2012-02-15 17:19:00'
links:
- lang: fr
name: Page d'origine sur Archive.org
url: https://web.archive.org/web/20120221042913/http://ingnu.fr/2012/02/15/pourquoi-jarrete-facebook-et-twitter/
tags:
- Internet
- StatusNet
title: Pourquoi j'arrête facebook et twitter
weather:
humidity: 82
illuminance: 16724.4
precipitations: false
pressure: 1014.1
source:
- open-meteo
temperature: 3.0
wind_direction: 302
wind_speed: 19.9
---
[Je l'ai dis il y a quelques dizaines de minutes](https://web.archive.org/web/20120221042913/https://social.ingnu.fr/notice/3292) sur [social.ingnu](https://web.archive.org/web/20120221042913/https://social.ingnu.fr/), j'abandonne facebook et twitter. Bien que ma principale raison soit évidemment liée à la protection de ma vie privée, il en existe d'autres.
Tout d'abord, facebook et twitter ont beau cumuler à eux deux une population plus nombreuse que la Chine, je m'y sens seul. J'ai l'impression qu'il n'y a aucune activité qui m'intéresse. C'est d'autant plus vrai en ce qui concerne facebook, dont l'idée est davantage de se constituer un cercle d'amis plutôt qu'échanger des idées réellement intéressantes. Je commence à me lasser des photos personnelles, des histoires d'horoscope, ou de ce que les gens ont bouffé la veille (je ne parle pas de mes propres contacts qui ont des timelines un peu plus développées). Ce que je veux dire, c'est que trouver des gens qui m'intéressent sur facebook tient plus du hasard qu'autre chose. D'ailleurs, en fait, ce n'est jamais arrivé.
En ce qui concerne twitter, la situation est différente. La limite à 160 caractères (ou 144 je ne sais plus) est parfaitement incompréhensible pour moi. On est à l'ère du haut débit, où on s'échange des photos en quelques secondes, des films en quelques minutes. La limite de caractères arbitrairement imposée par twitter engendre des posts parfaitement incompréhensibles, truffés de raccourcis et d'abréviations qui pourrissent la timeline, d'autant que cela nécessite de faire le tri entre l'information qui est intéressante de celle qui ne l'est pas. C'est une perte de temps.
Il y a quelques semaines, j'ai franchi le pas et j'ai installé une instance de [status.net](https://web.archive.org/web/20120221042913/http://status.net/). Je l'ai installé parce que c'est un Logiciel Libre, et qu'il est présenté comme un réseau social libre et décentralisé. J'en avais déjà entendu parlé, mais j'étais un peu frileux, n'étant pas de nature particulièrement sociable.
En fin de compte, je me suis rendu compte que l'ouverture de cette application n'est pas seulement une philosophie de développement: cette ouverture se fait aussi sur le monde, à un niveau que je ne soupçonnais pas. On ne suit pas seulement des gens, individuellement, on suit des groupes, des fédérations d'instances de status.net. Et là, ça s'emballe: je reçois les posts de plusieurs dizaines de personnes simplement parce que je suis le groupe [Debian](https://web.archive.org/web/20120221042913/http://identi.ca/group/14/id), ou le groupe [GNU](https://web.archive.org/web/20120221042913/http://identi.ca/group/33/id). Et le ratio informations intéressantes/inutiles s'inverse par rapport aux autres réseaux sociaux (je ne parle pas de Google+ que j'ai quitté il y a quelques temps).
Du coup, on peut communiquer avec beaucoup plus de gens que sur facebook ou twitter, et surtout, beaucoup plus de gens qui partagent les mêmes centres d'intérêt.
Je n'ai pas encore bien pris le temps de m'occuper de mes followers ou de ceux que je follow, ce qui fait que ma liste est relativement restreinte. Mais j'ai déjà l'impression que c'est un nouveau monde qui s'étend à mes pieds - à mes doigts. Je me sens comme un explorateur qui vient de découvrir une terre inconnue, qui n'a qu'une hâte: l'explorer. D'autant que cette terre est déjà bien peuplée, vivante, comme si elle avait toujours été là.
Ce qui me permet de rebondir sur une critique que j'ai parfois entendu: non, ce n'est pas mort, non, ce n'est pas dépeuplé. C'est au contraire très actif, et de manière beaucoup plus intelligente que les autres réseaux sociaux.
Par un mystère que je ne m'explique pas, j'ai l'impression que des étrangers communiquent plus facilement sur status.net que sur n'importe quel autre réseau social. En ce qui concerne twitter, c'est peut être dû au fait que la communication est essentiellement uni-directionnelle, et concernant facebook, peut-être parce qu'il n'y a de communication que sur soi-même.
Sur status.net, c'est l'esprit Libre: on échange, on partage, on communique de manière omnidirectionnelle. Il suffit de faire partie d'un groupe pour que tous puissent lire ce que vous écrivez, tandis que vos posts (vos notices) ne quittent pas votre serveur.
Si vous faites partie de mes contacts facebook ou twitter, et que vous ne faites pas encore partie de mes contacts sur social.ingnu, je vous recommande donc chaudement de venir me rejoindre. [Créez-vous un compte sur mon instance](https://web.archive.org/web/20120221042913/https://social.ingnu.fr/main/register) (ou sur [identi.ca](https://web.archive.org/web/20120221042913/http://identi.ca/) par exemple), et ajoutez *ingnu@social.ingnu.fr* à ceux que vous suivez.
Peut-être alors qu'un jour, vous aussi vous quitterez les réseaux sociaux riches à milliards qui se servent de vos informations personnelles pour y parvenir, pour revenir du côté lumineux de la Force...

421
content/interets/informatique/2012/02/19/sauvegarder-et-restaurer-son-serveur/index.md Normal file
View File

@@ -0,0 +1,421 @@
---
comments_url: https://com.richard-dern.fr/post/526
date: '2012-02-19 00:14:00'
dossier:
- Créer son propre Cloud
links:
- lang: fr
name: Page d'origine sur Archive.org
url: https://web.archive.org/web/20120221004524/http://ingnu.fr/2012/02/19/sauvegarder-et-restaurer-son-serveur/
tags:
- Backup
- rsync
- Sauvegarde
title: Sauvegarder et restaurer son serveur
weather:
humidity: 96
illuminance: 0.0
precipitations: true
pressure: 1012.4
source:
- open-meteo
temperature: 3.6
wind_direction: 226
wind_speed: 16.5
weight: 14
---
Maintenant que nous disposons d'un serveur pratiquement complet pour [avoir son propre cloud](https://web.archive.org/web/20120221004524/http://ingnu.fr/category/creer-son-propre-cloud/), que nous avons [renforcé sa sécurité](https://web.archive.org/web/20120221004524/http://ingnu.fr/2012/02/13/renforcer-la-securite-de-son-serveur/) et que nous avons vu comment [opérer un monitoring basique](https://web.archive.org/web/20120221004524/http://ingnu.fr/2012/02/13/trucs-et-astuces-pour-son-serveur-prive/), nous allons voir comment sauvegarder et restaurer son serveur.
Nous allons faire appel au fameux [rsync](https://web.archive.org/web/20120221004524/http://rsync.samba.org/), pour ne pas encombrer notre serveur de solutions aussi lourdes à installer qu'à configurer, d'autant que je vous propose un script qui va simplifier tout ça, et même plus encore...
Vous pouvez placer ce script n'importe où : sur le serveur qui héberge vos services, sur votre propre machine, sur un serveur séparé, un NAS qui supporte rsync et l'authentification par clé, etc.
Il suffit de configurer un peu le script pour que la sauvegarde se fasse presque toute seule.
Elle est pas belle la vie Libre ?
## Choisir son dispositif de stockage
Communément, on sauvegarde sur une partition séparée, de préférence sur un disque séparé, peut être dans une machine séparée, ultimement dans un local séparé.
Il n'y a véritablement que deux prérogatives à l'utilisation du script que je vous propose : la machine doit pouvoir utiliser rsync, et l'authentification par clé.
Toute distribution GNU/Linux en est capable, vous ne devriez donc pas avoir trop de mal à disposer d'une plateforme adéquate.
Évidemment, une autre prérogative s'impose d'elle-même : l'espace disque disponible.
À titre d'exemple, sachez que j'utilise ce script pour sauvegarder deux serveurs et les documents d'une dizaine de personnes.
Le premier, celui qui héberge ingnu.fr, héberge aussi tout un tas d'autres sites, un serveur mail d'une dizaine d'utilisateurs, les bases de données, etc.
Au total, un snapshot des deux machines occupe à l'heure actuelle 7.6Go.
Mon script vous permet de disposer de deux types de sauvegardes : un instantané (appelé *snapshot*) et un instantané de chaque heure de chaque jour.
Le premier instantané est en réalité vieux au maximum d'une minute, tandis que les autres instantanés vous permettent de remonter dans le temps par tranche d'une heure, sur un nombre de jours que vous pouvez déterminer.
Au final, sur cinq jours (qui est le réglage par défaut), l'espace disque total occupé par les sauvegardes n'est que doublé : il est actuellement de 13Go.
Seuls les fichiers modifiés occupent la différence entre l'espace total et l'espace initial.
Vous n'avez donc pas besoin d'un disque de plusieurs téraoctets, à moins que vous ne vouliez sauvegarder aussi des fichiers comme des vidéos ou des distributions GNU/Linux en quantité industrielle...
## Créer la clé d'authentification
La communication entre le serveur et la machine qui exécute la sauvegarde (qui peut aussi être la même machine donc) se fait via rsync, donc ssh.
La connexion est par conséquent chiffrée, et les transferts sont intelligents : la bande passante est minimisée.
Pour pouvoir tout sauvegarder d'un coup, on va donc sauvegarder en tant que root.
Si vous sauvegardez depuis une machine distante, créez une clé avec la commande suivante :
```bash
ssh-keygen -t rsa -f ~/.ssh/id_rsa_backup
```
Que vous enverrez au serveur via la commande :
```bash
ssh-copy-id -i ~/.ssh/id_rsa_backup.pub root@exemple.fr
```
Vous devrez saisir le mot de passe root de la machine distante.
Testez enfin l'accès :
```bash
ssh root@exemple.fr
```
Vous devriez être connecté sans avoir eu besoin de saisir votre mot de passe.
## Créer le script de sauvegarde
Créez un répertoire dédié au script et à sa configuration :
```bash
mkdir -p /scripts/backup
cd /scripts/backup
mkdir conf.d include.d exclude.d
```
Pour respecter le [Standard de Hiérarchie des Systèmes de Fichiers](https://web.archive.org/web/20120221004524/http://www.pathname.com/fhs/), nous devrions placer le script dans */usr/bin*, et la configuration dans */etc/backup*.
Rien ne vous empêche de procéder de la sorte, à condition de modifier les chemins d'accès dans le script que nous allons voir tout de suite :
```bash
nano backup
```
```text
#!/bin/bash
###############################################################################
# Variables #
###############################################################################
my_pid=$$
my_dir=$(dirname $0)
pid_file="/var/run/backup.pid"
conf_dir="$my_dir/conf.d"
include_dir="$my_dir/include.d"
exclude_dir="$my_dir/exclude.d"
log_dir="/var/log/backup"
log_file="$log_dir/backup"
rsync_args="--archive --recursive --delete --delete-excluded"
backup_root="/mnt/backup"
rsync=$(which rsync)
current_date=$(date "+%Y-%m-%d")
current_minute=$(date +%M)
current_hour=$(date +%H)
yesterday_date=$(date --date "yesterday" "+%Y-%m-%d")
max_age=5
oldest_backup=$(date --date "$max_age days ago" "+%Y-%m-%d/%H")
oldest_log=$(date --date "$max_age days ago" "+%Y-%m-%d")
###############################################################################
# Fonctions #
###############################################################################
function check_pid() {
if [ -f "$pid_file" ]
then
old_pid=$(cat "$pid_file")
old_pid_exists=$(ps -p $old_pid | grep -v TTY | awk -F " " '{print $1}')
if [ "$old_pid_exists" != "" ]
then
exit
fi
fi
}
function log() {
if [ "$2" == "true" -o "$2" == "TRUE" -o "$2" == "yes" -o "$2" == "YES" -o "$2" == "1" ]
then
log_date=$(date "+%d/%m/%Y %H:%M:%S")
echo "[$log_date] $1" >> "$log_file"
else
echo "$1" >> "$log_file"
fi
}
function check_dir() {
if [ ! -d "$1" ]
then
mkdir -p "$1"
fi
}
###############################################################################
# Lancement de la procédure #
###############################################################################
##### Vérification des journaux ###############################################
check_dir "$log_dir"
if [ ! -f "$log_file" ]
then
touch "$log_file"
fi
##### Déplacement des anciens journaux ########################################
if [ "$current_hour" == "00" -a "$current_minute" == "00" ]
then
mv "$log_file" "$log_file-$yesterday_date"
fi
##### Démarrage de la procédure ###############################################
check_pid
echo $my_pid > "$pid_file"
start_date=$(date "+%d/%m/%Y %H:%M:%S")
log " "
log "###############################################################################"
log "# Début de la procédure : $start_date #"
log "###############################################################################"
log " "
list=$(ls "$conf_dir")
for host in $list; do
conf_file="$conf_dir/$host"
source "$conf_file"
host_rsync_args="$rsync_args"
host_snapshot="$backup_root/$host/snapshot"
if [ "$ENABLED" != "yes" -a "$ENABLED" != "YES" -a "$ENABLED" != "true" -a "$ENABLED" != "TRUE" -a "$ENABLED" != "1" ]
then
log "**** L'hôte $host est désactivé ****"
log " "
continue
fi
log "**** Traitement de l'hôte $host ****"
log " "
source="$SOURCE"
target="$host_snapshot"
check_dir "$target"
log "Source : $SOURCE" true
log "Destination : $target" true
if [ -f "$include_dir/$host" ]
then
log "Un fichier d'inclusion existe : $include_dir/$host" true
host_rsync_args="$host_rsync_args --files-from=$include_dir/$host"
fi
if [ -f "$exclude_dir/$host" ]
then
log "Un fichier d'exclusion existe : $exclude_dir/$host" true
host_rsync_args="$host_rsync_args --exclude-from=$exclude_dir/$host"
fi
log "Commande : $rsync $host_rsync_args $source $target" true
log "Démarrage de la création ou mise à jour de l'instantané..." true
$rsync $host_rsync_args $source $target
log "Création ou mise à jour de l'instantané terminée" true
##### Sauvegarde périodique ###############################################
if [ "$current_minute" == "00" ]
then
log " "
log "Sauvegarde périodique" true
source="$host_snapshot/"
target="$backup_root/$host/$current_date/$current_hour/"
check_dir "$target"
log "Source : $source" true
log "Destination : $target" true
log "Commande : $rsync $host_rsync_args --links-dest=$source $SOURCE $target" true
log "Démarrage de la sauvegarde périodique..." true
$rsync $host_rsync_args --link-dest="$source" "$SOURCE" "$target"
log "Sauvegarde périodique terminée" true
fi
##### Suppression des anciennes sauvegardes ###############################
log " "
log "Recherche d'une ancienne sauvegarde ($backup_root/$host/$oldest_backup)..." true
if [ -d "$backup_root/$host/$oldest_backup" ]
then
log "Une ancienne sauvegarde existe : $backup_root/$host/$oldest_backup" true
log "Suppression de la sauvegarde la plus ancienne..." true
rm -rf "$backup_root/$host/$oldest_backup"
log "Suppression terminée" true
else
log "Il n'existe pas d'ancienne sauvegarde" true
fi
log " "
done
end_date=$(date "+%d/%m/%Y %H:%M:%S")
log "###############################################################################"
log "# Fin de la procédure : $end_date #"
log "###############################################################################"
log " "
rm -f "$pid_file"
```
Important : Veuillez noter que ce script me convient bien : rien ne vous empêche de faire des ajustements pour qu'il vous corresponde à VOUS !
Notice : Modifiez impérativement la variable *backup_root* !
Quelques explications.
Si vous voulez respecter les FHS, modifiez les variables *conf_dir*, *include_dir* et *exclude_dir*.
Vous pouvez également modifier la variable *max_age*, dont la valeur (un entier) représente le nombre de jours à conserver.
Ensuite, quelques fonctions classiques : recherche d'un pid existant (pour ne pas lancer deux sauvegardes simultanées), journalisation, et recherche et création de répertoire.
La procédure commence alors par la vérification de l'existence des journaux et leur archivage.
Puis, le script récupère la liste des fichiers contenus dans *conf.d*, lit chacun d'entre eux pour obtenir deux directives de configuration (*$ENABLED* true/false et *$SOURCE* représentant la source à sauvegarder), recherche s'il existe un fichier d'inclusion (il vaut mieux sinon vous sauvegardez toute la partition, se trouve dans le répertoire *include.d*) et un fichier d'exclusion (facultatif, se trouve dans *exclude.d*).
Chaque minute (via une tâche cron), le script se lance, et créé ou met à jour l'instantané (le contenu du répertoire *$backup_root/$host/snapshot*).
Chaque heure, ce snapshot est créé dans un répertoire distinct, en faisant appel aux hard links : le fichier n'est pas copié, mais un hard link est créé.
Autrement dit, le fichier est accessible depuis deux adresses différentes.
Même si la source (dans le *snapshot*) est supprimée, le fichier existe toujours grâce au hard link.
Dans notre cas, cela nous permet d'économiser de l'espace disque.
La conséquence de cette façon de procéder est de disposer à tout instant d'une image complète du système de fichiers sauvegardé.
Et le but, c'est de le restaurer en une ligne de commande (une simple copie suffira).
Enfin, on supprime les instantanés les plus anciens.
Attribuez le droit d'exécution au script :
```bash
chmod +x backup
```
## Configuration
Vous disposez donc d'un répertoire *conf.d, include.d* et *exclude.d*.
Le premier contiendra un fichier par machine à sauvegarder.
Vous pouvez nommer ce fichier comme bon vous semble.
Une seule règle à respecter : ce nom devra être le même que celui du fichier d'inclusions et du fichier d'exclusions.
Créons la configuration de notre cloud :
```bash
nano conf.d/my_cloud
```
```text
ENABLED=true
SOURCE=/
```
Si le serveur est une machine différente, on utilisera la notation suivante :
```text
SOURCE="root@exemple.fr:/"
```
Avec cette configuration, on va sauvegarder l'ensemble de la machine concernée (ou plus exactement, l'intégralité de la partition */*).
Ce n'est probablement pas ce que vous voulez, alors nous devons créer un fichier d'inclusions :
```bash
nano include.d/my_cloud
```
À peu de chose près, vous devriez mettre ceci :
```text
/etc/amavis
/etc/apache2
/etc/bind
/etc/clamav
/etc/dovecot
/etc/php5
/etc/postfix
/etc/prosody
/etc/rc.local
/etc/spamassassin
/etc/ssl
/opt
/scripts
/var/vmail
/var/www
/var/lib/mysql
```
Avec ce contenu, vous devriez sauvegarder l'intégralité du serveur que nous avons configuré jusqu'à maintenant.
Pour éviter de sauvegarder des choses inutiles, créons un fichier d'exclusions :
```bash
nano exclude.d/my_cloud
```
```text
log
```
## Lancement
On édite la crontab de l'utilisateur qui procède à la sauvegarde :
```bash
crontab -e
```
```text
* * * * * /scripts/backup/backup
```
Et on vérifie le contenu du journal :
```bash
tail -f /var/log/backup/backup
```
## Restauration
Pour restaurer votre serveur, il suffit de copier vers lui tout ou partie de la dernière sauvegarde valide, via *scp*, tout simplement.
Inutile de tergiverser : grâce à ce système de sauvegarde, il suffit d'une simple copie sécurisée pour restaurer le dernier état valide du serveur; contrairement à d'autres solutions de sauvegarde, pas besoin d'installer un agent sur la machine distante, une simple connexion ssh suffit !
## Conclusion
Nous voici arrivés à la fin de la série d'articles sur la création de son cloud personnel.
Plus qu'un article à publier d'ici quelques minutes, alors à tout de suite !

115
content/interets/informatique/2012/02/19/vue-densemble-et-conclusion/index.md Normal file
View File

@@ -0,0 +1,115 @@
---
comments_url: https://com.richard-dern.fr/post/527
date: '2012-02-19 00:33:00'
dossier:
- Créer son propre Cloud
links:
- lang: fr
name: Page d'origine sur Archive.org
url: https://web.archive.org/web/20120531001514/http://ingnu.fr/2012/02/19/vue-densemble-et-conclusion/
title: Vue d'ensemble et conclusion
weather:
humidity: 97
illuminance: 0.0
precipitations: true
pressure: 1011.8
source:
- open-meteo
temperature: 3.5
wind_direction: 224
wind_speed: 17.1
weight: 15
---
Voilà, [notre série d'articles consacrée à la mise en place d'un cloud personnel](https://web.archive.org/web/20120531001514/http://ingnu.fr/category/creer-son-propre-cloud/) nous permettant de nous affranchir des solutions propriétaires en ayant recours uniquement à des Logiciels Libres touche à sa fin.
Vous disposez désormais d'un ensemble d'outils performants, sécurisés, fiables et faciles à entretenir.
Vous avez votre cloud !
Pour y voir un peu plus clair, je vous propose, à travers ce dernier article, de faire le point sur ce que nous avons fait, sur ce qui est en place, et sur ce qui peut encore être optimisé dans le futur.
## Articles publiés, sommaire
- [Créer son propre Cloud : Introduction](https://web.archive.org/web/20120531001514/http://ingnu.fr/2012/02/05/creer-son-propre-cloud-introduction/)
- [Installer et configurer un serveur DNS](https://web.archive.org/web/20120531001514/http://ingnu.fr/2012/02/05/installer-et-configurer-un-serveur-dns/)
- [Création de sa propre autorité de certification](https://web.archive.org/web/20120531001514/http://ingnu.fr/2012/02/06/creation-de-sa-propre-autorite-de-certification/)
- [Installation de son propre serveur mail](https://web.archive.org/web/20120531001514/http://ingnu.fr/2012/02/06/installation-de-son-propre-serveur-mail/)
- [Installation d'un serveur HTTP/HTTPS](https://web.archive.org/web/20120531001514/http://ingnu.fr/2012/02/07/installation-dun-serveur-http-https/)
- [Kronolith : une alternative à Google Calendar](https://web.archive.org/web/20120531001514/http://ingnu.fr/2012/02/07/kronolith-une-alternative-a-google-calendar/)
- [Communiquer via XMPP](https://web.archive.org/web/20120531001514/http://ingnu.fr/2012/02/08/communiquer-via-xmpp/)
- [Son propre réseau social avec status.net](https://web.archive.org/web/20120531001514/http://ingnu.fr/2012/02/08/son-propre-reseau-social-avec-status-net/)
- [Partager ses fichiers sur les réseaux sociaux avec SMP](https://web.archive.org/web/20120531001514/http://ingnu.fr/2012/02/09/partager-ses-fichiers-sur-les-reseaux-sociaux-avec-smp/)
- [Une alternative à Dropbox](https://web.archive.org/web/20120531001514/http://ingnu.fr/2012/02/12/une-alternative-a-dropbox/)
- [Gérer ses photos avec PhotoShow](https://web.archive.org/web/20120531001514/http://ingnu.fr/2012/02/13/gerer-ses-photos-avec-photoshow/)
- [Renforcer la sécurité de son serveur](https://web.archive.org/web/20120531001514/http://ingnu.fr/2012/02/13/renforcer-la-securite-de-son-serveur/)
- [Trucs et astuces pour son serveur privé](https://web.archive.org/web/20120531001514/http://ingnu.fr/2012/02/13/trucs-et-astuces-pour-son-serveur-prive/)
- [Sauvegarder et restaurer son serveur](https://web.archive.org/web/20120531001514/http://ingnu.fr/2012/02/19/sauvegarder-et-restaurer-son-serveur/)
## Ports réseaux
En toute logique, depuis l'extérieur, tous les ports de votre serveur sont fermés, à l'exception des ports suivants :
| Port | Utilisation |
| --- | --- |
| 22 | Accès au serveur via SSH |
| 25 | Accès au serveur SMTP (connexion non sécurisée) |
| 53 | Accès au serveur DNS |
| 80 | Accès au serveur HTTP (connexion non sécurisée) |
| 443 | Accès au serveur HTTPS (connexion sécurisée) |
| 465 | Accès au serveur SMTPS (connexion sécurisée) |
| 993 | Accès au serveur IMAPS (connexion sécurisée) |
| 5222 | Accès au serveur XMPP |
| 5269 | Accès au serveur XMPP |
## Applications installées
- [Apache](https://web.archive.org/web/20120531001514/http://www.apache.org/) (serveur HTTP et HTTPS + Webdav)
- [Bind](https://web.archive.org/web/20120531001514/http://www.isc.org/software/bind) (serveur DNS)
- [MySQL](https://web.archive.org/web/20120531001514/http://www.mysql.com/) (base de données)
- [Postfix](https://web.archive.org/web/20120531001514/http://www.postfix.org/) (serveur SMTP et SMTPS)
- [Dovecot](https://web.archive.org/web/20120531001514/http://dovecot.org/) (serveur IMAP et IMAPS, gestion des filtres sieve)
- [Prosody](https://web.archive.org/web/20120531001514/http://prosody.im/) (serveur XMPP et BOSH)
- [Unison](https://web.archive.org/web/20120531001514/http://www.cis.upenn.edu/~bcpierce/unison/) (synchronisation)
- [fail2ban](https://web.archive.org/web/20120531001514/http://www.fail2ban.org/) (sécurisation)
- [rsync](https://web.archive.org/web/20120531001514/http://rsync.samba.org/) (sauvegarde)
## Applications web installées
- [phpMyAdmin](https://web.archive.org/web/20120531001514/http://www.phpmyadmin.net/) (gestion de la base de données)
- [RoundCube](https://web.archive.org/web/20120531001514/http://roundcube.net/) (client mail)
- [Horde](https://web.archive.org/web/20120531001514/http://www.horde.org/) + [Kronolith](https://web.archive.org/web/20120531001514/http://www.horde.org/apps#kronolith-) (agenda partagé)
- [Jappix](https://web.archive.org/web/20120531001514/https://project.jappix.com/) (client XMPP)
- [Status.net](https://web.archive.org/web/20120531001514/http://status.net/) (réseau social)
- [SMP](https://web.archive.org/web/20120531001514/http://sharemypics.net/) (partage de fichiers sur les réseaux sociaux)
- Horde + [Gollem](https://web.archive.org/web/20120531001514/http://www.horde.org/apps#gollem-) (accès aux fichiers)
- [PhotoShow](https://web.archive.org/web/20120531001514/http://www.photoshow-gallery.com/) (galerie de photos)
- [phpSysInfo](https://web.archive.org/web/20120531001514/http://phpsysinfo.sourceforge.net/) (monitoring)
## Améliorations, ajouts
En l'état, vous disposez d'une base, bien fournie mais une base tout de même à laquelle on peut ajouter beaucoup d'autres choses :
- un serveur de streaming audio/vidéo
- des serveurs de jeux comme Minecraft ou Half Life qui offrent un serveur natif GNU/Linux
- des scripts plus personnalisés
- d'autres applications web (blog, agrégateur de contenu, syndication, utilitaires de la vie courante)
- la gestion d'un onduleur
- j'aurai aimé compléter l'article sur [XMPP](https://web.archive.org/web/20120531001514/http://ingnu.fr/2012/02/08/communiquer-via-xmpp/) en rajoutant des astuces pour l'intégration avec postfix/dovecot pour la notification de nouveaux messages ou pour un monitoring interactif du serveur, mais je n'ai pas eu le temps de tester moi-même
- et probablement d'autres choses qui ne me viennent pas immédiatement à l'esprit
## Remerciements
Je remercie :
- tous mes lecteurs qui ont contribué de près ou de loin à la rédaction de ces articles
- les bloggeurs qui m'ont linké
- mes followers, qu'ils soient sur twitter, facebook ou [status.net](https://web.archive.org/web/20120531001514/https://social.ingnu.fr/ingnu)
- Coca Cola et Red Bull (qui auraient pu me fournir quelques canettes gracieusement, franchement...)
- ma femme qui m'a supporté
- mes chats qui ne sont pas montés sur le bureau trop souvent pendant que j'écrivais
- mes PC qui ne m'ont pas lâché pendant que je les torturais
- l'Allemagne qui ne signe pas ACTA
- mes parents sans qui je ne serai pas là aujourd'hui
- ceux qui riront en lisant mes remerciements, particulièrement celle concernant mes parents
Continuez de m'écrire, me linker et m'aider.
Vous me donnez un but en le faisant : contribuer aux communautés du Libre !

3
content/interets/informatique/2012/02/25/les-6-fleaux-dinternet/data/images/cover.yaml Normal file
View File

@@ -0,0 +1,3 @@
description: "Couverture originale créée localement pour accompagner la republication de l'article Les 6 fléaux d'Internet."
attribution: "Codex"
prompt: "Illustration abstraite éditoriale sur Internet et son architecture, avec globe stylisé, arcs de connexion et ambiance rétro-web 2012, sans texte, sans logo."

BIN
content/interets/informatique/2012/02/25/les-6-fleaux-dinternet/images/cover.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 104 KiB

100
content/interets/informatique/2012/02/25/les-6-fleaux-dinternet/index.md Normal file
View File

@@ -0,0 +1,100 @@
---
comments_url: https://com.richard-dern.fr/post/528
cover: images/cover.png
date: '2012-02-25 00:02:00'
links:
- lang: fr
name: Page d'origine sur Archive.org
url: https://web.archive.org/web/20120318074613/http://ingnu.fr/2012/02/25/les-6-fleaux-dinternet/
tags:
- Internet
- Chiffrement
- DNS
- Fai
- Ipv6
- Motdepasse
- Tracabilite
title: Les 6 fléaux d'Internet
weather:
humidity: 99
illuminance: 0.0
precipitations: false
pressure: 1026.2
source:
- open-meteo
temperature: 5.6
wind_direction: 238
wind_speed: 11.5
---
Internet est une avancée majeure dans l'histoire de la civilisation humaine. C'est le seul outil de communication qui peut se vanter de réunir les peuples, de permettre à un juif et un musulman de se parler ou à un chinois ou un coréen de s'exprimer. C'est aussi l'outil le plus puissant à la disposition de l'Homme pour partager culture et connaissance. Bref, je ne vais pas faire l'apologie d'Internet: c'est pour moi l'une des plus grandes et belles inventions de l'Homme qui n'imitent pas la Nature (là dessus aussi il y a de quoi déblatérer: quelles sont les "vraies "inventions de l'Homme, celles dont il ne s'est pas inspiré de la Nature, mais c'est un autre sujet).
Malheureusement, dans sa conception actuelle, Internet souffre de nombreux défauts dont je vais vous parler aujourd'hui. Il y en a peut être d'autres, peut être que certains d'entre vous jugeront que ce ne sont pas des problèmes. Pour moi, baroudeur du Net depuis presque la première heure, conscient des implications techniques du Réseau des réseaux, voici ce que je considère comme étant les fléaux d'Internet.
## Le système de gestion des noms de domaine
[J'en ai déjà parlé](https://web.archive.org/web/20120318074613/http://ingnu.fr/2012/01/11/comment-licann-va-tuer-internet-et-comment-len-empecher/), j'estime que le DNS dans son état actuel est l'un des plus gros défauts d'Internet. Pour commencer, le simple fait de ne pas être propriétaire mais seulement locataire d'un nom de domaine est inacceptable. Ensuite, c'est un système extrêmement fragile. Un peu comme une bombe atomique, on ne se sert pas des attaques massives contre les serveurs DNS parce qu'on connaît le résultat: ce serait tout bonnement terrifiant.
Bien qu'étant un système décentralisé (si un serveur DNS, même racine, se casse la gueule, Internet continue de fonctionner), il n'en reste pas moins que des attaques massives contre un système aussi fragile seraient catastrophiques, à cause du système de propagation. Lancer un déni de service massif contre un serveur ne ferait que le mettre hors-ligne: il suffit de relancer le serveur. Par contre, saboter les enregistrements DNS serait beaucoup plus grave.
La faute à un système non chiffré, non authentifié (ou trop peu), et paradoxalement "centralisé": seuls quelques prestataires dans le monde ont la possibilité de gérer des noms de domaine. Ce qui explique pourquoi on ne peut pas être propriétaire de son propre domaine.
Autrement dit, si chacun pouvait déclarer au monde entier que LUI possède le domaine *exemple.fr*, et que seul LUI peut diffuser l'adresse des serveurs appartenant au domaine, je pense qu'on gagnerait en sécurité, mais aussi en liberté. C'est d'ailleurs l'objet du projet [ODDNS](https://web.archive.org/web/20120318074613/http://oddns.ingnu.fr/) que j'ai furtivement lancé et qui, pour le moment, ne fait pas grand bruit. Mais je pense qu'il y a matière à réflexion.
## Les connexions non chiffrées
C'est tellement simple de chiffrer une connexion, je ne comprends pas pourquoi ce n'est pas systématique dans le cadre de manipulation de données personnelles. Les gros sites (Google, Twitter) commencent à s'y mettre, mais comment ça se fait que ce ne fut pas proposé dès le début? Ça s'auto-signe un certificat si on n'a pas les moyens de s'en payer un "valide", au moins dans un premier temps.
Quand je téléphone à quelqu'un sur un sujet personnel, j'apprécie de ne pas avoir quelqu'un qui écoute au milieu. C'est exactement à ça que sert le chiffrement.
Alors je vous invite tous, si ce n'est pas déjà fait, à:
- [Installer des certificats sur vos sites "sensibles"](https://web.archive.org/web/20120318074613/http://ingnu.fr/2012/02/06/creation-de-sa-propre-autorite-de-certification/) , privés (une instance de status.net par exemple)
- Créer des clés GPG pour vos mails (ça fera l'objet d'un prochain article)
- N'utiliser que des services chiffrés lorsque cela est possible
## Les fournisseurs d'accès à Internet
C'est eux qui ont le pouvoir technique. Si les gouvernements obligent les FAI à empêcher l'accès à un site (ce qui ne serait pas possible avec un système tel que ODDNS), ou couper la connexion Internet d'un client, eux seuls peuvent le faire.
Il existe des [FAIs alternatifs](https://web.archive.org/web/20120318074613/http://www.ffdn.org/doku.php). L'idée est excellente, la conception simple.
Mais il existe encore des freins conséquents à la mise en place d'un réseau affranchi des FAIs, à commencer par les infrastructures, en particulier le "simple "fait d'avoir un câblage parfaitement indépendant.
Il "suffirait "de pouvoir tirer un câble vers son voisin, et que lui tire un câble vers son voisin, etc. Après, les geeks, il y en a partout: la mise en place d'un routeur est très simple. Autre avantage de cette solution, bien qu'elle nécessite le coût d'installation de départ et l'adoption massive du principe, l'accès à Internet serait gratuit pour tout le monde.
## Les mots de passe
Peut être l'idée la plus stupide dans le domaine de l'informatique (à part bien sûr l'obfuscation de code source). Trop de gens mettent 1234 (ou 123456 si le mot de passe doit être plus long...), ou des dates de naissances, des prénoms, brefs, des suites de caractères faciles à prévoir.
Je trouve l'idée encore plus stupide en entreprise: mettre un mot de passe sur une machine en entreprise, c'est dire à tout le monde qu'on fait des choses sur cette machine dont on n'est pas très fier. Le problème est différent sur les serveurs: il est évident qu'on ne va pas laisser tout le monde trifouiller un serveur. Mais une machine cliente, j'ai du mal à comprendre. Les données d'entreprises sensibles peuvent être stockées sur une partition chiffrée, à l'abri des regards indiscrets, protégée par un certificat, par exemple...
## La traçabilité
Quand un serveur A contacte un serveur B et en attend une réponse, il est impossible que les deux machines ne communiquent pas leur adresse IP. C'est logique, et là encore, c'est le même principe que le téléphone: l'adresse IP est le numéro de téléphone à contacter. Il est impensable de contacter une machine précise sans en connaître un identifiant quelconque, identifiant largement diffusé et accessible publiquement. Pour l'heure, il s'agit de l'adresse IP.
Le problème, c'est que ces adresses IP sont traçables géographiquement. Si vous faites une recherche géographique sur ingnu.fr, vous verrez que le serveur est hébergé à Vitry.
Je pense que c'est une donnée qui non seulement ne doit pas être communiquée, mais en plus qui n'aide pas une machine A à contacter une machine B. Les ordinateurs s'en foutent comme de leur premier disque dur de l'emplacement géographique de leur correspondant. Ils veulent juste savoir comment le contacter, via quelle adresse IP.
On pourrait imaginer tout un tas de choses: pour identifier un humain sur une machine, on peut avoir recours aux clés RSA par exemple. Pourquoi ne pas imaginer une surcouche aux protocoles réseaux, dont la clé RSA serait celle de l'ordinateur à contacter? Ce qui permettrait dans le même temps de chiffrer l'intégralité de la communication avec cet ordinateur, sans révéler en clair la clé RSA de la machine émettrice. Du coup, la connexion serait intraçable.
## IPv6
Effectivement, le monde est en pénurie d'adresses IPv4, à cause de la multiplication, la prolifération des périphériques mobiles notamment. La réponse à cette pénurie nous vient d'IPv6. En gros, on en a pour des millénaires avant d'épuiser le stock d'adresses IPv6.
C'est bien beau tout ça, mais IPv6 (dont le lancement mondial se fera le 06/06, je le rappelle) change pas mal d'autres choses, notamment le routage.
Mon sentiment personnel est que ces modifications ont une incidence néfaste sur la sécurité des réseaux de part la compréhension relativement difficile du nouveau protocole et le manque de support des constructeurs sur du matériel réseau moins récent. Je vais digresser, mais le fait que les firmwares de la majorité des routeurs sur le marché ne sont pas libres n'aide probablement pas à ce que la migration vers IPv6 se fasse sans douleur.
IPv6 est nécessaire, je serai bien bête de dire le contraire. Mais la communication autour de son adoption devrait être plus grand public: après tout, beaucoup de locataires de box vont passer en IPv6 même sans le savoir, ce qui peut leur causer des désagréments en matière de sécurité puisqu'ils ne savent pas comment configurer leur box.
On pourra bien sûr m'objecter que les paramètres par défaut devraient être corrects. Il n'en reste pas moins qu'encore une fois, c'est mon sentiment personnel. IPv6 risque de causer des problèmes de sécurité dans un premier temps, jusqu'à ce qu'il soit parfaitement maîtrisé.
## Conclusion
Je m'attends à ce qu'on me traite de paranoïaque, et je ne m'attends pas à ce qu'on me dise visionnaire. Mais en tenant compte de mon expérience du Réseau, de mes convictions personnelles, de ma connaissance technique de l'informatique, j'espère qu'Internet tel qu'on le connaît est voué à disparaitre au profit de réseaux connectés n'ayant plus à subir les désagréments que je viens d'évoquer. Malheureusement, en l'état actuel des choses, je crois qu'Internet est trop ancré dans un modèle économique pour que son modèle technique change radicalement.
Il faut s'attendre à l'émergence d'un réseau parallèle à Internet, relié à lui par une unique voie d'accès unilatérale, empêchant Internet d'accéder à ce réseau, mais laissant ce réseau accéder à Internet. Internet va devenir commercial à 100%, tandis que ce réseau alternatif ne sera soumis à aucune loi capitaliste et sera Libre à 100%. En tout cas, il faut y travailler. C'est, à mon humble avis, urgent et capital pour l'avenir de l'informatique.

3
content/interets/informatique/2012/02/29/hadopi-ne-sert-a-rien/data/images/cover.yaml Normal file
View File

@@ -0,0 +1,3 @@
description: "Couverture originale créée localement pour accompagner la republication de l'article Hadopi ne sert à rien."
attribution: "Codex"
prompt: "Illustration abstraite éditoriale sur la contrainte et la censure numérique, avec barres verticales, trait de rupture et ambiance rétro-web 2012, sans texte, sans logo."

BIN
content/interets/informatique/2012/02/29/hadopi-ne-sert-a-rien/images/cover.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 134 KiB

53
content/interets/informatique/2012/02/29/hadopi-ne-sert-a-rien/index.md Normal file
View File

@@ -0,0 +1,53 @@
---
comments_url: https://com.richard-dern.fr/post/529
cover: images/cover.png
date: '2012-02-29 20:36:00'
links:
- lang: fr
name: Page d'origine sur Archive.org
url: https://web.archive.org/web/20120302060425/http://ingnu.fr/2012/02/29/hadopi-ne-sert-a-rien/
tags:
- Internet
- Censure
- Google
- Paypal
title: Hadopi ne sert à rien
weather:
humidity: 97
illuminance: 0.0
precipitations: false
pressure: 1022.1
source:
- open-meteo
temperature: 7.4
wind_direction: 76
wind_speed: 10.7
---
J'adore la classe avec laquelle la France est capable de se ridiculiser.
Le 19 janvier dernier, le FBI a fait fermé le site MegaUpload, site basé en dehors des États-Unis, donc "hors de la juridiction "du FBI. Hors d'atteinte même, normalement des États-Unis. Et pourtant, quand les lobbys montrent les crocs, on soulève des montagnes pour satisfaire leurs caprices.
D'après une information relayée par Numerama, la fermeture de MegaUpload aurait incité la moitié des téléchargeurs à arrêter. Ça, et puis le fait que RapidShare et compagnie ont pris peur, taillé dans le gras, ne laissant plus rien aux pirates de la culture. Le FBI rôde, et tel un rapace, il plane au-dessus d'eux, et on ne peut pas prévoir quand il va attaquer.
Ceci dit, les États-Unis (ou plus précisément, certaines entreprises étasuniennes) ont compris qu'il n'y avait même pas besoin de sortir l'arsenal juridique pour faire fermer un site. Faut taper là où ça fait mal. Pas les noyaux non, le porte-feuille.
C'est ainsi que le français UpToBox est en train de couler, PayPal et Google l'ayant privé de ses ressources publicitaires. Deux des plus gros acteurs d'Internet qui commencent à faire la loi (Google et eBay, je rappelle que PayPal appartient à eBay). Et ils sont américains. Inutile de dire qu'il y a fort à parier que ce genre d'opérations se multiplient dans un avenir proche.
Ça, c'est gouverner par la terreur. Ça coûte pas cher, il suffit d'une action pour calmer tout le monde. Genre Hiroshima. À la States quoi.
On parle d'Hadopi depuis près de trois ans. À raison d'une dizaine de millions d'euros claqués par an, ça fait déjà trente millions qui ont été dépensé. Mais c'est notre cher Nicolas Sarkozy, et notre cher Frédéric Mitterand qui vont s'approprier la réussite des États-Unis, puisque [la Hadopi a réduit de 35% le piratage en France](https://web.archive.org/web/20120302060425/http://reflets.info/grace-a-hadopi-le-piratage-a-recule-de-35-mais-il-faut-aller-plus-loin-et-sattaquer-au-streaming-sarkozy/).
Et encore, 10 millions par an, c'est un chiffre politiquement correct. Je cite Mr Hervé Féron:
> Quel sera le coût de l'identification des adresses IP? Les barèmes sur les réquisitions judiciaires en matière d'internet n'existent pas encore - ce qui permet de douter de l'application de la loi "Hadopi 2 "- mais dans le code de procédure pénale, le tarif applicable à l'identification d'un abonné ADSL est de 8,50 euros. Si l'on table, comme les majors de la musique et du cinéma, sur 50 000 identifications quotidiennes - chiffre confirmé par le directeur général de la fédération française des télécoms (FFT) - cela ferait 425 000 euros par jour, soit plus que les subventions octroyées annuellement à la production cinématographique, que la Hadopi est censée défendre!
Ça, c'est gouverner à la française. On fait raquer tout le monde pour de la merde, et on fait passer ça pour la solution du siècle.
Je ne parle pas des magouilles sous-jacentes au business Hadopi, TMG et Amesys, un site comme [Reflets](https://web.archive.org/web/20120302060425/http://reflets.info/) est bien mieux documenté sur le sujet que moi.
Au final, une somme d'argent colossale est attribuée à des fumisteries. NOTRE argent, puisque c'est nous qui finançons ce genre de conneries. En payant des impôts, on se rend responsables du bridage, du filtrage, de la censure dans les pays qui ont acheté ces solutions logicielles à la France.
Au moins, aux États-Unis, la chasse aux pirates coûte moins cher vu que ce ne sont que quelques grosses entreprises qui s'en chargent: ce n'est même plus l'État qui paye. Loin de moi l'idée d'approuver ce que fait Google ou eBay, vous savez quelle est ma position sur le premier. Mais ce n'est pas le contribuable qui paye.
Parmi les solutions qui s'offrent à nous pour éviter notre escalade (ou notre chute...) vers un Internet contrôlé par quelques grosses mafias: [s'abstenir de voter](https://web.archive.org/web/20120302060425/http://ingnu.fr/2012/02/29/pourquoi-il-est-vital-de-ne-plus-voter/), et basculer massivement et rapidement vers un Internet décentralisé.