Sélectionner une page

Table des matières

ADSL

L’ADSL (ou Asymmetric Digital Subscriber Line), ou communication par ondes hertziennes, est un mode de transmission et de réception de données numériques utilisé sur une téléphonie conventionnelle. Le principe est simple : la communication se fait via inaudibles sons (aigus ou graves) entre les modems ADSL des clients et les DSLAMs installés dans le central téléphonique.

Comme son nom l’indique, la communication asymétrique est unidirectionnelle : cela implique que le débit de transmission est différent du débit de réception. Dans le cas de l’ADSL, le débit de transmission est nettement inférieur au débit de réception, avec des rapports allant de un à quatre, voire moins.

Cette restriction est critique pour l’auto-hébergement car elle limite fortement l’éventail des possibilités de diffusion, comme le démontre le serveur de fichiers public ou un site de contenu multimédia à fort trafic qui ne peut être fourni.

Un site web unique ne nécessite pas la même quantité de données qu’un site web d’entreprise typique. Pour les sites personnels, cependant, il est important de garder à l’esprit que ce faible taux de transfert reste plus qu’adéquat. Ce faible taux de transmission n’a aucune incidence sur les services pour lesquels les données doivent être transmises dans la même quantité de toute façon – tels que le courrier électronique et la messagerie instantanée – qu’ils soient hébergés par eux-mêmes ou non.

Apache HTTP Server

Le serveur Web le plus populaire est le serveur HTTP Apache, qui est utilisé par plus de la moitié des sites Web du monde.

Comment installer un serveur Apache HTTP sous Debian ?

Commencez par installer le paquet correspondant. Sous Debian, par exemple, il s’appelle Apache2 :

# aptitude install apache2

Comment configurer Apache HTTP Server ?

Le serveur HTTP Apache est géré à partir du répertoire /etc/apache2/ et de ses sous-répertoires. En fonction de leur objectif, les distributions Debian et leurs dérivés ont divisé la configuration en plusieurs fichiers :

  • apache2.conf le fichier de configuration de base ;
  • httpd.conf l’ancien fichier de configuration unique, aujourd’hui inutilisé ;
  • conf.d/ un répertoire contenant les fichiers de configurations d’applications web installées par des paquets Debian additionnels (un webmail ou un wiki, par exemple) ;
  • mods-available/ un répertoire contenant les fichiers de chargement et de configuration de tous les modules additionnels disponibles, activés ou non ;
  • mods-enabled/ un répertoire dans lequel on lie les fichiers de chargement et de configurations des modules que l’on souhaite activer ;
  • sites-available/ un répertoire dans lequel on place les fichiers de définition de tous les sites web indépendants, activés ou non ;
  • sites-enabled/ un répertoire dans lequel on lie les fichiers de définition des sites web que l’on souhaite activer.

À quoi servent les modules Apache ?

Le serveur Apache HTTP 2.2 vous permet d’utiliser des modules complémentaires qui offrent des capacités accrues en fonction de vos besoins. Le pack principal du serveur Apache HTTP comprend déjà certains modules, dont plusieurs sont déjà activés.

Sous Debian et dérivées, pour activer configurer un module, on édite son fichier de configuration /etc/apache2/mods-available/. Ensuite, pour l’activer ou le désactiver, on utilise les commandes suivantes, avant de redémarrer le serveur web :

# a2enmod  <module>       # activer un module
# a2dismod <module>       # désactiver un module
# /etc/init.d/apache2 restart

Où héberger votre site Web principal sur votre serveur HTTP Apache ?

L’emplacement principal desservi par le serveur HTTP Apache, que l’on peut atteindre en allant sur http://serveur/, est /var/www/. Par conséquent, vous pouvez y héberger votre site Web principal.

Où héberger vos sites Web personnels sur votre serveur HTTP Apache ?

Le module userdir permet aux utilisateurs d’un système de définir leur site personnel. Pour l’utiliser, commencez par activer ce module selon la méthode correspondant à votre distribution. Ensuite, placez simplement votre site personnel dans votre répertoire ~/public_html/, en le créant si nécessaire : il sera alors disponible à l’adresse http://serveur/~identifiant/.

Quel rapport entre le serveur Apache HTTP et PHP ?

Le serveur HTTP Apache est fréquemment utilisé en conjonction avec le langage PHP. Pour ce faire, vous devez installer le module approprié.

Arch Linux

Arch Linux est une distribution communautaire binaire optimisée pour les architectures i686 et x86_64 ayant comme but de rester le plus fidèle possible à la philosophie KISS.

Les principales caractéristiques de cette distributions sont :

  • rolling-release, avec les avantages et inconvénients que ça apporte:
  • paquets très à jour;
  • pas de mise à jour complète de la distribution tous les 6 mois/un an, une installation est nécessaire ;
  • pas de blocages de paquets dans un état stable qui ne bouge pas;
  • mais un très léger risque de se retrouver avec un logiciel qui bug suite à une mise à jour ;

Qu’est-ce que l’esprit « Kiss » ?

  • système et scripts d’init simples et aisément compréhensibles ;
  • les paquets sont livrés de manière “vanilla”, le moins possible de patch et d’adaptation de la part de la distribution, (fichiers de configuration notamment);
  • système de paquet simple, la création de paquets personnels grandement facilitée;
  • distribution minimaliste: l’utilisateur construit lui-même son écosystème logiciel à partir d’un système initial vierge de toute application.

En général, cette distribution est la meilleure pour ceux qui désirent un contrôle complet du système au prix d’un investissement de départ qui peut être un peu plus élevé que sur d’autres distributions. Les fichiers de configuration des applications ne sont pas « prémâchés », ce qui signifie que l’utilisateur doit les comprendre et lire la documentation.

Il est également intéressant de noter que dans certaines régions, une pénurie de paquets est signalée (par exemple la surveillance), mais la simplicité du développement des paquets et le dépôt communautaire peuvent souvent compenser cette pénurie.

CoralCDN

Lorsqu’un site web auto-hébergé est soumis à un grand nombre de visites, il peut rapidement s’engorger, tant en termes de capacité matérielle du serveur que de connexion. Pour surmonter ce problème, nous pouvons utiliser des serveurs proxy avec une plus grande connectivité. Cela offrira une certaine marge de manœuvre à notre serveur personnel ainsi qu’à la ligne qui le supporte.

Il existe plusieurs fournisseurs de proxys sur Internet, et ils sont fréquemment partagés (plusieurs proxys sont dispersés dans le monde). Nous faisons référence à un Content Delivery Network ou CDN. Akamai est le plus connu car il est le plus populaire et le plus coûteux, adressant des sites de plusieurs millions de pages. Vous pouvez utiliser un CDN gratuit tel que CoralCDN, qui est hébergé sur le réseau de recherche PlanetLab et offre une couverture mondiale.

Comment installer CoralCDN ?

Pour utiliser un CDN, il suffit d’ajouter nyud.net au nom de domaine de notre site. En conséquence, l’adresse de la page accessible via CoralCDN est https://auto-hebergement.fr.nyud.net/dokuwiki/distribution/coralcdn. Lors de leur première demande, les visiteurs recevront et renverront le fichier texte à l’adresse https://auto-hebergement.fr/dokuwiki/distribution/coralcdn, par exemple.

Par défaut, CoralCDN conserve la page en mémoire pendant 12 heures. Cette durée est personnalisable en fonction de la valeur du champ HTTP Expire.

On trouve sur le site officiel de CoralCDN, une page expliquant comment mettre en place des configurations plus originales, par exemple en redirigeant automatiquement tous les visiteurs sur CoralCDN ou tous les visiteurs en provenance de certains sites.

CRON

CRON est un planificateur de tâches basé sur le temps dans les systèmes d’exploitation de type Unix. Le nom cron vient du mot grec pour le temps, χρόνος (chronos).

Cron permet aux utilisateurs de planifier des travaux (commandes ou scripts shell) à exécuter automatiquement à une certaine heure ou date. Il est généralement utilisé pour la maintenance ou l’administration du système, mais peut également être utilisé à d’autres fins, comme l’envoi de notifications par courriel.

Cron est généralement utilisé pour automatiser les tâches de maintenance ou d’administration du système, mais il peut aussi être utilisé à d’autres fins, comme l’envoi de notifications par courriel. Cron est disponible sur la plupart des systèmes d’exploitation de type Unix, y compris Linux et macOS. Le planificateur de tâches de Windows peut également être utilisé pour planifier des tâches sur les systèmes Windows.

Cron est un service permettant a un administrateur d’un système GNU/Linux d’exécuter régulièrement une tâche. Il est fréquemment utilisé dans les tâches d’administrations d’un système afin, par exemple, de lancer un script à heures fixes.

Cron est généralement présent dans n’importe quel système de base et est opérationnel tel quel.

Comment fonctionne les CRONs et comment les configurer ?

L’ensemble des tâches exécutées par ce service sont décrites dans le fichier /etc/crontab.

Pour chaque tâche que le service doit lancer, une ligne doit être créée et respecter le format suivant :

m h   dom mon dow   user   command

avec :

  • m : le nombre de minutes ;
  • h : le nombre d’heures ;
  • dom : le jour du mois (day of month) ;
  • mon : le numéro du mois (month) ;
  • dow : le jour de la semaine (day of week) ;
  • user : le nom de l’utilisateur qui doit lancer la commande ;
  • command : la commande à lancer ;

Chaque champs doit être remplis soit avec un nombre, soit avec une expression. Un astérisque (*) correspond à toutes les valeurs possibles d’un champ.

Par exemple :

0 4    *  *  *      robert     /home/robert/script_backups.sh

Cette ligne lancera chaque jour de la semaine à 4h00, le script situé à l’emplacement /home/robert/script_backups.sh en utilisant les droits de l’utilisateur robert.

De la même manière, on pourra utiliser les 5 premiers champs suivants pour lancer un script chaque minute :

* *    *  *  *      robert     /home/robert/script_backups.sh

Ou encore, chaque heure :

0 *    *  *  *      robert     /home/robert/script_backups.sh

L’expression */x (avec x, un entier) signifie “toutes les x périodes”. Par exemple, pour lancer une commande 3 fois par jour (toutes les 8 heures) :

0 */8 * * * robert /home/robert/script_backups.sh

Expression spéciales pouvant être utilisées pour configurer vos CRONs

Il existe d’autres expression particulières permettant de remplacer ces 5 champs :

  • @hourly : chaque heure ;
  • @daily : chaque jour à minuit ;
  • @weekly : chaque semaine, le lundi à minuit ;
  • @reboot : à chaque démarrage du serveur ;

Par exemple :

@weekly      robert     /home/robert/script_backups.sh

Cyrus-SASL (identification)

Quelle est l’utilité de l’authentification lorsque l’on gère un système auto-hébergé ?

Si vous souhaitez utiliser l’authentification avec Postfix afin que d’autres ordinateurs puissent accéder à votre serveur de messagerie à partir des réseaux pointés par mydestination dans votre configuration Postfix, vous devez installer un serveur d’authentification car il n’est pas pris en charge par Postfix.

Les solutions les plus courantes sont :

  • Dovecot offre des fonctionnalités supplémentaires en plus d’être un MDA ou un serveur POP3/IMAP, comme par exemple prendre la fonction d’un autre système.
  • Cyrus-SASL

Comment installer et configurer Cyrus-SASL sur un serveur Debian ?

Le paquet sasl2-bin de Debian s’occupe de ce service :

# aptitude install sasl2-bin
# adduser postfix sasl

Le démon salsauthd n’est pas présent par défaut, il faut l’activer de cette manière :

# cp /etc/default/saslauthd /etc/default/saslauthd.dist
# vim /etc/default/saslauthd

    START=yes
    OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"

Le réglage de la valeur OPTIONS permet de changer la valeur du chemin qui mène au socket surveillé par le serveur saslauthd pour surveiller les connexions. Il convient de le changer pour Postfix car ce dernier est “chrooté” (il est démarré dans le répertoire /var/spool/postfix/ dans lequel il est enfermé pour une question de sécurité).

On peut dès lors créer une configuration SASL pour Postfix en créant le fichier suivant :

# vim /etc/postfix/sasl/smtpd.conf

    pwcheck_method: saslauthd
    mech_list: plain

On démarre ensuite le serveur :

invoke-rc.d saslauthd start

Il faut indiquer au serveur Postfix que l’on souhaite utiliser SASL. Pour cela, on ajoute à la configuration main.cf les informations suivantes :

# vim /etc/postfix/main.cf

    smtpd_sasl_auth_enable = yes
    smtpd_sasl_path = smtpd
    smtpd_sasl_security_options = noanonymous
    broken_sasl_auth_clients = yes
    smtpd_sasl_authenticated_header = yes

Le paramètre smtpd_sasl_path permet de désigner le socket SASL qui a été créé précédemment.

Pour que l’authentification soit possible, il ne reste qu’à recharger la configuration du serveur de messagerie :

# invoke-rc.d postfix reload

Davical

Davical est un serveur qui permet de partager des calendriers et des listes contacts, un peu à l’image de Google calendar. Il existe des protocoles standards pour partager des fichiers, des calendriers et des listes de contacts. Davical repose sur les protocoles CalDav et CardDav. CalDav permet d’échanger des calendriers tendit que CardDav permet de transférer des listes de contacts. Ces deux protocoles reposent sur WebDav qui permet de transférer de simples fichiers. Pour finir, WebDav repose sur le très célèbre protocole, HTTP.

Les utilisateurs peuvent interagir entre eux et collaborer sur des activités grâce à l’intégration de Groupon et Google Maps de Mixi dans RoomDavical. Il permet aux gestionnaires de gérer de nombreux utilisateurs, des calendriers et des listes de contacts par utilisateur. L’interface web du serveur est utilisée pour toute l’administration. Les calendriers et les listes de contacts peuvent être trouvés à des URLs tels que : http://serveur/compte/calendrier, http://serveur/compte/contacts, ou https// Puisqu’il est possible d’utiliser https au lieu de http pour ces urls (ce qui n’est pas nécessaire), on dira toujours cela quand on utilise cet outil !

Comment installer Davical ?

Premier pré-requis : PostgreSQL

Si vous envisagez d’utiliser Davical, assurez-vous que votre base de données est correctement configurée avant de poursuivre. Même si Davical ne fait que sauvegarder les calendriers et les listes de contacts dans de simples fichiers, il le fait via une base de données PostgreSQL.

Pour utiliser une base de données PostgreSQL, après qu’elle ait été correctement installée, vous devez d’abord la configurer pour permettre l’accès à Davical. Pour ce faire, ajoutez les lignes suivantes :

local davical davical_app trust
local davical davical_dba trust

Au début du fichier /etc/postgresql/#votre_version#/main/pg_hba.conf. Si vous ne mettez pas ces lignes au début du fichier, l’installation de Davical ne fonctionnera pas ! Ces deux lignes autorisent l’utilisateur “davical_dba” à créer la base de données “davical” et de l’utiliser comme bon lui semble en locale.

N’oubliez pas de relancer le serveur postgres.

/etc/init.d/postgres restart

Deuxième pré-requis : Apache

Comme il est écris dans l’introduction, Davical est accessible depuis le web. Il faut donc que apache soit correctement installé et configuré.

Installation du packet Davical :

aptitute install davical

Comment configurer Davical avec Virtual Host ?

Le paquet postgres davical a également installé un script qui vous permet de générer automatiquement les tables appropriées dans postgres. Pour exécuter le script correctement, utilisez la commande suivante :

su postgres -c /usr/share/davical/dba/create-database.sh

Si vous n’avez pas configuré postgres correctement, le script vous donnera des difficultés.

Maintenant il faut configurer apache pour pouvoir accéder à Davical depuis le web. Si vous utilisez le système de Virtual Host, vous pouvez vous baser sur cette configuration :

<VirtualHost *:443>
  RewriteEngine on
  SSLEngine On
  SSLCertificateFile /etc/ssl/private/cert.pem
  DocumentRoot /usr/share/davical/htdocs
  DirectoryIndex index.php index.html
  ServerName davical.servername
  ServerAlias davical.servername
  Alias /images/ /usr/share/davical/htdocs/images/
  <Directory /usr/share/davical/htdocs/>
    AllowOverride None
    Order allow,deny
    Allow from all
  </Directory>
  php_value include_path /usr/share/awl/inc
  php_value magic_quotes_gpc 0
  php_value magic_quotes_runtime 0
  php_value register_globals 0
  php_value error_reporting "E_ALL & ~E_NOTICE"
  php_value default_charset "utf-8"
</VirtualHost>

Comment configurer Davical avec un autre système que Virtual Host ?

Si vous utilisez Davical, voici comment l’activer : Davical est livré avec son propre logiciel de gestion de la configuration. (Vous n’êtes pas obligé d’utiliser https si vous ne le souhaitez pas.) Cette méthode fonctionne que vous utilisiez ou non le système Virtual Host.

Alias /cal/ /usr/share/davical/htdocs/

Quoi qu’il en soit, n’oubliez pas de redémarrer Apache.

/etc/init.d/apache2 restart

Vous pouvez maintenant vous connecter à la page d’accueil de davical en utilisant un navigateur web. Selon la façon dont vous l’avez configuré, soit à davical.servername ou à servername/cal.

Vous pouvez récupérer le mot de passe de l’administrateur numérique (qui est créé automatiquement lors de la configuration) à l’aide de cette commande :

su postgres
psql davical -c 'select username, password from usr;'

Attention, les deux caractères ** au début du mot de passe ne sont pas à prendre en compte !

Comment utiliser l’interface Web de Davical ?

L’interface web de davical est assez basique, mais elle vous permet d’accomplir toutes vos tâches. Par défaut, vous êtes déjà connecté en tant que compte administrateur. Je vous recommande de changer le mot de passe de ce compte à partir de l’onglet « Informations utilisateur » puis « Mes informations ».

Ensuite, je vous recommande de configurer au moins un compte supplémentaire qui n’est pas un administrateur et qui contient les différents calendriers et listes de contacts.

Pour chaque nouveau contact, un calendrier est généré par défaut. Ce calendrier se trouve à l’adresse suivante : http://adresseDuServerDavical/caldav.php/nomDucompte/home. Le chemin par défaut du calendrier principal est /home.

Cependant, un nouvel utilisateur ne se verra pas automatiquement attribuer une liste de contacts. Vous devez la créer manuellement. Créez une nouvelle collection en allant dans « Informations utilisateur » puis « Mes informations » et en sélectionnant « Collections de comptes » Décochez ensuite la case « Est un calendrier », cochez la case « Est un carnet d’adresses » et remplissez les espaces vides si nécessaire. Vous obtiendrez ainsi votre nouvelle collection de contacts. Pour visualiser cette liste, allez dans le chemin que vous avez spécifié lors de sa création.

Quels sont les logiciels clients compatibles avec Davical ?

L’évolution est un excellent outil pour Davical. Il ne vous reste plus qu’à lui donner l’adresse du paragraphe précédent, et il aura tous ses rendez-vous et contacts sur votre téléphone.

Thunderbird avec le plugin Lightning fonctionne bien avec les calendriers de Davical. La liste des contacts, par contre, est encore un peu compliquée.

Veuillez noter que les clients Android qui prennent en charge les protocoles CardDav et CalDav peuvent également accéder aux instances locales du calendrier et des carnets d’adresses Davical.

Debian

Le système d’exploitation « le plus rapide, le plus sûr et le plus stable » est Debian GNU/Linux, une distribution Linux qui a de nombreuses caractéristiques :

  • Debian a été réalisée pas une communauté (et non une entreprise) ;
  • Contient des textes fondateurs précis (Constitution, contrat social, principes du logiciel libre) ;
  • Est disponible pour 13 architectures matérielles (y compris pour des téléphones, par exemple) ;
  • A une grande stabilité ;
  • Permet d’appliquer des règles techniques fortes pour l’intégration des logiciels (pour entrer dans Debian, un logiciel doit se conformer à des normes Debian, et être suffisamment documenté, par exemple).

En pratique, utiliser Debian permet :

  • d’avoir un système stable ;
  • de bénéficier d’une maintenance de sécurité assez longue (à peu près deux ans et demi) ;
  • d’avoir un système homogène (toute la configuration est placée dans /etc, par exemple).

En revanche, Debian ne permet pas :

  • d’utiliser les dernières versions de vos logiciels préférés.

Comment installer Debian sur votre serveur ?

Il existe plusieurs méthodes pour installer Debian, en fonction de vos compétences. Le manuel d’installation couvre toutes ces approches en détail.

Depuis un CD :

  • La manière la plus populaire d’installer Debian était d’utiliser un CD. Maintenant, il est possible de le faire depuis un fichier .ISO (fichier bootable disponible et téléchargeable dans le Cloud). Pour ce faire, suivez ces étapes :
  • téléchargez une petite image de CD sur la page de téléchargement de Debian ou un fichier .ISO depuis le Cloud ;
  • gravez-la sur un disque vierge ou bootez directement le fichier .ISO ;
  • démarrez dessus ;
  • suivez les instructions de l’installateur.

Depuis une clé USB :

Si vous n’avez pas de lecteur de CD, vous pouvez installer Debian depuis une clé USB. Mais il faut pour cela disposer d’un système Unix pour préparer la clé USB, selon les instructions données dans le guide d’installation :

  • préparer la clef USB ;
  • démarrer dessus ;
  • suivre les instructions de l’installateur.

Depuis un système GNU/Linux existant :

Si votre serveur a démarré un système GNU/Linux préinstallé et le chargeur d’amorçage GRUB, vous pouvez l’utiliser pour lancer l’installateur Debian. Pour ce faire, suivez les étapes suivantes :

  • téléchargez un noyau (linux) et un initrd (initrd.gz) sur la page de l’installateur par réseau pour x86 ou pour amd64 selon votre processeur ;
  • placez-les dans un répertoire comme /boot/debian-installer ;
  • redémarrez ;
  • à l’écran de GRUB, appuyez sur [c] pour pouvoir saisir des commandes à la main :
kernel /boot/debian-installer/linux
initrd /boot/debian-installer/initrd.gz

Après cela, suivez simplement les instructions de l’installateur.

Conseils pour débuter avec Debian

Si vous débutez, les tutoriels Debian sont un bon point de départ. Voici quelques éléments à prendre en compte avant de démarrer avec Debian.

La gestion des logiciels installés se fait avec le logiciel Aptitude :

# aptitude update && aptitude safe-upgrade      # met à jour le système
# aptitude install LOGICIEL                     # installe le LOGICIEL choisi

Pour installer un service (le courrier avec Postfix, par exemple), pensez à consulter :

  • le contenu du répertoire /usr/share/doc/LOGICIEL/,
  • le wiki Debian disponible sur le Web;

N’hésitez pas à consulter les pages de manuel, pour chaque commande ou fichier de configuration :

man postfix        # renvoie vers d'autres pages du manuel
man 5 postconf     # détail de la configuration de Postfix
man interfaces     # fichier de configuration du réseau

DKIM (DomainKeys Identified Mail)

La norme DomainKeys Identified Mail (DKIM) est une méthode d’authentification du nom de domaine de l’expéditeur d’un courriel. Elle permet aux services d’être plus responsables et de lutter contre la fraude aux adresses électroniques.

Le serveur qui envoie le message le signe numériquement en utilisant une clé liée à son nom de domaine.

Le serveur qui reçoit le message résout à l’aide du DNS la clé publique correspondant au nom de domaine de l’expéditeur, et vérifie la présence d’une éventuelle signature cryptographique :

  • s’il y a une signature valide, le message est considéré comme authentifié1) ;
  • s’il n’y a aucune signature :
  • si le nom de domaine précise que tous ses messages sont censés être signé, le message peut être considéré comme frauduleux,
  • si le nom de domaine ne précise pas de politique particulière, le message peut être considéré comme non authentifié ;
  • s’il y a une signature invalide, le message peut être considéré comme frauduleux, c’est à qu’il s’agit d’un faux ou qu’il a été modifié en chemin.

Comprendre la syntaxe des clés DKIM

Un nom de domaine peut être lié à de nombreuses clés DKIM, chacune d’entre elles étant associée à un sélecteur distinct : cela est utile lorsque le même nom de domaine est utilisé par plusieurs services ; sinon, un sélecteur par défaut sera utilisé. Les enregistrements DNS de ces clés DKIM d’un nom de domaine sont publiés au format TXT.

Par exemple, l’enregistrement suivant montre la clé DKIM pour le sélecteur par défaut du nom de domaine exemple.com :

default._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS…wIDAQAB"

Cet enregistrement se compose des éléments suivants dans le nom de domaine :

  • default est le sélecteur, qui identifie cette clef particulière — il pourrait y en avoir d’autres pour example.com,
  • _domainkey, obligatoire, permet de distinguer ce nom de domaine d’un nom d’hôte ou de service quelconque,
  • example.com indique le nom de domaine administratif auquel cette clef appartient ;

Cet enregistrement se compose des éléments suivants dans le contenu :

  • v=DKIM1 indique la norme utilisée : DKIM, version 1,
  • k=rsa indique l’algorithme de la clef,
  • p=… indique la clef elle-même.

La politique de signature du DKIM, c’est quoi ?

Un nom de domaine peut publier une politique de signature ADSP, qui précise comment il utilise DKIM et d’autres mesures de sécurité, comme la recherche de logiciels malveillants. Par exemple, un enregistrement TXT peut contenir les informations suivantes :

_adsp._domainkey.example.com. TXT "dkim=all"

Cet enregistrement se compose des éléments suivants dans le nom de domaine :

  • _adsp._domainkey, obligatoire, indique qu’il s’agit d’une politique ADSP,
  • example.com indique le nom de domaine administratif auquel cette politique correspond ;

dans le contenu, dkim=all indique que tous les message sont censés être signés. Les valeurs possibles sont :

  • unknown les messages peuvent être ou ne pas être signés2),
  • all tous les messages sont censés être signés,
  • discardable les messages non signés ou avec une signature incorrecte peuvent être jetés.

Exemple concret du fonctionnement d’un clé DKIM

Voici le genre de requêtes DNS faites par le serveur SMTP destinataire pour récupérer la clef publique de l’émetteur et sa politique (en supposant que le courriel est issu du domaine example.com :

# dig default._domainkey.example.com TXT
;; ANSWER SECTION:
default._domainkey.example.com. 10800 IN TXT    "v=DKIM1\; k=rsa\; p=MIGfMA0GCS…wIDAQAB"

# dig _adsp._domainkey.example.com TXT
;; ANSWER SECTION:
_adsp._domainkey.example.com. 10800 IN  TXT     "dkim=all"

Avant la mise en place d’une politique DKIM, les serveurs SMTP qui recoivent un courriel du domaine example.com ajouteront cet en-tête au courriel :

Authentication-Results: smtp.destinataire.example.org from=example.com;
domainkeys=neutral (no sig); from=example.com; dkim=neutral (no sig)

Après la mise en œuvre d’une politique DKIM :

Authentication-Results: smtp.destinataire.example.org from=example.com;
domainkeys=neutral (no sig); from=example.com; dkim=pass (ok)

Comment utiliser DKIM ?

DKIM peut être utilisé de deux façons :

  • pour vérifier les signatures DKIM des messages reçus ;
  • pour signer les messages envoyés.

Pour ce faire, vous aurez besoin d’une extension du serveur de messagerie. Dans les deux cas, cela nécessite l’utilisation d’un module DKIM spécialisé. OpenDKIM est l’implémentation DKIM libre la plus avancée car il s’agit d’un module milter qui peut être utilisé avec la plupart des serveurs de messagerie actuels.

Comment intégrer OpenDKIM à votre serveur de courrier ?

OpenDKIM doit être activé sur votre serveur. Assurez-vous que OpenDKIM est en cours d’exécution. Le reste dépend de votre fournisseur de messagerie.

Comment configurer DKIM dans Postfix sur un serveur Debian ?

Comme le suggère le fichier de configuration d’OpenDKIM, il existe certaines situations dans lesquelles un serveur SMTP Postfix peut être exécuté dans un chroot. Pour cette raison, il est important de permettre à OpenDKIM d’écouter sur une socket dans le chroot. Le fichier /etc/default/opendkim sur Debian contient la ligne suivante :

SOCKET="local:/var/spool/postfix/var/run/opendkim/opendkim.sock" # Postfix' chroot

Après cela, créez le répertoire en question puis relancez OpenDKIM :

# install -o opendkim -g opendkim -d /var/spool/postfix/var/run/opendkim/
# service opendkim restart

Configurez enfin Postfix pour qu’il utilise OpenDKIM, dans /etc/postfix/main.cf :

smtpd_milters = unix:/var/run/opendkim/opendkim.sock
non_smtpd_milters = unix:/var/run/opendkim/opendkim.sock

Nous allons utiliser OpenDKIM pour sécuriser le courrier sortant en le chiffrant et valider la signature de l’expéditeur sur le courrier entrant, le tout en utilisant notre socket. Ce devoir est nécessaire pour le courrier délivré par le daemon smtpd ou envoyé par sendmail, ainsi les deux directives placées dans la configuration de Postfix sont appropriées à cet effet.

Finalement, ajoutez Postfix au groupe d’OpenDKIM pour qu’il ait le droit d’écrire dans son socket, puis relancez-le :

# adduser postfix opendkim
# service postfix restart

Comment mettre en place votre clé DKIM ?

1. Générer la paire de clés

Placez-vous dans un répertoire dédié, par exemple /etc/dkim/example.com, puis utilisez la commande opendkim-genkey, en l’adaptant à votre propre nom de domaine :

opendkim-genkey -d example.com

Cela créera deux fichiers :

  • default.txt est la clef publique, à publier dans votre zone DNS,
  • default.private est la clef privée, à conserver sur votre serveur qui l’utilisera pour signer les messages envoyés.

Comment configurer OpenDKIM ?

OpendDKIM se configure dans le fichier /etc/opendkim.conf. Si vous n’utilisez qu’un seul nom de domaine, la configuration sera assez simple :

Domain                 example.com
KeyFile                /etc/dkim/example.com/default.private
Selector               default

Vérifiez qu’OpenDKIM a accès au fichier de clef privée. Je vous conseille pour cela d’autoriser sa lecture par le groupe opendkim :

# chgrp opendkim /etc/dkim/example.com/default.private
# chmod 640 /etc/dkim/example.com/default.private

Puis relancez OpenDKIM :

# service opendkim restart

Comment tester si votre clé DKIM fonctionne correctement ?

Essayez d’envoyer un message à une adresse externe avant de télécharger votre clé DKIM. Vérifiez que le message comporte un en-tête DKIM-Signature après sa livraison.

Publier votre clé et votre politique DKIM publiquement

À ce stade, vous devez simplement publier l’enregistrement de votre clé publique – le fichier default.txt généré précédemment – dans votre zone DNS.

Vous pouvez créer un enregistrement de politique ADSP indiquant que tous vos messages sont censés être signés :

_adsp._domainkey.example.com. TXT "dkim=all"

Testez à nouveau DKIM

Essayez maintenant d’envoyer un message vers une adresse externe dont le serveur vérifie les signatures DKIM, par exemple chez Yahoo! ou Google. Une fois le message reçu, vérifiez le contenu de l’en-tête Authentication-Results : il doit contenir « dkim=pass ».

Comment signer les e-mails pour plusieurs noms de domaine ?

Pour signer le courrier pour plusieurs noms de domaine, vous devrez apporter quelques modifications au fichier de configuration OpenDKIM que vous avez créé précédemment, mais il ne suffira pas de reproduire les lignes de configuration d’OpenDKIM. Au lieu de cela, la déclaration de chaque domaine doit être remplacée par un tableau qui fait référence à la clé privée à utiliser pour ce domaine. Voici un exemple :

Dans /etc/opendkim.conf :
KeyTable refile:/etc/dkim/keytable
SigningTable refile:/etc/dkim/signingtable
/etc/dkim/keytable
default._domainkey.example.com example.com:default:/etc/dkim/example.com/default.private
default._domainkey.example.org example.org:default:/etc/dkim/example.org/default.private

Dans /etc/dkim/signingtable :
*@example.com default._domainkey.example.com
*@example.org default._domainkey.example.org

La création de la nouvelle clef privée, les droits à lui donner et la diffusion de la clef privée dans la zone du second nom de domaine ne change pas par rapport à ce qui a été expliqué plus tôt.

Dovecot

Dovecot est un serveur de boîtes aux lettres libre conçu pour être sécurisé. Il utilise moins de mémoire que les autres serveurs de messagerie et est donc plus rapide. Dovecot dispose d’un grand nombre de fonctionnalités que l’on ne trouve dans aucun autre serveur de messagerie.

Dovecot est utilisé par de nombreuses organisations car il est plus sûr que les autres serveurs de messagerie. Il est également plus rapide et utilise moins de mémoire. Dovecot dispose de nombreuses fonctionnalités que l’on ne trouve dans aucun autre serveur de messagerie.

Comment installer Dovecot sur votre serveur Debian ?

Commencez par installer Dovecot. Dans certaines distributions, comme Debian, les services POP3 et IMAP sont fournis dans des paquets séparés :

# aptitude install dovecot-pop3d dovecot-imapd

Comment configurer Dovecot sur Debian ?

La configuration par défaut de Dovecot est déjà fonctionnelle, mais peut être affinée. Dovecot 1 se configure dans le fichier /etc/dovecot/dovecot.conf, et Dovecot 2 dans les fichiers du répertoire /etc/dovecot/conf.d, qui sont très bien documenté par leurs commentaires.

Voici quelques modifications utiles à apporter, dans /etc/dovecot/dovecot.conf pour Dovecot 1 :

# Écouter en IPv6 et en IPv4 (par défaut, Dovecot n'écoute qu'en IPv4).
listen = [::]
 
# Emplacement de la boîte aux lettre du courrier entrant et des boîtes aux lettres secondaires.
mail_location = mbox:~/Mail:INBOX=/var/mail/%u

et dans /etc/dovecot/conf.d/10-mail.conf pour Dovecot 2) :

# Emplacement de la boîte aux lettre du courrier entrant et des boîtes aux lettres secondaires.
mail_location = mbox:~/Mail:INBOX=/var/mail/%u

Après cela, vous pouvez recharger Dovecot :

/etc/init.d/dovecot reload

Puis essayer de vous y connecter avec votre logiciel de messagerie préféré, en définissant un compte POP3 ou IMAP utilisant votre serveur, votre identifiant et votre mot de passe Unix.

Duplicity

Duplicity est un logiciel de sauvegarde qui peut être utilisé pour des sauvegardes compressées, complètes et différentielles. Il prend en charge la copie locale ainsi que de nombreux protocoles comme FTP, IMAP, RSync, Amazon S3, WebDAV, etc. Duplicity est disponible pour Windows, macOS et Linux

Duplicity utilise GnuPG pour le cryptage afin que vos données soient sécurisées. Avec Duplicity, vous avez également la possibilité d’effectuer des sauvegardes incrémentielles qui ne sauvegardent que les nouvelles données depuis la dernière sauvegarde effectuée. Cela rend la sauvegarde de grandes quantités de données plus efficace

Duplicity est une excellente solution de sauvegarde pour les entreprises ou les particuliers qui ont de grandes quantités de données à sauvegarder.

Comment effectuer une Sauvegarde avec Duplicity ?

Duplicity peut être utilisé pour effectuer des sauvegardes de la manière suivante :

duplicity --no-encryption dossier_a_sauvegarder/ protocole://utilisateur@adresse_du_serveur/dossier/

Exemple :

duplicity --no-encryption /home/www-data/mon_site/ ftp://genevieve@ftp.example.com/backup/

La première sauvegarde ainsi effectuée sera complète, et chaque nouvelle utilisation de cette commande créera une sauvegarde différentielle (seuls les nouveaux fichiers et les fichiers modifiés seront transférés vers la destination).

Comment restaurer un backup avec Duplicity ?

Les sauvegardes de Duplicity sont des archives au format .tar. Pour retrouver la dernière version d’un dossier sauvegardé, il faudra utiliser Duplicity afin d’interpréter leur contenu.

duplicity --no-encryption protocole://utilisateur@adresse_du_serveur/dossier/ dossier_a_sauvegarder/

Exemple :

duplicity --no-encryption ftp://genevieve@ftp.example.com/backup/ /home/www-data/mon_site/

Il est possible d’ajouter le paramètre –restore-time pour préciser la version des données à récupérer.

Exemple : Pour récupérer les donnés sauvegardées il y a 3 jours :

duplicity --no-encryption --restore-time 3D ftp://genevieve@ftp.example.com/backup/ /home/www-data/mon_site/

Comment chiffrer ses sauvegardes afin de les protéger ?

Dépendant de l’endroit où l’on souhaite stocker une sauvegarde, on peut être amener à vouloir la chiffrer pour préserver le caractère privé de ses données. On utilisera alors Duplicity avec GnuPG.

Il est nécessaire de posséder au moins un couple clé privée-clé publique pour suivre les exemples ci après. Voir la définition de GnuPG pour plus d’informations.

Pour la sauvegarde ou la restauration des données, le paramètre –no-encryption pourra être remplacé par les 2 paramètres –encrypt-key et –sign-key suivis chacun de l’identifiant à 8 caractères d’une clé (il faudra bien entendu posséder la clé privée pour pouvoir effectuer une restauration).

Exemple :

duplicity --encrypt-key 1234ABCD --sign-key 1234ABCD /home/www-data/mon_site/ ftp://genevieve@ftp.example.com/backup/

Comment détourner IMAP pour stocker vos sauvegardes ?

IMAP est un protocole de consultation de boîte aux lettres, mais avec la taille actuelle des boîtes aux lettres fournies avec des services comme Gmail (15Go), il peut être intéressant de mettre a profit cet espace en le détournant pour y stocker des sauvegardes.

duplicity --volsize 5 --imap-mailbox Mon_dossier_IMAP dossier_a_sauvegarder imaps://utilisateur:mot_de_passe@adresse_du_serveur

Exemple :

duplicity --volsize 5 --imap-mailbox Backup /home/www-data/mon_site/ imaps://genevieve@gmail.com:mot_de_passe@imap.gmail.com

Exemple de script de sauvegarde avec Duplicity

Voici un exemple de script pouvant être appelé régulièrement par Cron pour effectuer une sauvegarde complète d’un serveur vers un emplacement accessible via FTP. La première sauvegarde sera complète, les suivantes différentielle, et toutes les 2 semaines une nouvelle sauvegarde complète sera crée. A chaque exécution du script, les sauvegardes de plus d’un mois seront effacées de l’emplacement de destination.

export PASSPHRASE='phrase de passe de la clé GnuPG'
export FTP_PASSWORD='mot de passe associé au compte FTP'

duplicity --encrypt-key 1234ABCD --sign-key 1234ABCD --full-if-older-than 2W --exclude /mnt --exclude /tmp --exclude /proc --exclude /sys / ftp://genevieve@ftp.example.com/backup/
duplicity remove-older-than 1M --force --encrypt-key 1234ABCD --sign-key 1234ABCD ftp://genevieve@ftp.example.com/backup/

Pour des raisons de sécurité évidentes, ce script devra être exécuté uniquement par l’utilisateur root et ne devra pas être accessible par n’importe quel utilisateur.

Listes des paramètres possibles pour Duplicity

Duplicity peut être configuré par l’utilisation de nombreux paramètres, dont voici quelques-uns :

–no-encryption : Indique à Duplicity de ne pas utiliser GnuPG pour chiffrer les données. Par défaut, Duplicity tente de chiffrer avec la clé définie par défaut.
–restore-time : Suivi de la date à laquelle on souhaite effectuer la restauration ou d’intervalle de temps. L’intervalle s’exprime sous la forme “XD” pour le nombre de jours (avec X le nombre de jours), “XW” pour le nombre de semaines, “XM” pour le nombre de mois.
–encrypt-key : Suivi de l’identifiant de la clé GnuPG à utiliser pour chiffrer l’archive avant de la stocker dans la destination.
–sign-key : Suivi de l’identifiant de la clé GnuPG à utiliser pour signer l’archive avant de la stocker dans la destination.
–exclude : Suivi d’une expression ou d’un nom de fichier ou dossier à exclure de la sauvegarde.
–imap-mailbox : Suivi du nom du dossier à utiliser avec le protocole IMAP.
–volsize : Suivi de la taille d’une archive en Méga-octets.
Pour connaître tous les paramètre disponibles et obtenir plus de détails ne pas hésiter à consulter son manuel officiel en anglais.

Ejabberd

Ejabberd est un serveur de messagerie instantanée populaire et polyvalent, qui compte probablement le plus grand nombre d’installations.

Quelles sont les configurations préalables requises pour utiliser Ejabberd ?

Avant de commencer à installer un serveur de messagerie instantanée, il y a quelques étapes préliminaires à effectuer dans l’article général sur la messagerie instantanée.

Comment installer Ejabberd sur Debian ?

Il suffit d’installer le paquet souhaité pour votre distribution, qui devrait être identique. Il s’agit du paquet Debian ejabberd, par exemple.

Comment corriger les droits du binaire d’identification ?

Le service d’identification PAM est accessible par ejabberd avec un petit exécutable, epam, pour vérifier l’identification des utilisateurs. Ce binaire doit être capable de lire le fichier de mots de passe secrets, /etc/shadow, afin d’identifier les personnes. Le groupe shadow nous fournira ce binaire et le rendra setuid.

# chown root:shadow /usr/lib/ejabberd/priv/bin/epam
# chmod 2755 /usr/lib/ejabberd/priv/bin/epam

Sous Debian, pour rendre cette modification persistante malgré les éventuelles mises à jour :

# dpkg-statoverride --add root shadow 2755 /usr/lib/ejabberd/priv/bin/epam

Comment configurer Ejabberd ?

La configuration d’ejabberd se trouve dans le fichier /etc/ejabberd/ejabberd.cfg. Celui-ci est écrit en erlang, mais son texte est très bien commenté. Vous pouvez également consulter le manuel officiel, qui offre une description complète des paramètres d’ejabberd.

Parmi les réglages les plus importants :

  • le ou les noms de domaines à servir :
%% Hostname
{hosts, ["example.com", "example.org"]}.
  • l’adresse Jabber de l’administrateur, qui aura des privilèges supérieurs sur le service :
%% Admin user
{acl, admin, {user, "gene", "example.com"}}.

À quoi correspond le mode d’identification ?

Le serveur ejabberd utilise par défaut sa propre base d’identification, ce qui est suffisant pour un service de messagerie instantanée de base. En revanche, on peut souhaiter utiliser l’identification du système d’exploitation pour un self-hosting multi-services. Pour ce faire :

%%
%% auth_method: Method used to authenticate the users.
%% The default method is the internal.
%% If you want to use a different method,
%% comment this line and enable the correct ones.
%%
%%{auth_method, internal}.

%%
%% Authentication using PAM
%%
{auth_method, pam}.

Ejabberd et le chiffrement SSL

Si vous souhaitez vous connecter à votre service de messagerie instantanée depuis l’extérieur, il est judicieux d’utiliser le cryptage de la connexion pour éviter que votre mot de passe ne soit envoyé en clair sur des réseaux que vous ne contrôlez pas. Pour ce faire, vous aurez besoin d’un certificat SSL et de la clé qui l’accompagne.

Chaque serveur Ejabberd doit être capable de charger la clé, le certificat et le certificat d’autorité à partir d’un seul fichier. Il faut donc combiner ces documents ensemble et les rendre lisibles par Ejabberd :

# cat /etc/ssl/private/example.com.key /etc/ssl/certs/example.com.pem /etc/ssl/certs/autorité.pem > /etc/ejabberd/ejabberd.pem
# chmod 440 /etc/ejabberd/ejabberd.pem
# chgrp ejabberd /etc/ejabberd/ejabberd.pem

Ensuite, configurez Ejabberd pour utiliser ce certificat :

%%
%% domain_certfile: Specify a different certificate for each served hostname.
%%
{domain_certfile, "example.com", "/etc/ejabberd/ejabberd.pem"}.

Enfin, pour imposer le chiffrement pour toutes les connexions clientes et pour le proposer pour les connexions serveurs :

%%
%% listen: Which ports will ejabberd listen, which service handles it
%% and what options to start it with.
%%
{listen,
 [
  {5222, ejabberd_c2s, [
                        inet6,
                        {access, c2s},
                        {shaper, c2s_shaper},
                        {max_stanza_size, 65536},
                        starttls, starttls_required
                       ]},
  …
 ]}.

Comment tester si Ejabberd fonctionne correctement ?

Vous pouvez maintenant redémarrer ejabberd en tapant /etc/init.d/ejabberd restart, puis tenter de vous connecter à votre serveur en utilisant l’un de vos clients favoris. Les fautes les plus typiques sont les points, accolades, virgules ou parenthèses manquants dans le fichier de configuration.

Fetchmail

Fetchmail est un programme qui vous permet de récupérer automatiquement les nouveaux e-mails d’une adresse et de les transférer à une autre. Ce logiciel est vraiment utile pour faire la transition entre votre ancienne adresse de courriel en nuage et votre nouvelle adresse de courriel de votre serveur personnel.

De cette manière, vous pourrez récupérer tout votre courrier sur la nouvelle adresse tout en conservant le nom original de la personne qui vous a contacté. En effet, une autre approche pour récupérer votre courrier sur une autre adresse consiste à demander à un logiciel de « transférer » les nouveaux courriers vers un compte de messagerie différent. Mais dans ce scénario, votre nom change. Votre nom devient le nom de la boîte aux lettres qui a fait suivre le matériel. Dans certaines situations, cette action peut être frustrante.

Comment installer Fetchmail sur un serveur Debian ?

L’installation de fetchmail sur une distribution Debian est très simple. Rien n’est plus simple que d’installer fetchmail sur une distribution Debian :

aptitute install fetchmail

Comment configurer Fetchmail ?

La configuration de fetchmail est simple. Pour commencer, vous devez créer le fichier de configuration du service. Vous pouvez soit créer un fichier global : /etc/fetchmailrc. Alternativement, vous pouvez créer un fichier pour chaque utilisateur : ~/.fetchmailrc

Si vous créez un fichier de configuration global, vous pouvez lancer ce service comme n’importe quel autre. Si vous créez un fichier de configuration par utilisateur, utilisez fetchmail comme n’importe quel autre programme avec des privilèges d’utilisateur. En raison de la facilité de configuration de fetchmail, il est plus intéressant de maintenir un seul fichier de configuration global plutôt que de nombreux fichiers locaux.

Les fichiers fetchmailrc, qu’est-ce que c’est ?

La configuration de fetchmail se résumé à deux lignes :

  • set daemon xxx
  • poll server with proto protocol user user@server.domain there with password theUserPassword is newUser here

La première ligne définit le temps entre les récupérations en secondes. Fetchmail vérifiera le nouveau courrier toutes les 5 minutes si vous définissez la valeur de xxx à 300.

Pour délivrer vos mails, vous devez d’abord sélectionner une boîte aux lettres sur laquelle les envoyer. La deuxième ligne précise où les mails doivent être envoyés et transférés. Les mots-clés en gras ne doivent pas être modifiés ; le reste des mots sont des paramètres qui doivent être modifiés pour que fetchmail agisse comme souhaité.

  • server : l’adresse du serveur où récupérer les mails
  • protocol : le protocole à utiliser, typiquement POP/POP3 ou IMAP
  • user@server.domain : tout simplement l’adresse mail où chercher les nouveaux mails
  • theUserPassword : le mot de passe de l’adresse mail
  • newUser : l’utilisateur de la machine locale où il faut transmettre les mails

Enfin, ce fichier contient votre adresse électronique, il est donc important de modifier les autorisations d’accès au fichier :

chmod 600 /etc/fetchmailrc

Pour lancer fetchmail, utilisez cette commande :

/etc/init.d/fetchmail start

Qu’en est-il de la taille des mails récupérés ?

Si vous avez des pièces jointes volumineuses dans votre boîte aux lettres, fetchmail sera incapable de les récupérer. Par défaut, fetchmail ne récupère pas les courriers volumineux. Ce n’est pas le problème le plus grave. En plus de ne pas récupérer votre courrier, il enverra également un e-mail de notification à la personne qui vous a envoyé le message toutes les minutes, à moins que vous ne supprimiez vous-même l’élément incorrect.

Vous pouvez également utiliser l’option limit de fetchmail pour restreindre les téléchargements d’emails en limitant la quantité maximale de données que fetchemail peut collecter. Si cette option est définie à 0, fetchmail ne pourra pas contrôler la taille des emails qu’il récupère. Donc, si vous ne voulez pas que vos courriels soient récupérés et que des courriels d’erreur soient envoyés, mettez simplement cette option à 0.

Fibre optique

La fibre optique est un type de câble de données qui transmet les informations par la lumière. Elle est constituée d’un fil fin (généralement en verre ou en plastique) qui est un conducteur de lumière et qui est utilisé pour la transmission de données. Les largeurs de bande envoyées par cette technologie sont nettement supérieures à celles fournies par les câbles coaxiaux classiques, ce qui peut inciter toute entreprise d’auto-hébergement souhaitant fournir des services nécessitant une large bande passante (notamment en transmission ou en téléchargement).

Cependant, il existe plusieurs formes de réseaux en fibre optique, chacune ayant ses propres caractéristiques (ainsi que ses limites). La meilleure forme de réseau est le FTTH (Fiber To The Home), dans lequel le point de connexion final est la prise murale de votre maison, mais c’est aussi généralement l’option la plus coûteuse à installer. Pour plus d’informations sur les technologies FTTx, consultez l’article intitulé Différents types de fibre optique à domicile.

Freenet

Il existe des méthodes alternatives pour garder votre site web en ligne en utilisant les réseaux P2P. Par exemple, Freenet propose des services gratuits d’hébergement partagé dans un environnement p2p, tels que :

  • L’hébergement de pages web en HTML appelé Freesite
  • Des forum de discussion (Freetalk) malheureusement non modérable pour le moment (à utiliser avec précaution donc !)
  • Le stockage de fichiers,
  • Les mails (Freemail),
  • Le chat instantané personnalisable (FMS).

L’avantage est que ces sites restent sur le réseau dès qu’ils ont été téléchargés (pages + fichiers (images, pdf tout ce dont vous avez besoin… etc)) après quoi, même si votre ordinateur est éteint, le matériel que vous avez créé est disponible.

Vous pouvez également créer des intranets en utilisant Freenet (en mode F2F : réseaux exclusifs d’amis à amis) pour héberger des pages web semi-privées (ne mettez rien de très privé de toute façon, à moins que vous ne fassiez confiance à 100% aux capacités techniques et morales de vos amis (qui n’en ont peut-être pas après tout !!)).

Le principal avantage est que seuls ceux qui exécutent le logiciel Freenet en mode ouvert (pour tout le monde) peuvent y accéder, bien que cela puisse être limité par le portail freenet sur Internet (sauf par un site sur Internet donnant accès à freenet). Si votre site n’est pas très intéressant, il disparaîtra rapidement de Freenet.

Un certain nombre d’applications similaires existent, mais elles sont moins sophistiquées que Freenet et moins populaires : I2P, etc.

Une belle solution pour éviter les grosses dépenses d’électricité à la fin du mois ! Et, à mon avis, la décentralisation (pour des raisons légales évidentes) et les économies sont toutes deux sur la voie de l’avenir…

Gentoo GNU/Linux

Gentoo est une dérivation du projet original Gentoo Linux qui comprend des améliorations, des mises au point et des correctifs. En d’autres termes, il s’agit d’une distribution basée sur Gentoo Linux avec des modifications pour répondre à des préférences personnelles ou à des situations uniques rencontrées lors de l’installation du système.

Il convient également de noter que les paquets des versions précédentes peuvent ne pas être compatibles avec les versions futures, à moins que vous n’effectuiez un certain niveau de mise à jour manuelle. Cela peut conduire à des problèmes tels que l’échec de la synchronisation si l’on dépend de ces paquets pour quelque chose d’important dans le fonctionnement de son système.

Le noyau peut être mis à jour soit par le biais de gestionnaires de paquets (tels que Portage), qui sont standard dans toutes les distributions, soit en le compilant manuellement à partir du code source. Comme mentionné précédemment, ceci est généralement possible via la commande emerge ; cependant, il arrive qu’un message d’erreur sera affiché qu’un certain nombre de fichiers n’ont pas pu être trouvés. Cela est dû au fait que certains des logiciels installés nécessitent une version spécifique du noyau pour fonctionner correctement. Si vous voyez ce message, vous devrez peut-être rétrograder ou mettre à niveau votre noyau avant de continuer.

Le système est une distribution rolling-release, ce qui signifie que le programme est maintenu fréquemment sans nécessiter la publication d’une nouvelle version de Gentoo. Par conséquent, le système reste à jour.

Comment installer Gentoo GNU/Linux ?

Pour installer le logiciel, il n’y a pas de programme d’installation ; en revanche, un manuel complet contenant toutes les instructions nécessaires à la construction d’un système complet est fourni sur le site officiel de Gentoo.

Git

Git est un système de contrôle de version distribué, gratuit et open source, conçu pour traiter tous les projets, des plus petits aux plus grands, avec rapidité et efficacité.

Git est facile à apprendre et a une empreinte minuscule avec des performances rapides comme l’éclair. Il surpasse les outils SCM tels que Subversion, CVS, Perforce et ClearCase grâce à des fonctionnalités telles que le branchement local bon marché, les zones de stockage pratiques et les flux de travail multiples.

Pourquoi et quand utiliser Git ?

L’utilisation traditionnelle de Git pour un projet collaboratif tire parti de ses fonctionnalités de gestion distribuée :

  • chaque collaborateur maintient son propre dépôt Git ;
  • le responsable principal du projet récupère — « tire », en langage Git — les modifications des dépôts des autres collaborateurs pour les intégrer dans le dépôt principal.

Avec une telle méthode de travail, il n’est pas nécessaire de donner aux collaborateurs des droits d’envoyer leurs modifications dans le dépôt principal puisque celles-ci sont récupérées par le responsable, tirées plutôt que poussées.

Les protocoles pour utiliser Git

Git est utilisable selon deux modes principaux :

  • pour pousser des modifications, donc en lecture–écriture : en local ou par SSH ;
  • pour tirer des modifications, donc en lecture seule : par le protocole Git natif, ou par HTTP — il est bien sûr possible de tirer ces modifications en local ou par SSH.

Dans l’utilisation traditionnelle distribuée de Git, le mode en lecture–écriture est principalement utilisé par chaque collaborateur pour pousser ses modifications sur le serveur qui héberge son dépôt personnel s’il travaille sur une machine différente.

Comment installer et configurer Git sur un serveur Debian ?

Sous Debian, il suffit d’installer le paquet git-core.

# aptitude install git-core

Comment créer un projet dans Git ?

Pour créer un projet avec Git, il suffit de se servir de la commande git-init. Cela peut être utilisé de la façon suivante :

$ cd mon_projet/
$ git init

Après la création d’un nouveau dépôt, la première chose à faire est de renseigner sa description dans le fichier adéquat.

$ echo "Description du projet." > .git/description

Comment créer un projet Git depuis un dépôt SVN ?

Voici comment il est possible de passer de SVN à Git via le programme git-svn.

# aptitude install git-svn
$ git svn clone http://example.org/svn/projet -s --authors-file=~/fichier_auteurs

Bon à savoir :

  • ‘option -s permet de récupérer branches et tags depuis les noms conventionnels (trunk, branches et tags).
  • l’option –authors-file permet de faire référence à un fichier qui fait le lien entre un nom de contributeur au format SVN et un autre au format Git.
Dans ~/fichier_auteurs :
user = user <username@example.org>

Cette commande a donc pour objectif de passer en revue chaque commit sur SVN pour le reporter sur un nouveau projet Git. Créer un projet de cette façon aura la fâcheuse tendance de ne pas le construire de la même manière que s’il avait été initié sous Git. J’entends par là que les branches SVN existantes au moment de la migration seront reprises en tant que branches distantes et qu’il est difficile de savoir vers quoi elle sont reliées. D’autre part, le fichier .git/config comporte des sections obscures, etc. J’ai pris le pli de retirer ces sections et de créer des branches locales depuis les branches distantes avant de supprimer ces dernières.

Comment utiliser Git en lecture seule ?

Le démon Git permet de fournir un accès en lecture seule à des dépôts par le protocole natif Git. Cela permet à des contributeurs de récupérer une copie de ce dépôt — de « tirer », en langage Git. Puisqu’il fournit un service en lecture seule, ce démon a uniquement besoin de pouvoir lire les fichiers des dépôts.

Les dépôts Git peuvent être stockés dans un répertoire /srv/git appartenant à root. Contrairement aux dépôts locaux, on crée ici un dépôt nu (bare), qui n’a pas de répertoire de travail :

# mkdir /srv/git
# git init --bare /srv/git/projet.git
# echo "Description du projet." > /srv/git/projet.git/description

Le démon Git peut être lancé à la demande par le super-serveur inetd, qui prendra à sa charge l’écoute sur le port Git (9418) : cela évite de laisser tourner un démon Git qui ne sera utilisé que momentanément. Il faut donc créer une règle inetd particulière dans le fichier de configuration /etc/inetd.conf après avoir installé le paquet openbsd-inetd si ce n’est pas déjà fait :

git stream  tcp4    nowait  nobody /usr/bin/git git daemon --inetd --base-path=/srv/git /srv/git
git stream  tcp6    nowait  nobody /usr/bin/git git daemon --inetd --base-path=/srv/git /srv/git

Si aucun service inetd n’était défini, le serveur inetd était probablement à l’arrêt et il faut alors le lancer :

# service openbsd-inetd start

À ce stade, le daemon tourne est délivre son service. Il est donc possible d’accéder en lecture aux dépôts du répertoire /srv/git à condition que ces derniers soient marqués comme exportables, c’est-à-dire qu’ils comportent un fichier git-daemon-export-ok (ce qui ne devra pas être le cas pour les projets personnels).

# touch /srv/git/projet.git/git-daemon-export-ok

L’accès se fera de cette façon (ici, dans le cas d’une demande de clone) :

$ git clone git://git.example.org/projet.git

Comment utiliser Git en lecture et écriture ?

Git permet nativement de pousser des modifications par SSH : l’accès aux projets est alors régi par les droits d’accès Unix usuels sur les fichiers des dépôts :

  • pour un service personnel, il suffit de donner les dépôts Git à votre utilisateur ;
  • pour un service de groupe, il faut créer un groupe par projet, y mettre les utilisateurs correspondant aux collaborateurs et donner le dépôt du projet à ce groupe, autoriser l’écriture par le groupe — il faut également configurer le dépôt pour indiquer à Git que les nouveaux fichiers créés doivent également être inscriptibles par le groupe : git config core.sharedRepository true.
# chown -R tintin:tintin /srv/git/projet.git

Il est dès lors possible de pousser des modifications de cette façon :

$ git clone ssh://genevieve@git.example.org/srv/git/projet.git
$ [modifications et commits]
$ git push

Comment visualiser ses projets Git sur GitWeb ?

Gitweb est un projet permettant de donner un accès en visualisation aux dépôts Git du serveur. Il est disponible dans les paquets de Debian :

# aptitude install gitweb

Il faut ensuite configurer Gitweb (pour lui enseigner que les dépôts sont dans /srv/git) :

# cp /etc/gitweb.conf /etc/gitweb.conf.dist
# vi /etc/gitweb.conf
Dans /etc/gitweb.conf

# path to git projects (<project>.git)
$projectroot = "/srv/git";

# directory to use for temp files
$git_temp = "/tmp";

# target of the home link on top of all pages
#$home_link = $my_uri || "/";

# html text to include at home page
$home_text = "indextext.html";

# file with project list; by default, simply scan the projectroot dir.
$projects_list = $projectroot;

# stylesheet to use
$stylesheet = "gitweb.css";

# javascript code for gitweb
$javascript = "gitweb.js";

# logo to use
$logo = "git-logo.png";

# the 'favicon'
$favicon = "git-favicon.png";

Les hooks pour GitWeb

Il est aussi nécessaire d’accrocher une exécution de “post-update” afin de mettre à jour les informations du dépôt (chose faîte à la volée pour les accès via protocole git mais pas pour http).

La commande à exécuter est simplement un “git update-server-info”, cela se configure dans le fichier “projet.git/hooks/post-update”.

projet.git/hooks/post-update
#!/bin/sh
exec git update-server-info

Comment configurer Apache pour GitWeb ?

Si vos projets ne sont pas à rendre publics, il faudra restreindre l’accès à Gitweb, il faut donc gérer un mécanisme d’authentification. Ce service est rendu par la configuration Apache ci-après. Si cela vous est inutile, vous pouvez retirer ce qui a un lien avec l’identification (« Auth* » et « Require valid-user ») et ne pas créer le fichier git.passwd.

Il faut donc créer une configuration Apache, l’activer et recharger Apache :

# vim /etc/apache2/sites-available/git
Dans /etc/apache2/sites-available/git

<VirtualHost *:80>
    ServerAdmin username@example.org
    ServerName git.example.org
    DocumentRoot /srv/git

    Alias /gitweb.css /usr/share/gitweb/gitweb.css
    Alias /git-favicon.png /usr/share/gitweb/git-favicon.png
    Alias /git-logo.png /usr/share/gitweb/git-logo.png
    Alias /git /srv/git

    ScriptAlias /gitweb.cgi /usr/lib/cgi-bin/gitweb.cgi
    DirectoryIndex gitweb.cgi
    <Directory "/srv/git/">
        Order allow,deny
        Allow from all
        AuthType Basic
        AuthName "Gitweb"
        AuthUserFile /srv/git/git.passwd
        Require valid-user
    </Directory>

    ErrorLog /var/log/apache2/git-error.log
    LogLevel warn
    CustomLog /var/log/apache2/git-access.log combined
</VirtualHost>
# a2ensite git
# /etc/init.d/apache2 reload

Il ne reste ensuite qu’à alimenter un fichier contenant les autorisations :

# htpasswd -cm /srv/git/git.passwd user

Pour simplement ajouter un utilisateur, on retire l’option -c qui servait à créer le fichier la première fois.

Comment sauvegarder les dépôts Git ?

Il existe plusieurs solutions pour sauvegarder ses dépôts Git. Chaque clone d’un dépôt constitue une sauvegarde basique.

Sauvegarder les dépôts Git via RSYNC

Une simple sauvegarde des fichiers du dépôt permet de le conserver et de le restaurer à l’identique au besoin, l’utilisation de rsync est idéale dans ce cas :

# crontab -e
50 5 * * * rsync -a --delete /srv/git /srv/sauvegardes/

Sauvegarder les dépôts Git via Git

Git permet aussi de gérer la copie de sauvegarde d’un dépôt.

Dans un premier temps il faut créer un clone du dépôt à sauvegarder, l’option –mirror permet de sauvegarder plus d’informations (cf. man 1 git-remote).

# cd /var/backup/git/
# git clone --mirror git://repo repo.backup

Puis une tâche dans la cron pour effectuer régulièrement une synchronisation via Git.

50 5 * * * cd /var/backup/git/repo.backup && git remote update

Extraction d’une révision précise de Git en local

Il est possible d’exporter une révision particulière du code source, ou une partie de l’arborescence du dépôt.

git archive -o latest_documentation.tar.gz HEAD:doc         # extraction du répertoire doc/ dans sa dernier révision
git archive --prefix=dev-1.4.0/ -o dev-1.4.0.tar.gz v1.4.0  # extraction du tag v1.4.0

Extraction d’une révision précise de Git à distance

Il est aussi possible de faire ça à travers le réseau de la même façon qu’avec svn export, cependant la configuration par défaut du daemon git ne permet pas le service (cf. man 1 git-daemon).

Afin d’autoriser l’export du code à travers le protocole git, il faut activer le service “upload-archive” dans le fichier de configuration du dépôt :

Dans projet.git/config

[daemon]
    uploadarch = true

Il est alors possible d’effectuer les même commandes que précédemment en spécifiant l’adresse du dépôt :

git archive --remote=git://git.example.org/myproject.git -o latest_documentation.tar.gz HEAD:doc         # extraction du répertoire doc/ dans sa dernier révision
git archive --remote=git://git.example.org/myproject.git --prefix=dev-1.4.0/ -o dev-1.4.0.tar.gz v1.4.0  # extraction du tag v1.4.0

Comment installer et configurer Git sur un poste client ?

Sur un poste client, l’installation de git-core est suffisante pour pouvoir cloner des projets et pour travailler dessus.

# aptitude install git-core

Il peut également être agréable d’avoir une vue graphique de l’historique des projets auquel cas l’application gitg peut être intéressante. Son installation se fait également depuis les dépôts sous Debian. Il existe également gitk qui est cependant un peu moins agréable à utiliser.

# aptitude install gitg

Un point primordial pour travailler avec Git est de configurer son identité qui sera reprise dans chaque commit. Il faut donc procéder ainsi :

$ git config --global user.name "Genevieve"
$ git config --global user.email "genevieve@example.org"

Il est plus aisé de travailler avec Git s’il on a configuré quelques alias. Les alias permettent de remplacer le nom d’une commande par quelque chose de généralement plus court. Il est possible d’opérer globalement (pour tous les projets gérés par l’utilisateur) en retenant ces alias dans un fichier de paramétrage propre à l’utilisateur.

$ git config --global alias.br branch
$ git config --global alias.ci commit
$ git config --global alias.co checkout
$ git config --global alias.st status

Enfin, il est plus agréable de demander une coloration du retour des commandes Git dans le Shell.

$ git config --global color.ui auto

Pour voir le résultat, il faudra afficher le fichier ~/.gitconfig :

$ cat ~/.gitconfig
Dans ~/.gitconfig

[user]
    name = Tintin
    email = tintin@example.org
[alias]
    br = branch
    ci = commit
    co = checkout
    st = status
[color]
    ui = auto

Au besoin, on peut refaire ces commandes de paramétrage sans l’option –global (à l’intérieur d’un projet git) pour que cela prime sur la valeur générale.

Enfin, il est possible de faciliter la saisie de commandes Git via l’autocomplétion tel qu’il est offert par le script /etc/bash_completion.d/git en ajoutant un appel à ce dernier dans sa configuration Bash.

$ vim ~/.bashrc
# Autocomplétion Git
source /etc/bash_completion.d/git

GnuPG

GnuPG est un logiciel libre de chiffrement utilisant la norme OpenPGP, il permet notamment de créer et utiliser des clés permettant une cryptographie asymétrique.

Comment utiliser GnuPG ?

Comment créer un couple de clés et à quoi ça sert ?

On entends par “création d’un couple de clés”, la création de 2 clés permettant un chiffrage asymétrique : une clé privée et une clé publique.

La création d’une paire de clés dans GnuPG se fait avec la commande gpg –gen-key. GnuPG posera alors quelques questions permettant d’identifier les clés (domaine, nom, etc.).

Comment exporter un clé GnuPG ?

Il est possible de lister toutes les clés privées dont l’utilisateur est en possession grâce à la commande gpg –list-secret-keys, et les clés publiques avec gpg –list-keys.

Chaque clé listée est identifiée par un champ au format “2048R/1234ABCD”. L’identifiant de la clé est la partie suivant la barre oblique, cet identifiant est hexadécimal.

Pour exporter une clé vers un fichier, il faudra utiliser la commande gpg –export 1234ABCD > ma_clé.gpg.key. Il est également possible d’afficher la clé avec des caractères lisibles avec l’option -a.

Comment exporter un clé GnuPG ?

Il est possible d’importer une clé publique ou une clé privée à votre trousseau avec la commande gpg –import clé_à_importer.gpg.key.

Jabberd14

Voici l’intégralité des actions qui vont suivre doivent être exécutées en tant que super-utilisateur (typiquement : root) pour installer Jabberd14

Pour installer jabberd14, utilisez votre gestionnaire de paquets préféré. Par exemple avec apt-get, entrez :

# apt-get install jabber

Dès lors, jabberd14 est installé.

Pour tester si votre serveur est dors et déjà opérationnel, entrez :

# telnet 127.0.0.1 5222

ainsi que

# telnet 127.0.0.1 5269

Si telnet ne vous indique pas « Unable to connect to remote host: Connection refused » mais « Connected to 127.0.0.1 » c’est que votre serveur est opérationnel.

Entrez « quit » et enfoncez la touche Entrer pour sortir de telnet.

Pour communiquer avec l’extérieur, il faudra donc ouvrir les ports 5222 et 5269 de votre routeur.

Pour tester la communication de votre serveur avec l’extérieur, entrez :

# telnet votre_nom_de_dommaine 5222
# telnet votre_nom_de_dommaine 5269

Si telnet ne vous indique pas « Unable to connect to remote host: Connection refused » mais « Connected to votre_nom_de_dommaine » c’est que votre serveur est opérationnel.

Entrez « quit » et pressez Entrer pour sortir de telnet.

Comment configurer Jabberd14 ?

Le nom du serveur demeure toujours « localhost ».

La configuration du serveur se fait via le fichier /etc/jabber/jabber.xml.

Certaines lignes sont précédées d’un point, ces lignes sont des commentaires, il ne sert donc à rien de les modifier.

Tout d’abord, pour changer le nom du serveur (localhost) dans jabber.xml, remplacez toutes les références à “localhost” par votre nom de dommaine.

Vous pouvez dors et déjà recharger votre serveur Jabberd14 en entrant :

# /etc/init.d/jabber restart

Votre serveur peut alors accepter les connexion de l’extérieur par votre nom de dommaine.

Pour ajouter un utilisateur, utilisez votre client Jabber préféré (Pidgin, Gaim, Freetalk…). Celui-ci vous proposera de créer un compte. (Par défaut, jabberd14 autorise la création de comptes.)

Toujours dans le fichier /etc/jabber/jabber.xml, vous pourrez modifier le nom, la description et l’URL de votre serveur Jabber grâce aux lignes :

<jabber>
 …
  <service id="sessions">
   …
    <jsm xmlns="jabber:config:jsm">
     …
      <vCard>
        <FN>Jabber Server</FN>
        <DESC>A Jabber Server on Debian GNU/Linux!</DESC>
        <URL>http://www.debian.org/</URL>
      </vCard>

Remplacez le texte contenu entre <FN> et </FN> par le nom de votre serveur Jabber, le texte contenu entre <DESC> et </DESC> par une petite description de votre serveur et le texte contenu entre <URL> et </URL> par l’URL de votre serveur Jabber.

<jabber>
 …
  <service id="sessions">
   …
    <jsm xmlns="jabber:config:jsm">
     …
      <register notify="yes">
        <instructions>Choose a username and password to register with this server.</instructions>
        <name/>
        <email/>
      </register>

Ces lignes servent à définir la phrase d’instruction qui sera demandée lors de l’enregistrement d’un compte. Je vous conseille de mettre un phrase explicite, en français.

Les éléments <name/> et <email/> indiquent que l’utilisateur va devoir renseigner son nom et son adresse e-mail lors de l’enregistrement. Vous pouvez supprimer l’un ou ces deux éléments selon vos souhaits.

Pour ne pas accepter l’enregistrement de nouveaux comptes, ajoutez <!-- avant <register notify="yes"> et <mod_register>./jsm/jsm.so</mod_register> (à la fin du fichier).

<jabber>
 …
  <service id="sessions">
   …
    <jsm xmlns="jabber:config:jsm">
     …
      <welcome>
        <subject>Welcome!</subject>
        <body>Welcome to the Jabber server -- we hope you enjoy this service! For information about how to use Jabber, visit the Jabber User's Guide at http://jabbermanual.jabberstudio.org/</body>
      </welcome>

Ces lignes servent a définir le message d’accueil réservé à un nouvel utilisateur.

Remplacez le texte compris entre et par le sujet du message de bienvenue, typiquement quelque chose comme : “Bienvenue”. Remplacez ensuite le texte compris entre et par votre message de bienvenue.

<jabber>
 …
  <service id="sessions">
   …
    <jsm xmlns="jabber:config:jsm">
     …
      <admin>
        <read>user@localhost</read>
        <write>user@localhost</write>
        <reply>
          <subject>Auto Reply</subject>
          <body>This is a special administrative address.  Your message was received and forwarded to server administrators.</body>
        </reply>
      </admin>

Ce groupe sert à définir le message de réponse lorsqu’un utilisateur « chattera » avec votre serveur (en entrant seulement le nom du serveur comme utilisateur).

Remplacez le texte compris entre et ainsi que le texte compris entre et par l’adresse de l’administrateur du serveur.

Vous pouvez ajouter plusieurs … et … pour définir plusieurs administrateurs.

Remplacez ensuite le texte compris entre et par le sujet du message qui sera envoyé. Puis remplacez le texte compris entre et par votre message.

Voilà, la configuration de base de votre serveur est terminée ! vous n’avez plus qu’a redémarrer votre serveur Jabberd14 en entrant :

# /etc/init.d/jabberd14 restart

Comment sécuriser les connexions Jabberd14 avec OpenSSL ?

Pour sécuriser la connexion avec OpenSSL, il va tout d’abord faloir créer un certificat et une clé.

Assurez-vous que le paquet openssl est dors et déjà installé, sinon installez-le.

Entrez ensuite :

openssl req -new -x509 -newkey rsa:1024 -days 3650 -keyout privkey.pem -out key.pem
openssl rsa -in privkey.pem -out privkey.pem
cat privkey.pem >> key.pem
rm privkey.pem

Vous obtenez alors un fichier « key.pem ». Copiez ce fichier dans un répertoire précis, comme « /etc/jabber/ssl/key.pem »

Éditez alors votre fichier jabber.xml et décommentez les lignes :

<pthcsock>
  …
  <ssl port="5223">your-ip-address</ssl>
  …
</pthcsock>
…
<io>
  …
  <ssl>
    <key ip="your-ip-address">/path/to/cert_and_key.pem</key>
  </ssl>
  …
</io>

en remplacant « your-ip-address » par l’adresse ip de votre serveur. Attention, aucun nom de dommaine n’est autorisé.

Remplacez aussi « /path/to/cert_and_key.pem » par l’emplacement de votre key.pem, pour mon exemple « /etc/jabber/ssl/key.pem »

Assurez-vous également que le fichier key.pem soit lisible par le serveur.

Enfin, ouvrez le port 5223 de votre routeur.

Documentation officielle de Jabberd14

Vous pouvez, si vous le souhaitez encore plus approfondir la configuration de votre serveur : le fichier jabberd.xml est très bien documenté, certes, dans la langue de Shakespeare, mais tout de même !

Lighttpd

Lighttpd est un serveur web léger et rapide. Il a été créé pour s’adapter aux sites web construits sur la prochaine génération de technologies, selon ses créateurs. En conséquence, lighttpd est employé par Youtube, Wikipedia et Meebo.

Comment installer Lighttpd ?

Toutes les procédures suivantes doivent être effectuées en tant que super-utilisateur (typiquement : root).

Utilisez le gestionnaire de paquets de votre distribution pour installer lighttpd. Par exemple, sur Debian 11.3 avec apt-get, tapez :

# apt-get install lighttpd

Lighttpd devrait maintenant être installé.

Visitez https://votre-serveur/ avec votre navigateur web pour voir si le serveur peut démarrer avec succès.

Si vous voyez une page web « Welcome page » écrite en anglais, votre serveur fonctionne correctement.

Si vous ne voyez pas cette page et que votre navigateur vous informe qu’il n’a pas pu contacter le serveur à cette adresse, cela implique que votre serveur n’a pas réussi à démarrer ou a été mal installé.

Vérifiez le fichier /var/log/lighttpd/error.log pour trouver un indice sur la raison pour laquelle le serveur n’a pas démarré.

Si le journal de logs n’existe pas, lighttpd doit être réinstallé.

Entrez cette commande pour redémarrer votre serveur :

# /etc/init.d/lighttpd restart

Le répertoire racine de votre serveur est déterminé par le chemin /var/www/, qui correspond au répertoire racine du serveur. Le répertoire /var/www/ (qui représente le répertoire racine du serveur) contiendra vos documents HTML jusqu’à ce que vous installiez le support PHP dans lighttpd.

Pour que votre serveur soit accessible de l’extérieur, vous devez d’abord ouvrir le port 80 sur votre routeur.

Comment installer PHP8 sur Lighttpd ?

Pour installer php8, utilisez le gestionnaire de paquets présent dans votre distribution. Par exemple sous Debian 11.3 avec apt-get, entrez :

# apt-get install php8-cgi

Nous devrons activer le module fastcgi lighttpd après l’installation pour que php8 soit pris en compte.

Pour cela, entrez :

# lighty-enable-mod fastcgi

Puis redémarrez le serveur comme indiqué :

# /etc/init.d/lighttpd force-reload

Vous avez terminé. Vous devriez maintenant avoir php8 installé sur votre serveur.

Il est possible que l’emplacement de PHP dans le fichier de configuration de lighttpd soit incorrect. Pour le changer, éditez /etc/lighttpd/lighttpd.conf et ajoutez (si ce n’est pas déjà fait)

fastcgi.server = ( ".php" =>
    (( "socket" => "/tmp/php-fastcgi.socket",
        "bin-path" => "/usr/bin/php5-cgi"
    ))
  )

Nous allons créer un fichier nommé phpinfo.php dans /var/www/ pour nous assurer que php8 est opérationnel.

Éditez ce fichier et placez les lignes suivantes à l’intérieur :

<?php
phpinfo();
?>

Accédez ensuite à votre serveur à l’adresse http://serveur/ et cliquez sur phpinfo.php.

Vous devriez maintenant avoir un liste d’informations approfondie sur votre serveur et PHP.

Si ce n’est pas le cas, je vous recommande de suivre la procédure susmentionnée lors de l’installation.

Pour plus d’informations sur le langage de programmation PHP, consultez leur site officiel.

Comment installer MySQL avec PHP8 ?

Disposer d’une base de données MySQL est séduisant, mais avoir PHP8 capable de communiquer avec elle l’est peut-être encore plus. C’est la base de ce que l’on pourrait appeler le « Web 1.5 » : les informations ne sont plus directement incluses dans le fichier du serveur Web, mais plutôt dans une base de données. Les CMS (Content Management Systems) utilisent cette technique pour permettre aux utilisateurs d’ajouter du matériel en ligne sans avoir besoin de compétences en développement Web.

Pour communiquer avec PHP8, vous devez d’abord installer « php8-mysql ».

# apt-get install php8-mysql

Puis redémarrer lighttpd :

# /etc/init.d/lighttpd restart

On va ensuite tester la communication entre PHP et MySQL.

Pour cela, vous pouvez vous rendre sur phpinfo.php à la rubrique MySQL(phpinfo.php#module_mysql)

Ou créer un fichier php qui se connectera à votre base de données. Créez ce fichier dans /var/www/.

Ensuite, remplissez ce fichier comme suivi en remplaçant mdp-de-root par le mot de passe que vous avez choisi.

<html>
<head>
<title>Test MySQL</title>
</head>
<body>
<?php
$test_mysql = mysql_connect("127.0.0.1", "root", "mdp-de-root");

if($test_mysql)
{
	print("La connexion est établie !");
}
else
{
	print("La connexion n'a pas pu être établie");
}
?>
</body>
</html>

Si le message « Connexion établie » apparaît sur la page, tout est normal. Sinon, regardez les journaux de logs de MySQL et de Lighttpd.

Installation et configuration de modules complémentaires

Pour installer un module complémentaire, utilisez la commande :

# lighty-enable-mod nom_du_module

Pour désinstaller un module complémentaire, utilisez la commande :

# lighty-disable-mod nom_du_module

Le module « userdir », de même que pour Apache, permettra aux utilisateurs de la machine hébergeant le serveur lighttpd d’avoir leurs pages personnelles sous la forme : http://serveur/~identifiant/.

Les pages HTML doivent alors être placées dans leur ~/public_html/.

Pour activer ce module, entrez :

# lighty-enable-mod userdir

Voici, en vrac, une liste d’extensions pour php8 :

  • php8-curl 
  • php8-gd 
  • php8-idn 
  • php-pear 
  • php8-imagick 
  • php8-imap 
  • php8-mcrypt 
  • php8-memcache 
  • php8-mhash 
  • php8-ming 
  • php8-ps 
  • php8-pspell 
  • php8-recode 
  • php8-snmp 
  • php8-sqlite 
  • php8-tidy 
  • php8-xmlrpc 
  • php8-xsl 
  • php8-json

Toutes ces extensions s’installent avec votre gestionnaire de paquets favori !

Les fichiers de configuration de lighttpd sont localisés dans le répertoire /etc/lighttpd.

Les manuels respectifs de lighttpd, PHP et MySQL peuvent également vous aider !

MySQL

MySQL est un système de gestion de base de données relationnelle (SGBDR) gratuit et open source. Il utilise le langage de requête structuré (SQL), qui est un langage interactif et de programmation standard pour obtenir des informations à partir de bases de données et les mettre à jour. MySQL est l’un des systèmes de base de données les plus populaires utilisés sur le web.

MySQL est un SGBDR fiable, efficace et facile à utiliser. Il est utilisé par de nombreux grands sites Web, dont Facebook, Twitter, Flickr et YouTube. MySQL est également disponible sur de nombreuses plateformes d’hébergement, comme EasyHoster, Amazon EC2, Rackspace Cloud et Google App Engine.

MySQL est un choix populaire pour les applications Web car il est facile à configurer et à maintenir. Il est également rapide et évolutif, ce qui en fait un bon choix pour les sites Web très fréquentés. En outre, MySQL est disponible sur de nombreuses plates-formes différentes, notamment Windows, Linux et OS X.

MySQL peut être utilisé pour un large éventail d’applications, notamment l’entreposage de données, le commerce électronique, les applications de journalisation et les systèmes de gestion de contenu. Il peut également être utilisé comme backend pour des applications web écrites en PHP ou Perl.

Comment installer MySQL sur un serveur Debian ?

Utilisez le gestionnaire de paquets de votre distribution pour installer MySQL. Par exemple, dans Debian 11.3 avec apt-get, tapez :

# apt-get install mysql-server mysql-client

Un mot de passe root sera demandé.

Sélectionnez le mot de passe que vous souhaitez, puis appuyez sur OK. Une bonne longueur de chiffres et de lettres alternés (environ 10 caractères) fournira un haut niveau de sécurité. Par conséquent, MySQL devrait être installé.

Pour voir si vous pouvez vous connecter, tapez dans le Terminal en ligne de commande :

mysql --user root --password

Renseignez ensuite votre mot de passe.

Si MySQL vous indique :

Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 37

C’est que vous êtes connecté et que votre serveur MySQL fonctionne. Pour sortir, entrez « quit ».

Si ce n’est pas le cas, les log de MySQL sont :

/var/log/mysql.log
/var/log/mysql.err

Pour redémarrer MySQL, tapez la ligne de commande :

# /etc/init.d/mysql restart

NAT (Accéder à un serveur derrière le même NAT)

Situation initiale

Si vous n’utilisez pas votre serveur comme routeur d’accès à Internet, il sera très certainement derrière votre NAT. Cela signifie en particulier qu’il sera accessible en IPv4 à deux adresses différentes :

  • depuis l’Internet, à l’adresse (publique) de votre connexion ;
  • depuis votre réseau local, à une adresse privée du genre 192.168.0.42.

Quel problème pouvez-vous rencontrer ?

Vous devez avoir défini certains enregistrements DNS pour diriger les utilisateurs vers votre adresse IPv4 publique, par exemple :

www.example.com. A 192.0.2.42

Votre serveur web est maintenant accessible à l’adresse www.example.com pour tout le monde sauf vous ! En effet, votre serveur se trouve à l’adresse 192.168.0.42 dans votre réseau local, tandis que 192.0.2.42 est votre routeur.

Les solutions pour contourner ces problèmes

Utiliser une IPv6

La première option, qui est la plus simple si vous utilisez un système d’exploitation récent, consiste à utiliser le protocole IPv6. Si vous disposez d’un bon fournisseur d’accès (Free, Nerim ou FDN), il vous suffit d’activer la fonctionnalité IPv6 et de configurer votre modem personnel si nécessaire. Sinon, un tunnel IPv6 sera nécessaire.

Votre serveur obtiendra automatiquement une adresse IPv6, par exemple 2001:db8:4212:4212:4212:4212:4212:4212. Il vous suffit maintenant de l’ajouter dans votre domaine DNS en plus de votre adresse IPv4 :

www.example.com. AAAA 2001:db8:4212:4212:4212:4212:4212:4212

Puisque vous n’êtes pas derrière un NAT en IPv6, votre adresse est désormais publique et peut être accessible depuis l’Internet ainsi que depuis votre réseau local (en IPv6, votre réseau local fait également partie de l’Internet). Vous pouvez utiliser n’importe quel logiciel client qui prend en charge IPv6 pour accéder à vos services personnels.

Utiliser /etc/hosts

La solution la plus simple, mais aussi la moins évolutive, consiste à placer les noms de vos services dans le fichier /etc/hosts sur chaque ordinateur. Pour ce faire, ajoutez des lignes comme celle-ci :

192.168.0.42 example.com www.example.com

Lorsqu’un logiciel demande à votre système de résoudre un nom, ce fichier est vérifié avant le DNS et remplace votre définition de nom habituelle.

La solution « vue DNS »

Une solution sans faille pour un grand réseau qui ne dispose pas de la connectivité IPv6 consiste à utiliser un service DNS qui donne des résultats variables en fonction de la requête :

  • depuis Internet : www.example.com. A 192.0.2.42 ;
  • depuis votre réseau local : www.example.com. A 192.168.0.42.

L’utilisation d’un double NAT

Si vous avez le contrôle de votre routeur, il existe encore des moyens de le contourner et de rendre votre serveur accessible depuis votre réseau local à l’aide d’une double NAT. Cette approche est répandue parmi les freebox.

Nom de domaine dynamique

Comment fonctionnent les noms de domaine dynamiques ?

Pour publier vos services sur Internet, vous devez définir un enregistrement de nom de domaine qui pointe vers votre adresse IP publique dynamique, et modifier cet enregistrement lorsque l’adresse change : c’est ce qu’on appelle un nom de domaine dynamique. Par exemple, supposons que votre adresse IP publique change de temps en temps, aujourd’hui vous avez :

example.com. A 192.0.2.48

… et le lendemain, vous avez :

example.com. A 192.0.2.32

Il existe un certain nombre de services de noms de domaine dynamiques :

  • avec un protocole standard, spécifié dans la RFC 2136 ;
  • avec un protocole spécifique à un fournisseur particulier comme DynDNS.

Comment palier au problème d’IP dynamique ?

Un système de nom de domaine dynamique reste une stratégie pour contourner les restrictions artificielles d’une connexion Internet de seconde classe. Une telle technique présente toutefois des problèmes inhérents :

  • Chaque fois que l’adresse IP publique change, vos services sont indisponibles pour que les utilisateurs puissent accéder à la nouvelle version de l’enregistrement DNS, ce qui peut prendre de quelques minutes à une journée pour les résolveurs qui ne respectent pas les délais d’expiration.
  • Si vous utilisez une adresse IP publique dynamique, il est impossible de créer votre propre service de nom de domaine.

Comment mettre en place un nom de domaine dynamique avec le protocole standard ?

Le protocole de mise à jour dynamique standard de l’industrie permet à un client – vous – de demander à un serveur des serveurs DNS du fournisseur de supprimer un enregistrement existant et d’en ajouter un nouveau. Il est utilisé avec nsupdate, qui est fourni avec la suite de serveurs de noms BIND, et nécessite une clé cryptographique ou une paire de clés pour vérifier la demande.

Voyons cela, d’abord, côté client

Installation d’un nom de domaine dynamique

Commencez par utiliser les outils fournis avec BIND, par exemple sous Debian :

# apt-get install dnsutils

Comment générer vos clés ?

Créez la paire de clés SIG(0) qui sera utilisée pour signer vos demandes de mise à jour. Par exemple, gene.dyn.example.com doit être le nom de cette paire de clés :

$ dnssec-keygen -a RSASHA512 -b 4096 -n HOST -T KEY gene.dyn.example.com

Après avoir généré une paire de clés, il faut du temps pour générer les nombres aléatoires, après quoi vous recevrez deux fichiers : .key qui comprend la clé publique et .private qui contient la clé privée. Envoyez votre fichier de clé publique à votre fournisseur de services DNS dynamiques et attendez qu’il configure l’accès aux demandes de mise à jour signées.

Comment utiliser un client de mise à jour ?

Le client nsupdate, bien sûr, a besoin du fichier de clé privée pour signer la demande :

$ nsupdate -k Kgene.dyn.example.com*.private
> update delete gene.dyn.example.com.     A
> update add    gene.dyn.example.com. 300 A 192.0.2.32
> send

nsupdate envoie automatiquement la demande au serveur maître de la zone DNS contenant l’enregistrement concerné. Si le serveur est bien configuré pour accepter les demandes de mise à jour signées par cette clef, la demande devrait être acceptée et propagée immédiatement.

Comment automatiser cette opération ?

Dans la vie réelle, cependant, vous voudrez automatiser cette opération afin qu’une mise à jour soit transmise chaque fois que l’adresse IP publique change, idéalement dès qu’elle change et dans la mesure du possible, ou pour vérifier régulièrement si elle a changé.
Le script suivant, qui utilise l’outil MiniUPnP external-ip, n’a pas encore été testé. Gardez à l’esprit qu’il n’a jamais été utilisé auparavant :

previous_ip="$(cat /tmp/current-ip)"
current_ip="$(external-ip)"
name="gene.dyn.example.com"
ttl=300
 
if [ "$current_ip" != "$previous_ip" ]
then
    cat <<EOF | nsupdate -k "K$name"*.private
update delete $name      A
update add    $name $TTL A $current_ip
send
EOF
    printf '%s\n' "$current_ip" > /tmp/current-ip
fi

Si vous avez vérifié qu’il fonctionne, vous pouvez le placer dans la tâche cron d’un utilisateur spécifique qui aura la clé privée pour signer la demande de mise à jour.

Voyons cela, maintenant, côté serveur

Qu’est-ce qu’une zone dédiée ?

Pour fournir un service de nom de domaine dynamique avec BIND, vous devez créer une zone dynamique. C’est une bonne idée d’auto-déléguer une zone en dessous de la zone principale, comme dyn.example.com, car cela modifiera le fichier de zone correspondant chaque fois qu’il sera mis à jour.

Pour cela, dans le fichier de zone supérieur example.com :

dyn.example.com. NS ns

Et dans la configuration /etc/bind/named.conf ou /etc/bind/named.conf.local :

zone "example.com" {
        type master ;
        file "dyn.example.com.zone" ;
} ;

Remplissez le fichier de zone avec les informations initiales pour cette zone — SOA, NS, MX nul :

$TTL 600
@ SOA ns hostmaster.example.com. (
      2013040201 ; serial
      1y         ; intervalle de rafraîchissement systématique par les serveurs secondaires
      5m         ; temps d'attente avant de réessayer un rafraîchissement échoué pour les serveurs secondaires
      1w         ; temps d'expiration de la zone sur les serveurs secondaires si le rafraîchissement échoue
      5m         ; TTL minimum
  )
  NS ns.example.com.
  MX 0 .         ; pas de courrier électronique pour cette zone

Comment donner l’autorisation de mise à jour ?

En utilisant un service de nom dynamique, vous devez obtenir une clé publique SIG(0) de l’utilisateur pour que vous puissiez autoriser les mises à jour de son nom de domaine signées avec la clé privée correspondante et uniquement celles-ci. Cette clé publique est publiée dans l’enregistrement DNS de votre zone dynamique avec le nom visé par la mise à jour dynamique – comme pour tout autre changement, n’oubliez pas de modifier le numéro de série de la zone en conséquence :

gene.dyn.example.com. KEY 512 3 10 AwEAAe8yZcPoomw1H7iOodt1Ef3x7Xps9uy0r5lV+DIvx+9OdVGXOtmM …

Vous devez ensuite rendre la zone en question accessible aux modifications dynamiques pour les noms qui sont identiques ou similaires à la clé utilisée pour signer la demande. Il est judicieux de stocker cette zone dans un sous-répertoire de /var/cache/bind/ :

zone "example.com" {
        type master ;
        file "dyn.example.com.zone" ;
        update-policy {grant * self * ;} ;
} ;

Pour pouvoir effectuer les mises à jour dynamiques demandées par les clients, BIND doit également avoir un accès en lecture et en écriture au fichier de zone et au répertoire qui le contient :

# chown -R bind:bind /var/cache/bind/dyn

Finalement, demandez à BIND de vérifier vos zones, puis votre configuration, et finalement de l’appliquer :

# named-checkzone example.com example.com.zone
# named-checkzone dyn.example.com dyn.example.com.zone
# named-checkconf
# rndc reload

Mise en œuvre avec un protocole spécifique

DynDNS

DynDNS est un fournisseur de DNS dynamique, probablement le premier à avoir vu le jour. Il existe de nombreux clients DynDNS, et la plupart des modem-routeurs domestiques en intègrent d’ailleurs un.

Gandi

Le bureau d’enregistrement DNS Gandi propose une API spécifique, qui est utilisable pour envoyer des mises à jour de zone DNS.

Onak

Onak est un serveur de clefs OpenPGP.

Avant de vous lancer dans l’installation d’un serveur de clefs, vous devez régler quelques étapes préalables, décrites dans l’article générale sur le service de clés.

Comment installer Onak sur un serveur Debian ?

Vous devez au préalable avoir installé un serveur Web.

Installez simplement le paquet correspondant pour votre distribution, qui devrait porter le même nom. Par exemple, sous Debian, c’est le paquet onak.

Comment configurer Apache HTTPD ?

Onak est un service CGI, c’est à dire un ensemble d’exécutables destinés à être utilisés par un serveur Web pour générer des pages, ici des pages de service de clefs. Il faut donc configurer votre serveur Web pour cela.

Si vous utilisez Apache HTTPD, il faut tout d’abord le faire écouter sur le port HKP, soit le TCP 11371. Sous Debian, cela se fait en ajoutant les lignes suivantes au fichier de configuration /etc/apache2/ports.conf :

# Key server
NameVirtualHost *:11371
Listen 11371

Il faut ensuite créer un site virtuel dédié à Onak. Avec une configuration modulaire comme celle de Debian, il faut pour cela créer un fichier /etc/apache2/sites-available/keyserver :

<VirtualHost *:11371>
        DocumentRoot /var/lib/onak
        ScriptAlias /pks /usr/lib/cgi-bin/pks
        CustomLog /var/log/apache2/keyserver-access.log combined
        ErrorLog /var/log/apache2/keyserver-error.log
</VirtualHost>

Puis activer ce site virtuel avec la commande a2ensite keyserver, et relancer Apache HTTPD.

Comment publier un clé GnuPG ?

Maintenant que votre serveur de clefs fonctionne, vous pouvez y publier votre clef. Par exemple, avec GnuPG 2 – la version 1 n’implémente pas la distribution des clefs par domaine – :

$ gpg2 --keyserver example.com --send-keys 42424242

PHP

PHP est un langage de programmation côté serveur qui permet le développement dynamique de pages Web. Il permet l’automatisation de diverses activités de construction de pages, ainsi que l’adaptation au contexte de chaque consultation : au visiteur, au moment, etc.

Afin d’exécuter des pages PHP, vous devez installer l’interpréteur PHP sur votre serveur web ou en tant que moteur CGI.

En utilisant un accélérateur PHP, vous pouvez augmenter les performances en éliminant le code compilé des fichiers PHP (par exemple, xcache).

Comment installer PHP sous Apache HTTP Server ?

Pour l’installer sous Debian, il suffit d’exécuter la commande suivante :

# aptitude install libapache2-mod-php8

Vous pouvez maintenant utiliser PHP8 sur vos pages web personnelles ou votre site principal, mais vous devez placer les fichiers PHP dans le bon répertoire, /var/www/ ou ~/public_html/.

Postfix

Le logiciel libre Postfix est un serveur de messagerie ou MTA qui se veut rapide, sûr et simple à utiliser. Il s’agit d’une alternative au populaire Sendmail MTA. Postfix a été créé par Wietse Venema en 1997.

Postfix est un agent de transfert de courrier (MTA) responsable de la distribution des messages électroniques. Il utilise diverses méthodes de transport, notamment l’Internet Message Access Protocol (IMAP), le Simple Mail Transfer Protocol (SMTP) et le Local Mail Transfer Protocol (LMTP). Postfix peut également être utilisé comme serveur proxy pour d’autres MTA.

Postfix est disponible pour de nombreux systèmes d’exploitation, notamment Linux, BSD, Solaris, Mac OS X et Microsoft Windows. Il est publié sous la licence publique générale GNU (GPL).

Comment installer Postfix sur son serveur ?

Pour installer Postfix, commencez par lancer cette ligne de commande :

# aptitude install postfix

Comment configurer Postfix ?

Dans le fichier /etc/postfix/main.cf (vous pouvez commencer en téléchargeant mon fichier d’exemple), Postfix est configuré. Des variables sont utilisées dans la configuration, et des valeurs leur sont attribuées. La liste complète des variables peut être trouvée dans le manuel postconf(5). Les suivantes sont les plus essentielles :

#######################
# Paramètres généraux #
#######################
 
# Nom de domaine de messagerie principal.
mydomain = example.com
# Nom d'hôte. 
myhostname = tintin.example.com
# Nom de domaine utilisé pour les adresses incomplètes.
myorigin = $mydomain
 
# Activer l'écoute IPv6.
inet_protocols = all
 
# Les clients SMTP sûrs, qui auront plus de privilèges
# (concrètement, le droit d'utiliser ce serveur comme relais).
mynetworks = 127.0.0.0/8 [::1]/128
 
################
# Serveur SMTP #
################
 
# Les noms de domaine pour lesquels on accepte le courrier.
mydestination = example.com, tintin.example.com, localhost, localhost.localdomain
# Si votre FAI ne vous permet pas de poster le courrier directement,
# utiliser son serveur SMTP comme relais en décommentant cette ligne.
#relayhost = smtp.fai.com
 
#######################
# Distribution locale #
#######################
 
# Commande pour distribuer le courrier.
mailbox_command = procmail -a "$EXTENSION"
# Taille limite des BàL
mailbox_size_limit = 51200000
# Caractère séparant le nom de destinataire d'un paramètre additionnel
# (adresses « plussées », du type <untel+nawak@example.com> → <untel@example.com>)
recipient_delimiter = +

Avec cette configuration, vous disposez déjà d’un serveur de messagerie fonctionnel et assez sûr, adapté à votre domaine, ainsi que des valeurs par défaut de nombreuses autres variables configurables.

Comment régler finement vos restrictions SMTP ?

Il est possible que vous soyez déjà familier avec les restrictions SMTP, car elles sont souvent utilisées avec un logiciel antivirus. Pour affiner cet arrangement, vous pouvez renforcer les limitations SMTP. Voici comment envoyer un courriel d’un serveur à un autre :

1. Nous nous connectons au serveur example.com sur son port SMTP et commençons une transaction SMTP :

$ telnet example.com smtp

2. Le serveur répond en se présentant :

220 gene.example.com ESMTP Postfix

3. Nous nous présentons à notre tour :

HELO auto.example.net

4. Le serveur vous répond qu’il est disponible pour recevoir un message :

250 gene.example.com

5. Vous pouvez annoncer l’expéditeur, puis les destinataires du message :

MAIL FROM: <gene@example.net>
250 2.1.0 Ok
RCPT TO: <vieve@example.com>
250 2.1.5 Ok

6. Nous terminons en envoyant le message et en fermant la connexion :

DATA
354 End data with <CR><LF>.<CR><LF>
Le contenu du message, y compris les en-têtes.
.
250 2.0.0 Ok: queued as 22D2A8871
QUIT
221 2.0.0 Bye

On peut donc distinguer quatre étapes où le client soumet des informations :

  • l’ouverture de la connexion ;
  • le HELO, où il se présente comme client SMTP ;
  • le MAIL FROM, où il présente l’expéditeur du message ;
  • le RCPT TO, où il présente le ou les destinataires du message.

Chacune de ces étapes est soumise aux restrictions de Postfix : il s’agit de règles qui décident de l’acceptation ou du rejet d’un message. Par exemple, le serveur example.com doit :

  • refuser le courrier mal formé ;
  • accepter tout le courrier bien formé envoyé par les utilisateurs de son ordinateur ;
  • accepter tout le courrier bien formé envoyé à destination d’un utilisateur de son domaine ;
  • refuser tout le courrier reçu de l’extérieur à destination de l’extérieur, pour éviter d’être un relais ouvert de pourriel (SPAM).

Qu’est-ce qu’un « Relai ouvert » ?

Un relais ouvert (ou Open Relay) est un serveur de messagerie qui accepte les messages électroniques de n’importe qui vers n’importe quelle adresse. Les spammeurs utilisent fréquemment des relais ouverts pour distribuer leurs courriers indésirables.

Il est essentiel d’éviter que votre propre serveur fonctionne comme un relais ouvert. Sinon, il serait rapidement utilisé pour envoyer du spam, et il pourrait se retrouver sur des listes de blocage avant d’être rejeté par d’autres serveurs sur Internet. La configuration par défaut de Postfix n’est pas configurée pour fonctionner comme un relais ouvert, mais vous devez faire preuve de prudence lorsque vous le faites.

Voici un exemple de configuration plus personnalisée que les options de base :

# Règles pour accepter ou refuser une connexion :
# - on attend une seconde (pour piéger les zombies) ;
# - on interdit la parallélisation là où il n'est pas sensé y en avoir.
smtpd_client_restrictions =
    permit_mynetworks, permit_sasl_authenticated,
    sleep 1, reject_unauth_pipelining
# Règles pour accepter ou refuser un message, dès lors qu'on connaît le nom
# de l'hôte de l'expéditeur (par sa commande HELO ou EHLO) :
# - on refuse les noms d'hôte invalides.
smtpd_helo_restrictions = reject_invalid_helo_hostname
# Règles pour accepter ou refuser un message, dès lors qu'on connaît l'adresse
# de l'expéditeur :
# - s'il vient d'un expéditeur inexistant de notre domaine, on le rejette ;
# - si le domaine de l'expéditeur n'a pas d'IP ou de MX, on le refuse ;
# - s'il vient d'un client sûr ou d'un client authentifié, on l'accepte ;
# - si l'adresse de l'expéditeur n'est pas sous forme canonique, on le refuse.
smtpd_sender_restrictions =
    reject_unlisted_sender, reject_unknown_sender_domain,
    permit_mynetworks, permit_sasl_authenticated,
    reject_non_fqdn_sender
# Règles pour accepter ou refuser un message, dès lors qu'on connaît le
# destinataire (par la commande RCPT TO) :
# - s'il est destiné à un expéditeur forgé chez nous, on le rejette ;
# - s'il est destiné à un domaine forgé, on le rejette ;
# - s'il vient d'un hôte sûr ou d'un client authentifié, on l'accepte ;
# - si l'adresse de destination n'est pas sous forme canonique, on le refuse ;
# - finalement, s'il n'est pas destiné à un domaine que l'on gère ou pour
#   lequel on relaie, on le refuse.
smtpd_recipient_restrictions =
    reject_unlisted_recipient, reject_unknown_recipient_domain,
    permit_mynetworks, permit_sasl_authenticated,
    reject_non_fqdn_recipient,
    reject_unauth_destination

Comment tester sa configuration de Postfix pour vérifier qu’elle est fonctionnelle ?

Rechargez Postfix après avoir modifié le fichier de configuration main.cf :

/etc/init.d/postfix reload

Après avoir vérifié que vous avez remplacé les paramètres de configuration essentiels, vous pouvez envoyer des tests à votre serveur. Vous pouvez tester votre configuration en envoyant un message directement par SMTP. Envoyez et recevez des adresses à l’intérieur et à l’extérieur de votre domaine pour voir laquelle fonctionne le mieux. Voici ce que vous devez dire pour une transaction SMTP (les réponses du serveur s’intercaleront entre vos phrases) :

$ telnet example.com smtp
HELO nom.de.la.machine.cliente
MAIL FROM: <xxx@example.net>
RCPT TO: <xxx@example.com>
RCPT TO: <xxx@example.org>         # si vous voulez envoyer un mail à plusieurs destinataires
DATA
From: Geneviève <xxx@example.net>
To: Récepteur <xxx@example.com>  # on met <xxx@example.org> en copie cachée (CCi) !
Subject: Test

Essai.
.
QUIT

Le courrier est ensuite distribué dans les boîtes aux lettres des utilisateurs correspondants : /var/mail/user. Mail, ou Mutt si vous l’avez installé, peut être utilisé pour vérifier votre courrier de manière basique à partir du Shell.

Comment mettre en place un relais de courrier avec identification ?

Vous pouvez maintenant envoyer et recevoir des e-mails à partir de votre serveur. Vous pouvez également configurer votre serveur en tant que relais de messagerie, ce qui vous permettra d’envoyer des courriers électroniques depuis n’importe où sur Internet tout en étant connecté.

Postfix doit employer un serveur SASL externe pour effectuer l’identification des utilisateurs par nom d’utilisateur et mot de passe. Dovecot ou Cyrus SASL sont deux applications de ce type qui peuvent être utilisées à cette fin. Nous proposons d’utiliser Dovecot, surtout si vous souhaitez l’utiliser également pour le service de boîte aux lettres.

Comment configurer Dovecot avec Postfix ?

Comme Postfix ne dispose pas d’un service d’identification propre, il doit se connecter à un serveur SASL externe. Dovecot peut fonctionner comme un serveur SASL ! Pour activer ce service, ajoutez (ou décommentez) ceci dans la section auth default du fichier de configuration /etc/dovecot/dovecot.conf pour Dovecot 1.2

auth default {
  …
  socket listen {
    client {
      path  = /var/spool/postfix/private/auth
      group = postfix
      mode  = 0660
    }
  }
  …
}

ou dans la section service auth du fichier /etc/dovecot/conf.d/10-master.conf pour Dovecot 2 :

service auth {
  …
  unix_listener auth-userdb {
    …
  }
 
  # Postfix smtp-auth
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    group = postfix
  }
}

Dovecot doit établir un socket Unix par lequel il écoutera les requêtes d’identification de Postfix. Comme le répertoire /var/spool/postfix/ est chrooté (piégé), ce socket doit être placé à cet endroit. Redémarrez Dovecot maintenant :

# /etc/init.d/dovecot restart

Comment configurer Postfix avec Dovecot ?

Postfix peut être utilisé pour accepter le courrier des utilisateurs qui sont actuellement connectés. Cependant, il ne comporte aucune fonction d’identification ! Tout ce que vous avez à faire est de configurer Postfix pour qu’il se connecte au service de connexion (dans le fichier /etc/main.conf) :

# Activer l'identification SASL
smtpd_sasl_auth_enable = yes
# Utiliser le service d'identification de Dovecot
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
# Noter dans les en-têtes des messages l'identifiant de l'utilisateur.
smtpd_sasl_authenticated_header = yes

Postfix écoute actuellement sur le port SMTP, et proposera une identification uniquement après que le client sera passé en connexion sécurisée (en TLS, avec la commande STARTTLS). Le port SMTP étant souvent bloqué par des fournisseurs d’accès, si vous comptez utiliser votre serveur comme relais depuis des connexions étrangères, vous devriez également activer deux autres services :

  • SMTPS : c’est un service SMTP par-dessus une connexion SSL, sur un port spécifique ;
  • submission : c’est un service SMTP dédié au relais, qui doit imposer une identification, sur un port spécifique.

Pour cela, éditez le fichier de configuration /etc/postfix/master.cf, qui définit les options spécifiques des différents services de Postfix. SMTPS et submission sont des services de type smtpd, qui vont utiliser le fichier de configuration /etc/postfix/main.cf, sauf pour certains paramètres que nous surchargeons aver les options -o :

smtp      inet  n       -       -       -       -       smtpd
submission inet n       -       -       -       -       smtpd
  -o smtpd_enforce_tls=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
smtps     inet  n       -       -       -       -       smtpd
  -o smtpd_tls_wrappermode=yes

Terminez enfin en relançant Postfix :

# /etc/init.d/postfix restart

Comment tester si le relai de courrier fonctionne ?

Vous pouvez maintenant tenter d’envoyer du courrier depuis un autre ordinateur client en configurant votre programme de messagerie pour qu’il utilise votre serveur comme relais. Pour ce faire, créez un compte SMTP avec les paramètres suivants sur le port de soumission (587) : Votre login Unix et votre mot de passe pour le compte SMTP.

Redirections de port

Dans la plupart des cas, vous ne disposez que d’une seule adresse IP publique pour votre modem en IPv4. Les adresses privées sont utilisées par les ordinateurs de votre réseau domestique.

NAT

Ces adresses privées sont toutes masquées (NAT) derrière leur adresse publique afin d’accéder à l’Internet. Votre routeur (ou la box de votre FAI) ne fait que recevoir les flux entrants.

Voici un exemple de flux de données derrière un NAT

Redirections

Cependant, vous souhaitez offrir des services via votre connexion qui ne sont pas fournis par votre routeur. Pour ce faire, vous devez mettre en place une redirection de port. Il s’agit de rediriger le trafic entrant vers votre serveur.

Schéma représentant un flux redirigé

Pour ce faire, vous devez vous connecter à l’interface d’administration de votre routeur (généralement ici ou là chez Free), où vous trouverez votre configuration.

Nom (indicatif)ProtocolePortAdresse privéePort
SSHTCP22192.168.0.1222
SMTP (courrier)TCP25192.168.0.1225
HTTP (Web)TCP80192.168.0.1280
HTTPS (Web sécurisé)TCP443192.168.0.12443
XMPP-client (MI)TCP5222192.168.0.125222
XMPP-server (MI)TCP5269192.168.0.125269
DNSTCP53192.168.0.1253
DNSUDP53192.168.0.1253

Bien entendu, vous pouvez rediriger n’importe quel port externe vers n’importe quel autre port de n’importe quelle machine. Bien que le numéro de port ne doive pas être identique, il doit être suffisamment proche pour des raisons de sécurité. Par exemple, vous pouvez changer le port choisi au hasard de votre serveur SSH en 22 afin d’éviter d’être harcelé par des attaques par force brute trop fréquemment.

Comment continuer à accéder à son serveur ?

Si vous êtes derrière le même pare-feu que votre propre serveur, il peut être difficile d’y accéder : c’est le sujet d’un billet complet.

Référencement de site web

Vous pouvez faire enregistrer votre nom de domaine, et une fois que c’est fait, vous pouvez soumettre votre site aux moteurs de recherche. Cela implique d’informer les moteurs de recherche de l’existence de votre site web afin que vous puissiez être trouvé par une recherche par mot-clé sans attendre qu’ils vous découvrent.

Si vous n’avez pas encore créé votre site Web, vous pourriez envisager de passer par EasyHoster qui propose des offre clés en main de sites WordPress et/ou WooCommerce tout fait. Si vous ne connaissez pas encore cet hébergeur, je vous recommande la lecture de l’article EasyHoster, présenté par Kim Communication.

Vous n’aurez pas à attendre qu’un autre site Web soit déjà mentionné, car vous serez invisible pour Google.

Comment indiquer l’existence de votre site Web auprès des moteurs de recherche ?

Voici les pages de chaque moteur de recherche qui peuvent être utilisées pour promouvoir votre site web :

  • Google (recherchez « add URL » dans Google)
  • Bing (recherchez « Submit a web site dans Bing)

Faire appel à des référenceurs professionnels ?

Certains freelances ou agences SEO vous référenceront sur de nombreux moteurs de recherche, gratuitement ou non. Pour plus d’informations, voir « référencement » (sur un moteur de recherche justement).

Comment empêcher le référencement de son site Web sur les moteurs de recherche ?

Vous pouvez vouloir empêcher les moteurs de recherche de voir certaines parties de votre site. Il suffit de créer un fichier nommé robots.txt à la racine du site et de le remplir avec les directives appropriées.

Routeur

Comment configurer un routeur ?

La boîte qui a été donnée à tout le monde, ou même le simple modem que certains d’entre nous possèdent, est en fait considérée comme un équipement de tête de réseau par le fournisseur… et elle lui appartient ! C’est aussi sous son contrôle total !

A partir de maintenant, il va falloir être assez schizophrène ! Votre FAI a un contrôle total sur votre box internet et votre TVBox, ainsi que sur le réseau télécom, le LAN entre la box et la boîte à images, et le LAN entre la box et vos machines. Alors que techniquement et légalement, vous êtes responsable de l’ensemble de votre installation chez vous, du câble en cuivre appelé câble téléphonique (ou télé) qui pend au bout de votre prise mal scellée jusqu’au moindre octet sur vos disques durs…

Pendant les sessions de maintenance, la configuration d’un boîtier peut être entièrement perdue ou modifiée à distance (ce dont vous n’êtes pas informé). Le scénario le plus fréquent est que le fournisseur d’accès réinitialise complètement le boîtier.

Même si vous bloquez et masquez le port de télémaintenance initialement accessible au FAI pour le FAI, cela peut toujours se produire. Des fournisseurs comme NuméricableTM, par exemple, emploient des bots pour le faire automatiquement.

Une douzaine de réinitialisations chaque jour avec une nouvelle mise à jour du firmware et une modification de l’IHM pour améliorer.

En outre, des lois sont en train d’être adoptées concernant ces boîtes, qui ne vous appartiennent pas et sur lesquelles vous n’avez aucune autorité, mais dont vous serez entièrement responsable !

Nous ne faisons même pas confiance au boîtier TVCOM, que nous laissons simplement allumé pour avoir un routeur télécom « professionnel » au lieu de ces trucs tout en plastique (ce qu’on appelle généralement un routeur d’agence).

Exemple : la LiveBox Pro™ est une Box d’agence, et l’ancien X2300™ anciennement fourni par Orange™ est un vrai routeur d’agence à l’accent bien teuton. On en trouve maintenant dans les poubelles ! Si vous avez un ADSL campagnard (lent) ou du RNIS (encore plus lent) : profitez en ! Surtout que l’expérience a montré que ce matériel tient bien la foudre et les remontées de terre!

Donc typiquement : on règle sur la Box uniquement ce qui concerne la gestion du brin “WAN” même au niveau IP, on effectue la sauvegarde de la configuration dans un fichier rechargeable vite fait ultérieurement. On place un routeur local derrière la Box, et uniquement ça.

Bref la Box ne fait rien ou presque et vous assurez le reste… C’est le seul moyen de ne pas voir de nouvelle configuration chargée par on ne sait qui sur une machine critique.

Les règles de mise en place à suivre pour la configuration de votre Routeur pour l’auto-hébergement

Oubliez le Wifi™, le BluetoothTM et le CPL sur la Box à moins que vous ne vouliez mettre votre tête sur le billot…. Même si cela procure d’agréables frissons à certains (chacun son truc), il y a plein d’individus peu recommandables dehors qui tentent de pirater la Box de Madame Michou !

Si vous autorisez un point d’appui incontrôlable à quiconque, vous pouvez être tenu responsable de tout et n’importe quoi. C’est pourquoi nous contrôlons les points d’appui incontrôlables et veillons à ce qu’ils soient efficaces, quelles que soient les actions à distance des fournisseurs.

Le boîtier qui vous a été envoyé est conçu pour gérer la connexion, ainsi que tous les protocoles nécessaires pour se connecter à l’équipement de votre fournisseur d’accès, sans problème. C’est merveilleux que cela fonctionne… PPPoA, syncPPP, PPPoE, et les protocoles propriétaires en font partie. Oubliez-les !

Voici une liste des services locaux qui peuvent être activés :

  • Connexion et gestion de ligne de votre prestataire TELECOM.
  • NAT sur la ligne TELECOM. Mais attention : certaines Box n’autorisent qu’un nombre limité de transactions sortantes NAT.
  • Redirections NAT du routeur TELECOM vers le routeur LAN. Massives et sans finesse… Pas de problème, vous gérez cela ailleurs.
  • Si on peut faire autrement sans utiliser le NAT : utiliser l’IP par la Box vers le serveur LAN et gérer le NAT sur celui-ci.

Voici les services locaux que vous devriez envisager afin de maintenir votre zone de télécommunication opérationnelle :

  • Export des logs de la Box vers le service centralisé interne de logging.
  • IHM interne de configuration de la Box (interdiction sur le réseau TELECOM).
  • Synchronisation de l’horloge interne de la Box sur le serveur de temps local (lui même, si vous avez les moyens, connecté directement sur une demi-douzaine d’horloges au Cesium en accès libre et sponsorisées par le département de la défense américaine. L’Europe est encore un peu en retard à ce niveau.).
  • Service local de dynDNS déclenché sur un changement de configuration de l’interface TELECOM. (Avec un second service dynDNS en secours sur le routeur LAN vers un autre prestataire dynDNS).
  • Export d’un fichier de configuration rechargeable.

Comment fonctionne le pare-feu (firewall) d’un routeur et comment l’utiliser pour de l’auto-hébergement ?

Le cas du routeur intégré au serveur ou du routeur externe

Il s’agit de la description d’un pare-feu intégré à une machine auto-hébergée qui remplit également les rôles de pare-feu, de routeur et de serveur. Le mot « bastion » fait référence à de telles machines.

Bien que ce type de configuration n’ait pas été enseigné dans un cadre universitaire, il convient également à la configuration du pare-feu qui sera placé au-dessus d’un routeur LAN situé derrière la Box.

Comment conserver un routeur sain ?

Dans cette description, nous appellerons les réseaux par les noms suivants :

Réseau «noir» : Vous êtes désormais connecté à la boîte par Internet (et même pas à l’extérieur). C’est un monde où tout existe de manière isolée, c’est pourquoi on l’appelle « le web sauvage » Vous êtes en fait sur un réseau commercial qui appartient à votre fournisseur.

Réseau «rouge» : Vous êtes probablement sur un réseau local sans fil connecté à l’Internet au sens large. Les points d’accès Wifi(tmp), les coupleurs CPL et les câbles tirés dans le jardin pour se connecter avec votre voisin sont typiques.

Réseau «vert» : réseau LAN interne de confiance !

Réseau «orange» : réseau LAN interne à confiance limitée mais plus relax que le «rouge» mais pas aussi libre que le «vert».

Il est illégal de construire un réseau sur la voie publique.

Les règles de bases à connaitre sur les différents réseaux

  • Sur les réseaux gérés localement, tout ce qui n’est pas expressément autorisé est interdit. Cela se traduit par un principe général lié à une règle tout aussi spécifique associée à chaque interface réseau.
  • La sortie de la règle de pare-feu est un fichier journal (nommé, par exemple, firewall.default.log) qui enregistre tout trafic « inconnu » qui a été intercepté par la politique par défaut.
  • Pour assurer l’uniformité du trafic acheminé, créez des règles génériques.
  • Sauf pour les nécessités absolues : ni les transactions sur les interfaces du réseau local ne sont interdites ni ne doivent être enregistrées.
  • Pour simplifier les choses, toutes les transactions ICMP seront traitées de la même manière : dans mon cas, DROP pour les réseaux « publics » et LOG pour les réseaux de confiance.
  • Le routeur/pare-feu transmet simplement le trafic réseau au port syslog (514) pour tout le matériel sensible (routeur, AP(s) Wifi, etc.). Les transactions ne sont acceptées à partir de ces appareils que si elles sont spécifiquement demandées.
  • Toute transaction est tracée par inspection “state-full”.
  • Un soin particulier est demandé lors de la mise en place des “gateways authentifiées” (traduction : autorisations de routage spécifiques par identification par clef publique/privée).
  • Vous devez suivre tout ce qui entre ou sort du réseau public (WAN) ou d’un LAN local, ainsi que tout ce qui entre et sort du réseau interne de votre entreprise. Et ceci pour respecter les réglementations légales, c’est donc non négociable.
  • Il est important de garder une trace de chaque petite chose qui cause des problèmes afin de comprendre comment améliorer les choses. Comme l’opérateur du système dispose d’une plus grande expertise, ce type de journalisation est personnalisable. Tout est négociable ici.
  • La conformité légale impose la collecte, la maintenance et l’analyse des logs pour se conformer à des réglementations telles que PCI DSS. Un système centralisé de gestion des journaux est nécessaire pour automatiser leur gestion et satisfaire aux exigences légales telles que l’enregistrement des journaux, le nettoyage des données et la conservation.
  • Il ne faut pas saturer le système de gestion des logs… l’enregistrement des établissements de transaction est suffisant pour ce qui nous concerne.

Les règles spécifiques au Réseau noir

  • Un fichier journal de type firewall.noir.log est utilisé pour enregistrer toutes les transactions en provenance et à destination du réseau « noir ».
  • Tous les services locaux de la machine, exactement spécifiés, sont autorisés et enregistrés.
  • L’utilisateur n’est pas autorisé à se connecter depuis l’extérieur du réseau local, et aucune connexion n’est enregistrée dans tous les cas. Seuls les services qui ont été redirigés vers les réseaux locaux sont autorisés et connectés, et cela est clairement indiqué.
  • Assurez-vous que seul le routeur LAN, ainsi que toute autre machine désignée par vous, peut accéder à l’interface graphique de gestion du routeur WAN.

Les règles spécifiques au Réseau vert

  • Toutes les transactions sont autorisées et enregistrées dans un fichier firewall.vert.log.

Les règles spécifiques au Réseau rouge

  • Certains services ne sont accessibles que depuis l’intérieur du pare-feu et sont enregistrés dans un fichier firewall.rouge.log : NTP, BIND, HTTP, et ainsi de suite.
  • Certains services, comme POP3 et IMAP, sont autorisés et enregistrés dans un fichier firewall.red.log : PIPE (Post Office Protocol version 3), HTTPS, POP3S, IMAPS, etc.
  • Tout le reste est interdit.
  • Il n’y a pas d’insertion de règle pour ce réseau.
  • Seul le routeur du réseau local ou tout autre dispositif spécifié par vous doit pouvoir accéder aux interfaces graphiques de gestion des points d’accès et autres gadgets critiques.

Les règles spécifiques au Réseau orange

  • Comme le réseau «rouge» avec des règles d’assouplissement en plus ; règles qui sont souvent spécifique à la configuration locale.
  • Avec au besoin un ou deux points d’insertion et de retrait de règle pour le contrôle à distance. (N.d.l.a. : mon «atelier» subit ce genre de «règles» : cela évite la casse en public).
  • La DMZ se trouve par là !
  • Tous les logs ont lieu dans un fichier firewall.orange.log.

Petites règles routeur complémentaires

  • La boîte envoie ses données au routeur/pare-feu, qui les enregistre automatiquement dans le fichier routerr.noir.log.
  • TOUS les équipements sensibles ou exportateurs de logs sont liés au serveur de temps du routeur/pare-feu ou à toute machine LOCALE SIMPLE !

Que faut-il retenir des règles réseaux ?

La mise en place est un peu difficile, mais tout se règle à l’aide de fichiers de configuration de 100 à 200 lignes. Parce qu’il est si organisé et synthétique, il est simple à dépanner.

RSYNC

RSYNC est un utilitaire open source qui permet le transfert incrémental rapide de fichiers. Il est largement utilisé pour les sauvegardes et la mise en miroir, ainsi que pour le transfert de données entre les systèmes locaux et les systèmes de gestion de l’information .

RSYNC utilise un algorithme de transfert delta pour minimiser les transferts de données sur le réseau. Il détecte les blocs modifiés dans le fichier source et ne transfère que ces blocs, en utilisant des flux de données compressés pour une efficacité maximale. RSYNC peut fonctionner en mode push ou pull. En mode push, il initie un transfert du système local vers le système distant. En mode pull, il demande un transfert au système distant.

RSYNC est disponible pour la plupart des systèmes d’exploitation, notamment Linux, Unix, BSD, macOS et Windows. Il s’agit d’un outil standard inclus dans de nombreuses distributions Linux populaires.

Exemple de sauvegarde locale avec RSYNC

Dans cet exemple (testé sur un système Debian 7.0), nous allons programmer une sauvegarde journalière, vers un média amovible (testé avec une clé usb, mais un disque dur externe ferait tout aussi bien l’affaire). Le support amovible reste bien entendu, dans ce cas, connecté en permanence à notre machine.

Préparation du média de sauvegarde

Connectez votre clé/disque externe sur votre machine, utilisez la commande :

# fdisk -l

pour savoir quel device (/dev/sdX) lui correspond.

Attention aux manipulations suivantes, potentiellement dangereuses pour vos données en cas d’erreur !

Partitionnement / formatage du média :

# fdisk /dev/sdX

Créer une partition de type Linux, non bootable.

Formatage de la partition :

# mkfs.ext4 -L backup-usb1 /dev/sdX1

Notez l’utilisation d’un label (=nom du volume), à modifier selon vos désirs.

Montage dans le fstab via son LABEL

# nano /etc/fstab

Ajoutez la ligne suivante :

LABEL="backup-usb1"     /mnt/usb        auto    defaults,noauto 0       2

Le média ne sera pas monté automatiquement lors du démarrage du système (option “noauto”)

Test de montage / démontage du média :

# mkdir -p /mnt/usb && mount /mnt/usb && umount /mnt/usb

S’il n’y a pas d’erreur, votre média est prêt à être utilisé.

Script de sauvegarde

Créer le script Bash suivant, vous pouvez le stocker dans le dossier /root par exemple.

Adaptez les variables SRC, EXCLUDE, DEST, OPTIONS selon vos besoins.

Note : par défaut le script lance rsync avec l’option

--dry-run

(mode simulation, aucun fichier n’est réellement écrit ou supprimé sur le média de destination) pour vous permettre de le tester en toute sécurité.

L’option

--delete

supprimera, sur le média destination, les fichiers qui n’existent plus dans la source de sauvegarde.

#!/bin/bash
# -----------------------------------------------------------------------------------------
# mybackup.sh : simple backup script using rsync
#
# http://agentoss.wordpress.com
#
# make sure /etc/fstab contains an entry for DEST, for example :
# LABEL="backup-usb1"     /mnt/usb        auto    defaults,noauto 0       2
 
# directories to backup
SRC="/root /etc /home /var"
 
# directories NOT to backup
EXCLUDE="--exclude /var/tmp --exclude /var/cache --exclude /var/run --exclude /var/lock"
 
# backup destination mount point
DEST="/mnt/usb"
 
# options for rsync (remove -v --dry-run when everything is well tested)
OPTIONS="-az --stats --delete -v --dry-run"
 
# minimal error handling
if [[ -z "$DEST" || -z "$SRC" ]];then
 echo "$0 : aborted : SRC or DEST not specified!"
 exit 1
fi
# empty OPTIONS mean "dry run"
[[ -z "$OPTIONS" ]] && OPTIONS="--dry-run"
 
# make sure DEST is not mounted already
umount "$DEST" 2>/dev/null
 
# do a fsck on DEST
/sbin/fsck -a "$DEST"
result=$?
if [[ $result -gt 1 ]];then
 echo -e "$0 : fsck failed, backup cancelled.\nCheck or replace media $DEST\n"
 exit 1
fi
 
# mount DEST and execute backup cmd
if mount "$DEST";then
 msg="*** an error or warning occured! ***"
 cmd="rsync $OPTIONS $EXCLUDE $SRC $DEST"
 echo "$cmd"
 time $cmd && msg="*** OK ***"
 echo -e "\n$0 : rsync : $msg\n\nInformation on $DEST:\n$(df -h|head -1; df -h|grep $DEST)"
 umount "$DEST"
 exit 0
else
 echo "$0 : aborted : mount $DEST failed!"
fi
 
# exit with error code
exit 1

Vous pouvez lancer le script afin de visualiser son déroulement (n’oubliez pas de lui donner les droits d’exécution) :

# ./mybackup.sh

Une fois que tout fonctionne comme prévu, vous pouvez enlever les options :

-v --dry-run

de la variable OPTIONS.

Comment automatiser vos bash RSYNC pour réaliser vos backups ?

Ajout d’un job dans le crontab :

Exemple pour une exécution tous les jours à 03h00 :

0 3 * * * /root/mybackup.sh

Comme toujours grâce à une CRON, le résultat du script sera envoyé par courriel (à root dans notre cas), ce qui permet de s’assurer que tout se passe bien.

Serveur de courrier secondaire

Lorsque votre serveur de messagerie est en panne, les serveurs d’envoi de vos correspondants mettent leur courrier sortant en attente : il est normal qu’il soit conservé pendant cinq jours avant d’être tenté à nouveau. Si vous avez des amis qui gèrent leur propre serveur, vous pouvez les définir comme vos serveurs secondaires. Dès que votre service redevient accessible, vous pouvez leur demander de tenter à nouveau de distribuer votre courrier.

Actions à entreprendre sur votre serveur

Il n’y a pas grand-chose à faire sur votre serveur de messagerie principal.

Cependant, il est avantageux pour vos serveurs de sauvegarde de connaître la liste des adresses e-mail de votre domaine afin qu’ils puissent immédiatement rejeter le courrier destiné à des utilisateurs inexistants. Pour ce faire, suivez les étapes suivantes :

  • faites la liste de vos utilisateurs Unix réels (cela exclut les utilisateurs systèmes comme www-data, par exemple) ;
  • faites la liste de vos adresses d’aliases (/etc/aliases) ;
  • mettez cette liste sous forme verticale, une adresse par ligne, en les faisant suivre par « OK », dans un fichier portant le nom de votre domaine :
gene@example.com       OK
postmaster@example.com OK
abuse@example.com      OK
hostmaster@example.com OK
root@example.com       OK
admin@example.com      OK
  • vous pouvez préparer cette liste automatiquement avec la commande suivante, en l’élaguant des utilisateurs système :
awk -v domain=example.com -F: "\!/^(#|$)/{print \$1 \"@\" domain \"\t OK\"}" /etc/passwd /etc/aliases
  • préparez un hachage Postfix à partir de ce fichier :
# postmap example.com
  • transmettez ce fichier example.com.db à l’administrateur de votre futur serveur secondaire.

Actions à entreprendre sur les serveurs secondaires

Les serveurs secondaires, eux, doivent être réglés pour accepter le courrier à destination de votre domaine. S’ils utilisent Postfix, cela se règle ainsi, dans /etc/postfix/main.cf :

relay_domains = example.com
relay_recipient_maps = hash:/etc/postfix/relay/example.com # votre fichier de liste

Il peut être également intéressant d’augmenter la durée de conservation des courriels en file d’attende (par défaut à 5 jours) :

maximal_queue_lifetime = 14d  # Conservation des courriels pendant 14 jours.

Il suffit maintenant de recharger la configuration de Postfix : ce serveur accepte maintenant le courrier pour votre domaine example.com. et le transfère tout seul au serveur MX principal.

# /etc/init.d/postfix reload

Que faut-il modifier au niveau de vos DNS ?

Vous pouvez maintenant essayer d’envoyer un message à une adresse de votre domaine, puis à une fausse adresse, en utilisant le serveur secondaire que vous venez de mettre en place. Si vous êtes satisfait de son service, vous pouvez l’ajouter à la liste de vos serveurs de courrier, dans votre domaine DNS :

@       MX      10      mx              # serveur primaire,   priorité 10
@       MX      20      mx.example.org. # serveur secondaire, priorité 20

N’oubliez pas de modifier le numéro de série de votre zone et de la recharger :

rndc reload example.com

Serveur de noms secondaire

Le système DNS permet d’utiliser de nombreux serveurs de noms pour un domaine, ce qui permet de maintenir le service en cas de panne d’un serveur. Plusieurs enregistrements NS sont définis dans le registre et dans le domaine lui-même, ainsi que plusieurs enregistrements NS.

L’idée d’utiliser des serveurs de secours est la suivante :

  • lors de leur mise en place, les serveurs secondaires, asservis, récupèrent le fichier de zone complet auprès du serveur maître ;
  • à chaque modification du fichier de zone, le serveur maître envoie aux serveurs asservis une notification ;
  • à la réception de cette notification, les serveurs asservis récupèrent les changements apportées.

Voici comment établir votre configuration et fournir des instructions à un ami sur example.org pour qu’il serve de serveur esclave pour votre domaine, en tant qu’administrateur d’un domaine exemple.com et propriétaire d’un example.com.

Actions à entreprendre sur le serveur « maître » (principal)

Votre zone doit être sécurisée lorsqu’elle est copiée sur un serveur asservi. En effet, vous devez éviter ce qui suit :

que n’importe qui puisse se faire passer pour votre serveur secondaire et récupérer toutes les informations de votre zone ;
que n’importe qui puisse se faire passer pour votre serveur primaire et fournir des fausses informations à vos serveurs secondaires.
La réplication DNS est basée sur le système de signature numérique TSIG, qui est un mécanisme symétrique. Il s’agit d’un système symétrique. Les serveurs primaires et secondaires partagent le même secret (celui-ci peut être différent pour chaque serveur secondaire ; il doit simplement être partagé par les deux parties engagées dans un échange).

La première étape consiste donc à générer une clef TSIG, à laquelle on donne généralement un nom composé de la concaténation des noms des serveurs impliqué, comme s’il s’agissait d’un nom d’enregistrement DNS de votre zone :

# mkdir tsig ; cd tsig
# dnssec-keygen -n HOST        # type de clé \
                -a HMAC-SHA512 # algorithme de signature \
                -b 512         # taille de clé \
                ns.example.org.ns.example.com. # nom de la clé

Cela génère deux fichiers, un .private et un .key. Comme il s’agit ici d’un algorithme symétrique, les deux contiennent en fait les mêmes données, et doivent rester secrètes. Vous pouvez maintenant modifier votre fichier de configuration de BIND, /etc/bind/named.conf[.local], pour y ajouter la clef et autoriser le transfert de votre zone aux serveurs disposant de cette clé :

key ns.example.org.ns.example.com. {
        algorithm hmac-md5 ;
        secret "le contenu de la clef, récupéré dans un des fichiers générés" ;
} ;

zone example.com {
        type master ;
        file "master/example.com.zone" ;
        allow-transfer { key ns.example.org.ns.example.com. ;} ;
} ;

Sur ce, demandez à BIND de recharger sa configuration :

# rndc reload

Actions à entreprendre sur le serveur « asservi » (secondaire)

Vous devez transmettre le contenu de la clé à l’administrateur du serveur qui hébergera votre NS secondaire. Il devra alors modifier son fichier de configuration BIND pour y inclure la définition de cette clé, ainsi que votre serveur maître et votre zone :

key ns.example.org.ns.example.com. {
        algorithm hmac-md5 ;
        secret "le contenu de la clé, récupéré dans un des fichiers générés" ;
} ;
masters ns.example.com { votre_adressse_IP key ns.example.org.ns.example.com. ;} ;

zone example.com {
        type slave ; notify no ;
        file "slave/example.com.zone" ;
        masters ns.example.com ;
} ;

Et votre adresse IP dans tout ça ?

Lorsque vous modifiez votre zone, votre serveur en informe ses serveurs esclaves. Les serveurs esclaves, quant à eux, contacteront directement votre serveur pour les premiers transferts et les transferts réguliers : ils doivent connaître son adresse IP pour ce faire.
Votre serveur envoie toutes les notifications NS à toutes les entrées NS de votre fichier de zone. Par conséquent, les notifications ne fonctionneront pas, sauf si vous utilisez l’option also-notify dans votre bloc de définition de zone, jusqu’à ce que vous ajoutiez votre serveur esclave à votre fichier de zone.

Il faut enfin vérifier que BIND peut écrire dans le répertoire /var/cache/bind/slave/, où il devra écrire le fichier de zone récupéré, puis recharger sa configuration :

# rndc reload

Que faut-il indiquer dans le fichier de zone ?

Vérifiez que la réplication fonctionne correctement en recherchant des lignes dans le fichier journal BIND indiquant qu’elle fonctionne, /var/log/daemon.log, après que l’administrateur du serveur esclave ait rechargé sa configuration. Examinez ensuite le comportement du serveur esclave face aux requêtes DNS en lui demandant divers enregistrements :

$ dig A www.example.com. @ns.example.org.

Si vous êtes satisfait de votre serveur asservi, vous pouvez l’ajouter à la liste de vos NS, dans votre fichier de zone :

@       NS      ns
@       NS      ns.example.org.

Vous devez également effectuer cette modification auprès de votre bureau d’enregistrement, pour qu’il demande au registre de mettre à jour les enregistrements glue correspondants.

SFTP

SFTP est un protocole de transfert de fichiers qui fonctionne avec un serveur SSH pour accéder aux fichiers et aux répertoires d’un ordinateur. Il fournit les mêmes droits sur la machine à toute personne qui l’utilise que ceux appartenant à l’utilisateur avec lequel vous établissez une connexion. En d’autres termes, si tintin sur le serveur dispose de certaines autorisations sur un répertoire, celles-ci seront maintenues lorsque vous accéderez au répertoire en utilisant une connexion SFTP via cet utilisateur.

Il est donc possible de définir une politique de partage basée sur les permissions d’accès des répertoires et fichiers.

SFTP n’est pas un serveur FTP, mais un protocole de transfert de fichiers qui utilise SSH pour assurer la sécurité de la connexion. Bien que vous puissiez utiliser un client FTP ordinaire pour vous connecter à un serveur SFTP, nous vous recommandons d’utiliser un client SFTP dédié pour une meilleure sécurité et compatibilité.

Pour vous connecter à un serveur SFTP, vous aurez besoin des éléments suivants :

  • Le nom d’hôte ou l’adresse IP du serveur SFTP.
  • Le numéro du port sur lequel le serveur SFTP écoute (généralement 22).
  • Un nom d’utilisateur et un mot de passe pour un compte sur le serveur SFTP.

Une fois que vous avez toutes les informations ci-dessus, vous pouvez utiliser n’importe quel client SFTP pour vous connecter au serveur. Nous recommandons Filezilla car il est gratuit et facile à utiliser.

Comment créer des utilisateurs SFTP adéquats ?

Les partages seront accessibles à différentes personnes à qui il convient d’offrir un accès au serveur. Pour cela, il est logique de leur réserver un compte UNIX.

root@serveur:~# adduser Genevieve
root@serveur:~# adduser Marcel

Si vous n’avez pas de clés SSH, vous devrez fournir le mot de passe pour vous connecter via SFTP.

À cette occasion, un groupe peut être utile pour rassembler les utilisateurs autorisés sur les actions.

root@serveur:~# addgroup dupont
root@serveur:~# adduser genevieve dupont
root@serveur:~# adduser marcel dupont

Comment préparer des partages SFTP ?

Les répertoires partagés doivent appartenir à des utilisateurs/groupes particuliers afin d’influer sur le type d’autorisations offerts aux utilisateurs.

Supposons que l’on souhaite créer deux types de partage :

  • l’un accessible à tous en lecture, nommé “lecture” ;
  • l’autre accessible au groupe en écriture, comme “ecriture”.
# chown -R genevieve:dupont /srv/data/*
# chown -R g+w /srv/data/ecriture/

De cette façon, les fichiers du répertoire “ecriture” pourront être lus et écrits par chaque membre du groupe moulinsart. Si vous n’avez pas accordé ces droits au répertoire “lecture”, il ne pourra pas être modifié par les membres du groupes.

En résumé, la connexion SFTP respectera les droits Unix des fichiers d’où l’importance de ces ajustements qu’il vous faudra adapter à vos besoins.

SSHFS

Comment installer SSHFS sur les clients ?

Pour permettre le montage de systèmes de fichiers virtuels, l’installation du paquet SSHFS et l’inclusion d’un utilisateur dans le groupe fuse sont nécessaires.

# aptitude install -y sshfs
# addgroup [genevieve|marcel] fuse

Si l’on est déjà connecté avec cet utilisateur, il faudra se reconnecter pour que le nouveau groupe soit pris en compte. On peut afficher les groupes auxquels un utilisateur appartient en lui faisant exécuter la commande “groups”.

Puis, il faut créer un point de montage pour chaque partage. J’ai l’habitude de créer ceux-ci dans le répertoire /media. Le point de montage devra appartenir à l’utilisateur qui veut l’utiliser.

# mkdir -p /media/sshfs/{ecriture,lecture}
# chown [genevieve|marcel]: /media/sshfs/ecriture /media/sshfs/lecture

Tout est prêt, le répertoire distant peut désormais être monté en local grâce à la commande SSHFS, comme suit :

# sshfs genevieve@serveur:/srv/data/ecriture/ /media/sshfs/ecriture/

Notons à cette occasion qu’il est probable que les UID et GID seront différents entre les clients et le serveur pour un “même utilisateur”. C’est la raison pour laquelle des valeurs erronées (ou même des valeurs numériques) pourront apparaître à la place des noms du propriétaire et du groupe d’un fichier.

Il est cependant inutile d’y prêter attention car ce sont bien les propriétaires et groupes des fichiers sur le serveur qui auront de l’importance, et c’est via ces utilisateurs que les connexions SSH sont établies… En harmonisant les UID et GID des utilisateurs et groupes impliqués (en changeant manuellement leurs valeurs), aussi bien sur le serveur que sur les clients, il est possible d’y remédier mais cela n’a que peu d’intérêt.

Comment mettre en place un montage automatique des partages SSHFS ?

Pour que les partages SSHFS soient montés automatiquement sur les postes clients, il est possible d’utiliser le programme autofs qu’il faut alors installer sur chaque machine.

# aptitude install -y autofs

Avec autofs, c’est l’utilisateur root du poste client qui procédera au montage du partage : c’est pourquoi il faut lui autoriser l’accès au compte utilisateur sur le serveur. Cependant, il a besoin d’établir la connexion en utilisant une clé privée SSH. Ainsi, il faudra bien entendu copier sa clé publique dans les clés autorisées par l’utilisateur de destination sur le serveur. Il faut prendre garde à établir une première connexion SSH afin d’inclure la destination dans les hôtes connus (faute de quoi le montage SSHFS échouera sans laisser d’indice sur ce qui le gêne).

D’autres documentations spécialisées expliqueront cette démarche plus en détail.

Configurons désormais SSHFS sur chaque poste client en éditant le fichier /etc/auto.master :

/media/sshfs    /etc/auto.sshfs --timeout=30

Cette instruction prévoit l’exécution de la configuration auto.sshfs lorsqu’un répertoire est demandé dans /media/sshfs. Voici le fichier en question (à adapter selon le client pour contacter un utilisateur précis sur le serveur, évidemment) :

ecriture -fstype=fuse,port=22,rw,allow_other :sshfs\#genevieve@serveur\:/srv/data/ecriture/
lecture  -fstype=fuse,port=22,rw,allow_other :sshfs\#genevieve@serveur\:/srv/data/lecture/

Enfin, il ne reste qu’à redémarrer le service autofs pour que les partages soient montés automatiquement lors de chaque tentative d’accès aux répertoires de /media/sshfs.

# service autofs restart

SPF (Sender Policy Framework)

SPF est une norme qui permet de détecter la falsification des adresses électroniques. Pour ce faire, elle vérifie que l’adresse IP de l’expéditeur du courriel est autorisée pour envoyer des e-mails au nom du domaine dans le champ From :. SPF est un système d’authentification basé sur le DNS, et il est relativement facile à mettre en œuvre.

De nombreux spammeurs utilisent une adresse de retour inventée pour brouiller les pistes, qui n’est pas la leur. Si la livraison échoue, un rapport est déposé auprès d’une personne qui n’a jamais envoyé le message non distribuable. Ces messages non distribués incohérents sont considérés comme des backscatter.

Les e-mails sont finalement similaires aux courriers papier !

Un message électronique, comme le courrier papier, comprend les éléments suivants :

  • une enveloppe, sur laquelle figure l’adresse de l’expéditeur et celle du destinataire ;
  • un en-tête, sur lequel figurent des informations comme l’expéditeur, le destinataire, les destinataires en copie, le sujet et la date ;
  • un corps, qui constitue le contenu effectif du message.

Les informations de l’enveloppe sont destinées aux intermédiaires de livraison et ne sont pas (facilement) lisibles par le destinataire ; en outre, l’adresse de l’expéditeur n’est utilisée que pour soumettre un rapport en cas d’échec de la livraison, et elle peut être falsifiée. Les en-têtes sont destinés à l’usage du destinataire, et ne doivent pas toujours correspondre à la réalité : dans la plupart des cas, l’adresse « Reply-To : » est différente de l’adresse réelle de l’expéditeur. Le corps du message contient enfin le contenu qui a été rédigé par l’expéditeur.

Les incompatibilités entre SPF et les relais de FAI

N’oubliez pas que ces procédures ne sont pas directement compatibles avec l’utilisation d’un relais SMTP tiers, tel que votre fournisseur d’accès Internet. Le serveur destinataire considérerait le serveur relais comme un imposteur s’il recevait le courrier par l’une de ces méthodes.

Comprendre la syntaxe du SPF

L’enregistrement SPF d’un nom de domaine est publié dans le DNS, généralement avec le type SPF ou TXT. Par conséquent, cette ligne :

example.com. SPF "v=spf1 +a:mx.example.com -all"
  • Cela signifie que les enregistrements SPF pour example.com comprennent une politique conforme à la norme SPF version 1 ;
  • que le serveur nommé mx.example.com est autorisé à envoyer du courrier au nom de gens <@example.com> ;
  • que les autres serveurs ne sont pas autorisés à le faire.

Que signifie « version de la norme SPF » ?

La version de la norme SPF doit être « v=spf1 » dans le premier composant d’un enregistrement SPF, ce qui indique la version de la norme SPF employée : il s’agit actuellement de la version 1.

Comment fonctionne le mécanisme du protocole SPF ?

Chaque composant d’un enregistrement SPF est appelé mécanisme. Un mécanisme est un groupe de serveurs. Les suivants sont les plus utiles, sans ordre particulier :

  • ip4:IP le serveur dont l’adresse IPv4 est IP, ou les serveurs dont l’adresse IPv4 est située dans la plage IP ;
  • ip6:IP le serveur dont l’adresse IPv6 est IP, ou les serveurs dont l’adresse IPv6 est située dans la plage IP ;
  • a:NOM les serveurs dont l’adresse IP (v4 ou v6) figure dans le nom DNS NOM (enregistrement DNS A ou AAAA – attention, c’est un FQDN qui est attendu comme a:mx.example.com ;
  • all tous les serveurs d’Internet.

Ils sont préfixés de qualificateurs :

  • + réussite ;
  • ? neutre ;
  • ~ échec partiel ;
  • – échec.

Si aucun qualificateur n’est donné pour un mécanisme, cela décrit un cas de réussite (qualificateur +).

Un enregistrement DNS est constitué de mécanismes de combinaison préfixés par des qualificatifs qui indiquent comment un message doit être traité. Par exemple :

example.com SPF "v=spf1 +a:mx.example.com ?ip6:2001:db8:4212:4212::/64 -all"

Se lit comme suit :

  • les messages au nom de quelqu’un @example.com provenant de
  • le serveur de nom mx.example.com réussissent le test SPF ;
  • les serveurs dont l’adresse IPv6 est située dans la plage 2001:db8:4212:4212::/64 donnent un résultat neutre au test SPF ;
  • tous les serveurs (sauf les précédemment mentionnés, qui ont déjà passé le test SPF) échouent au test SPF.

Comment fonctionne la mise en oeuvre du protocole SPF ?

Pour publier une politique SPF sur votre nom de domaine example.com, vous devez donc construire un enregistrement DNS, qui en pratique ressemblera à :

“v=spf1 a:.example.com ~all”, 

où :

gene.example.com est le nom du serveur d’où vous envoyez votre courrier, que ce soit directement ou en l’utilisant comme relais.

Vous ajusterez le qualificateur ~all selon que vous souhaitez que les messages envoyés depuis ailleurs que votre serveur soient acceptés (qualificateur + ou ?), assortis d’un avertissement (qualificateur ~) ou rejetés (qualificateur -).

Avant de passer à l’action, pensez à contrôler la syntaxe de vos enregistrement via un outil en ligne de contrôle SPF (qui permettra ensuite de simuler des vérifications de SPF en interrogeant directement votre nom de domaine).

Publiez cette politique dans votre zone DNS, sous la forme d’un enregistrement SPF et d’un enregistrement TXT :

example.com. SPF "v=spf1 a:gene.example.com ~all"
example.com. TXT "v=spf1 a:gene.example.com ~all"

Tri de courrier électronique

Il existe plusieurs outils de tri des e-mails qui peuvent être utilisés pour trier automatiquement les messages en fonction de critères tels que l’expéditeur ou les en-têtes des listes de distribution :

  • Procmail : c’est un puissant outil de tri des courriels qui peut être utilisé pour trier automatiquement les messages en fonction de critères tels que les en-têtes d’expéditeur ou de liste de distribution. Procmail peut également être utilisé pour filtrer les messages en fonction de leur contenu, et pour transférer les messages vers d’autres adresses électroniques ou systèmes.
  • FDM : fdm est un programme de filtrage du courrier électronique qui permet à l’utilisateur de définir des règles pour trier le courrier en fonction de divers critères. fdm peut également être utilisé pour filtrer les messages en fonction de leur contenu, et pour transférer les messages vers d’autres adresses électroniques ou systèmes.
  • Maildir : il s’agit d’une structure de répertoire utilisée par certains programmes de messagerie pour stocker les messages dans des dossiers séparés. Les programmes compatibles avec Maildir peuvent utiliser Procmail pour trier les messages dans les dossiers appropriés.
  • IMAP : l’Internet Message Access Protocol est un protocole utilisé par les clients de messagerie pour accéder aux messages électroniques stockés sur un serveur. Les clients compatibles IMAP peuvent utiliser Procmail pour trier les messages dans différents dossiers sur le serveur.
  • POP : le Post Office Protocol est un protocole utilisé par les clients de messagerie pour accéder aux messages électroniques stockés sur un serveur . Les clients compatibles POP peuvent utiliser Procmail pour trier les messages dans différents dossiers sur le serveur.
  • Maildrop : Maildrop est un agent de distribution du courrier (MDA) qui prend en charge la distribution du courrier électronique aux boîtes aux lettres locales, ainsi que la transmission des messages à d’autres adresses électroniques ou systèmes. Maildrop peut être utilisé avec Procmail pour fournir une solution complète de tri et de filtrage du courrier électronique.
  • Sieve : Sieve est un langage de programmation utilisé pour filtrer les messages électroniques. Les scripts Sieve sont généralement utilisés pour trier les messages dans différents dossiers, transférer les messages à d’autres adresses, ou supprimer des messages en fonction de certains critères. Sieve peut également être utilisé pour filtrer les messages en fonction de leur contenu, et pour ajouter des en-têtes ou joindre des fichiers aux messages. Sieve est spécifié dans RFC 3028.

Ubuntu

La distribution Ubuntu, « Linux pour les humains », présente les caractéristiques suivantes :

  • est basée sur Debian ;
  • est maintenue par une entreprise, Canonical, en partenariat avec une communauté active ;
  • est adaptée pour les débutants ;
  • a une communauté d’utilisateurs accueillante et très active.

En conclusion, Ubuntu vous permet de :

  • bénéficier d’une maintenance de sécurité assez longue (5 ans pour les versions LTS, 18 mois pour les autres) ;
  • avoir un système presque aussi stable et homogène que Debian ;
  • avoir des logiciels assez récents ;
  • profiter de l’entraide d’une communauté forte.

Par contre, cela ne permet pas de :

  • avoir un système aussi fiable que Debian.

Comment installer Ubuntu sur votre serveur

Ubuntu étant basé sur Debian, l’installation peut se faire de différentes manières.

Depuis un CD ou une image .ISO bootable :

  • L’approche la plus traditionnelle pour installer Ubuntu est d’utiliser un CD. Pour ce faire, suivez les étapes suivantes :
  • téléchargez l’image d’installation de l’édition serveur sur la page de téléchargement ;
  • gravez-la sur un disque vierge ;
  • démarrez dessus ;
  • suivez les instructions de l’installateur.

Depuis un système GNU/Linux existant :

Si votre serveur a été fourni avec un système GNU/Linux préinstallé et un chargeur d’amorçage GRUB, vous pouvez l’utiliser pour lancer l’installateur Debian. Pour ce faire, suivez les étapes suivantes :

  • téléchargez un noyau (linux) et un initrd (initrd.gz) sur la page de l’installateur par réseau pour x86 ou pour amd64 selon votre processeur ;
  • placez-les dans un répertoire comme /boot/ubuntu-installer ;
  • redémarrez ;
  • à l’écran de GRUB, appuyez sur [c] pour pouvoir saisir des commandes à la main :
kernel /boot/ubuntu-installer/linux
initrd /boot/ubuntu-installer/initrd.gz

Après cela, suivez simplement les instructions de l’installateur.

Quelques conseils pour débuter avec Ubuntu

Ubuntu est une distribution Linux basée sur Debian. Si vous n’en êtes pas familier, Ubuntu peut être un bon point de départ. Voici quelques éléments à prendre en compte concernant Ubuntu :

Le logiciel aptitude est utilisé pour gérer les programmes installés :

# aptitude update && aptitude safe-upgrade      # met à jour le système
# aptitude install LOGICIEL                     # installe le logiciel choisi

Pour installer un service (le courrier avec Postfix, par exemple), pensez à consulter :

  • le contenu du répertoire /usr/share/doc/LOGICIEL/,
  • le wiki Ubuntu ;

N’hésitez pas à consulter les pages de manuel, pour chaque commande ou fichier de configuration :

man postfix # renvoie vers d'autres pages du manuel
man 5 postconf # détail de la configuration de Postfix
man interfaces # fichier de configuration du réseau

Unison

Unison est un outil de synchronisation de fichiers pour Unix et Windows. Il permet à l’utilisateur de spécifier un ensemble de fichiers ou de répertoires qui doivent être maintenus synchronisés entre deux ou plusieurs ordinateurs. Unison fonctionne dans les deux sens, de sorte que les modifications apportées d’un côté sont propagées de l’autre côté. Il est attentif à l’utilisation de la bande passante et fonctionne bien sur les liaisons lentes telles que les connexions PPP. Unison est disponible pour de nombreuses architectures et systèmes d’exploitation.

Unison est un projet de logiciel libre et open source, développé à l’Université de Pennsylvanie par Benjamin C. Pierce et al. Le projet est financé par la National Science Foundation (NSF) sous les subventions IIS-9988642 et ITR-0427560, par la DARPA sous la subvention F30602-..-C0027, par l’Army Research Laboratory dans le cadre de l’accord de coopération W911NF-07-2-0027, et par l’Air Force Office de la recherche scientifique sous le numéro de bourse FA9550-14-1-0045. Unison est publié sous la licence GPL v2.

Pour installer Unison, lancez cette ligne de commande sur votre serveur Debian :

apt-get install unison

Unisson peut etre utilisé en local ou en distant à travers ssh. Commençons par l’utilisation local.

Je vais créer deux dossiers dans mon dossier /home :

mkdir ~/rep1
mkdir ~/rep2

Vous pouvez maintenant créer des sous répertoires et des fichiers dans les répertoires rep1 et rep2.

touch ~/rep1/fichier011
touch ~/rep1/fichier012
touch ~/rep2/fichier021
mkdir ~/rep1/rep01
touch ~/rep1/rep01/fichier013

ce qui donne comme résultat ceci :

tree /home/cemoi/rep1/ 
/home/cemoi/rep1/ 
|-- fichier011 
|-- fichier012 
`-- rep01 
    `-- fichier013 

1 directory, 3 files 


tree /home/cemoi/rep2/ 
/home/cemoi/rep2/ 
`-- fichier021 

0 directories, 1 file 

Pour synchroniser le contenu de ces deux dossiers, faites ceci :

unison ~/rep1 ~/rep2 
Contacting server... 
Connected [//cemoi//home/cemoi/rep1 -> //cemoi//home/cemoi/rep2] 
Looking for changes 
Warning: No archive files were found for these roots, whose canonical names are: 
	/home/cemoi/rep1 
	/home/cemoi/rep2 
This can happen either 
because this is the first time you have synchronized these roots, 
or because you have upgraded Unison to a new version with a different 
archive format.  

Update detection may take a while on this run if the replicas are 
large. 

Unison will assume that the 'last synchronized state' of both replicas 
was completely empty.  This means that any files that are different 
will be reported as conflicts, and any files that exist only on one 
replica will be judged as new and propagated to the other replica. 
If the two replicas are identical, then no changes will be reported. 

If you see this message repeatedly, it may be because one of your machines 
is getting its address from DHCP, which is causing its host name to change 
between synchronizations.  See the documentation for the UNISONLOCALHOSTNAME 
environment variable for advice on how to correct this. 

Donations to the Unison project are gratefully accepted: 
http://www.cis.upenn.edu/~bcpierce/unison 

Press return to continue.[<spc>]  Reconciling changes 

rep1           rep2               
file     ---->            fichier011  [f]  
file     ---->            fichier012  [f]  
         <---- file       fichier021  [f]  
dir      ---->            rep01  [f]  

Proceed with propagating updates? [] y 
Propagating updates 

 
UNISON 2.27.57 started propagating changes at 14:22:42 on 12 Apr 2010 
[BGN] Copying fichier011 from /home/cemoi/rep1 to /home/cemoi/rep2 
[END] Copying fichier011 
[BGN] Copying fichier012 from /home/cemoi/rep1 to /home/cemoi/rep2 
[END] Copying fichier012 
[BGN] Copying fichier021 from /home/cemoi/rep2 to /home/cemoi/rep1 
[END] Copying fichier021 
[BGN] Copying rep01 from /home/cemoi/rep1 to /home/cemoi/rep2 
[END] Copying rep01 
UNISON 2.27.57 finished propagating changes at 14:22:42 on 12 Apr 2010 


Saving synchronizer state 
Synchronization complete  (4 items transferred, 0 skipped, 0 failures) 

Enfin, relancez la même commande pour voir le message obtenu :

unison ~/rep1 ~/rep2 
Contacting server... 
Connected [//cemoi//home/cemoi/rep1 -> //cemoi//home/cemoi/rep2] 
Looking for changes 
  scanning fichier021 
Reconciling changes 
Nothing to do: replicas have not changed since last sync.

Il n’y a rien à faire : aucun fichier n’a été modifié depuis la dernière sauvegarde.

Pour faire des opérations plus avancées il est plus rapide de se servir du fichier de configuration d’unison qui se trouve dans ~/.unison/default.prf Nous allons créer notre propre fichier de configuration:sync_home.prf

nano ~/.unison/sync_home.prf


# Unison preferences file 
#repertoire de destination de la replication 
root = /home/cemoi/replication_unison 
#repertoire racine de l'utilisateur 
root = /home/cemoi 
#chemin du repertoire source rep1 à repliquer dans /home/cemoi/replication_unison qui se trouve dans /home/cemoi 
path = rep1 
#chemin du repertoire source rep2 à repliquer dans /home/cemoi/replication_unison qui se trouve dans /home/cemoi 
path = rep2

Attention, n’oubliez pas de créer le répertoire replication_unison :

mkdir replication_unison

unison sync_home.prf 
Contacting server... 
Connected [//cemoi//home/cemoi -> //cemoi//home/cemoi/replication_unison] 
Looking for changes 
Warning: No archive files were found for these roots, whose canonical names are: 
	/home/cemoi/replication_unison 
	/home/cemoi 
This can happen either 
because this is the first time you have synchronized these roots, 
or because you have upgraded Unison to a new version with a different 
archive format.  

Update detection may take a while on this run if the replicas are 
large. 

Unison will assume that the 'last synchronized state' of both replicas 
was completely empty.  This means that any files that are different 
will be reported as conflicts, and any files that exist only on one 
replica will be judged as new and propagated to the other replica. 
If the two replicas are identical, then no changes will be reported. 

If you see this message repeatedly, it may be because one of your machines 
is getting its address from DHCP, which is causing its host name to change 
between synchronizations.  See the documentation for the UNISONLOCALHOSTNAME 
environment variable for advice on how to correct this. 

Donations to the Unison project are gratefully accepted: 
http://www.cis.upenn.edu/~bcpierce/unison 

Press return to continue.[<spc>]    scanning rep1/fichier021 
Reconciling changes 

replicati...   cemoi              
         <---- dir        rep1  [f]  
         <---- dir        rep2  [f]  

Proceed with propagating updates? [] y 
Propagating updates 


UNISON 2.27.57 started propagating changes at 15:02:50 on 12 Apr 2010 
[BGN] Copying rep1 from /home/cemoi to /home/cemoi/replication_unison 
[END] Copying rep1 
[BGN] Copying rep2 from /home/cemoi to /home/cemoi/replication_unison 
[END] Copying rep2 
UNISON 2.27.57 finished propagating changes at 15:02:50 on 12 Apr 2010 


Saving synchronizer state 
Synchronization complete  (2 items transferred, 0 skipped, 0 failures) 

Je relance la même commande pour voir la message obtenu:
unison sync_home.prf 
Contacting server... 
Connected [//cemoi//home/cemoi -> //cemoi//home/cemoi/replication_unison] 
Looking for changes 
  scanning rep1/fichier021 
Reconciling changes 
Nothing to do: replicas have not changed since last sync. 

Regardez ensuite l’état du répertoire où la réplication à eut lieux :

tree /home/cemoi/replication_unison/ 
/home/cemoi/replication_unison/ 
|-- rep1 
|   |-- fichier011 
|   |-- fichier012 
|   `-- rep01 
|       `-- fichier013 
`-- rep2 
    `-- fichier021 

3 directories, 4 files 

Tout est bien là, c’est parfait.

Nous allons étendre les fonctions de notre fichier sync_home.prf

Rajoutons une règle pour filtrer des fichiers et/ou des répertoires :

#fichiers à ignorer
ignore = Name {*.bin, toto.back, *.docx}
#repertoire à ignorer
ignore = Path {rep2}

Ajoutons la gestions de backup des fichiers supprimés avec la conservation des 3 dernières versions histoire de pouvoir récupérer un/des fichiers supprimés par erreur :

##gestion des backups 
#conservons une copie de tous les fichiers supprimes 
backup = Name * 
#conserve les 3 dernieres versions des fichiers supprimes 
maxbackups = 3 

Webmail (RoundCube)

Pour pouvoir accéder à votre courrier électronique depuis le Web, vous pouvez installer un webmail. Il en existe plusieurs, tels RoundCube, SquirrelMail, Horde ou encore le naissant et prometteur MailPile. Dans cette section, nous vous proposons d’installer RoundCube.

Quels sont le prérequis pour installer RoundCube sur son serveur Debian ?

RoundCube est en fait un client IMAP en PHP, qui fournit une interface Web. Vous devez donc déjà disposer :

  • d’un serveur web avec PHP ;
  • d’un serveur de boîtes aux lettres IMAP.

Comment installer RoundCube sur Debian ?

RoundCube fait partie de Debian :

# aptitude install roundcube

L’installeur posera alors quelques questions :

  • serveur IMAP : si vous installez RoundCube sur la même machine, répondez localhost ;
  • ensuite, choisissez de configurer le serveur Web Apache HTTPD ou lighttpd, selon celui que vous utilisez ;
  • finalement, choisissez d’utiliser une base de données SQLite.

Comment installer RoundCube avec Apache HTTPD ?

Ajoutez maintenant aux fichiers de configuration /etc/apache2/sites-available/{default,default-ssl} un alias vers le site de RoundCube :

Alias /webmail/ "/var/lib/roundcube/"

Redémarrez Apache HTTPD avec la commande /etc/init.d/apache2 restart : vous pouvez maintenant accéder à votre webmail à l’adresse http://server/webmail/.

Comment installer RoundCube avec Lighttpd ?

Roundcube peut détecter automatiquement la présence de Lighttpd, la configuration se trouve dans /etc/roundcube/lighttpd.conf. Par défaut le webmail est accessible par http://serveur/roundcube, mais cela peut se modifier dans les configurations de Lighttpd.

Comment installer RoundCube avec d’autres distributions ?

Pour utiliser votre webmail, vous devez vous identifier dessus. Pour éviter d’envoyer ainsi votre mot de passe en clair sur Internet, il est recommandé de mettre en place une sécurisation SSL.