Installer et configurer X11 sous FreeBSD

X11Cet article traite de l’installation et de la configuration du système X Window sous FreeBSD. Il rassemble mes notes et mes observations succinctes sur les différentes étapes de la configuration du système graphique. C’est donc un complément à la documentation officielle assez fournie sur la question.

J’ai effectué mes tests dans une machine virtuelle sous VirtualBox, et sur une paire de PC de bureau Dell Optiplex 330 qui me servent de « bac à sable ».

Notre objectif consiste ici à installer et configurer le gestionnaire de fenêtres minimaliste Window Maker. Nous n’aborderons pas l’installation d’un environnement de bureau comme KDE, GNOME ou Xfce, même si c’est tout à fait possible. Nous utiliserons FreeBSD principalement sur des serveurs sans interface graphique.

Window Maker

Installer X11

Pour un composant important comme le serveur graphique, il vaut mieux récupérer la version précompilée.

# pkg install xorg

Le gestionnaire de paquets récupère un peu moins de deux cents paquets, notamment le serveur graphique, les pilotes, une panoplie de polices d’affichage et le gestionnaire de fenêtres minimaliste TWM (Tabbed Window Manager). Le téléchargement pèse près de 80 Mo.

Système invité VirtualBox

Si l’on a installé FreeBSD dans une machine virtuelle sous VirtualBox, c’est le moment d’installer les Additions Invité (Guest Additions). La procédure est assez simple. Dans un premier temps, il faut installer le paquet correspondant.

# pkg install virtualbox-ose-additions

Ensuite, il faut activer le pilote et le service associé en éditant /etc/rc.conf.

vboxguest_enable="YES"
vboxservice_enable="YES"

Pour finir, il suffit de redémarrer, et le tour est joué. Les utilisateurs qui feront tourner la machine virtuelle devront faire partie du groupe wheel.

Premiers essais

Pour un premier test, se connecter en tant que simple utilisateur et lancer X11.

$ startx

Dans la machine virtuelle, c’est TWM qui se lance dans toute sa splendeur, mais avec une résolution inutilisable de 640×480. Quant au poste Dell Optiplex, le lancement de X11 provoque carrément un gel du système. Bon bon bon.

Configurer une carte Intel G31

Voyons de plus près cette carte vidéo qui pose problème sur le PC de bureau.

# pciconf -lv | less
...
vgapci0@pci0:0:2:0: class=0x030000 card=0x02201028 ...
    vendor     = 'Intel Corporation'
    device     = '82G33/G31 Express Integrated Graphics Controller'
    class      = display
    subclass   = VGA

Apparemment, cette carte est gérée par deux pilotes différents.

  • l’ancien pilote i915
  • le nouveau pilote i915kms en Kernel Mode Setting

Après recherche sur le Web, le nouveau pilote i915kms peut faire geler certaines machines. Pour en avoir le coeur net, je fais un petit test.

# kldload i915kms

Le système ne répond plus, et je tiens le coupable. Il ne me reste qu’à appuyer sur le bouton Reset pour redémarrer.

Pour résoudre le problème, je vais tenter de charger manuellement l’ancien pilote.

# kldload i915
info: [drm] Initialized i915 1.6.0 20080730

À présent, la commande startx fonctionne, et TWM s’affiche correctement. Je garde donc cette configuration et j’édite /etc/rc.conf en ajoutant le chargement du pilote i915.

kld_list="i915"

Remplacer TWM par Window Maker

TWM est sans conteste le gestionnaire de fenêtres le plus moche et le moins fonctionnel de la planète. On va donc le remplacer par quelque chose de plus utilisable, tout en restant minimaliste.

# pkg install windowmaker

Le téléchargement fait près de 57 Mo pour une petite cinquantaine de paquets.

Pour lancer Window Maker, l’utilisateur doit disposer d’un fichier ~/.xinitrc correspondant.

exec wmaker

Un coup de startx, et c’est Window Maker qui s’affiche.

Corriger la résolution de l’affichage

Dans la machine virtuelle, Window Maker s’affiche toujours avec une résolution de 640×480. A priori, X11 n’a plus besoin du fichier de configuration global /etc/X11/xorg.conf pour fonctionner correctement. La manière orthodoxe de procéder, c’est d’ajouter des bouts de fichiers contenant chacun une stance dans /usr/local/etc/X11/xorg.conf.d.

Dans ce répertoire, je vais donc éditer un fichier screen.conf en indiquant la résolution souhaitée. Notez que je suis libre dans le choix du nom de ce fichier, du moment qu’il se termine par *.conf.

Section "Screen"
        Identifier "Screen0"
        Device     "Card0"
        Monitor    "Monitor0"
        DefaultDepth 24
        SubSection "Display"
                Viewport   0 0
                Depth     24
                Modes "1280x1024"
        EndSubSection
EndSection

Configurer la disposition du clavier

L’environnement graphique utilise un clavier QWERTY américain par défaut. Sa configuration n’est pas lié à la console. Pour modifier cela, il me faut ajouter un fichier de configuration keyboard.conf dans /usr/local/etc/X11/xorg.conf.d. Pour mon clavier suisse romand, voilà ce que ça donne.

Section "InputClass"
  Identifier      "KeyboardDefaults"
  Driver          "keyboard"
  MatchIsKeyboard "on"
  Option          "XkbLayout" "ch"
  Option          "XkbVariant" "fr"
EndSection

Avec un clavier français, on aura plutôt quelque chose comme ceci.

  Option          "XkbLayout" "fr"

Configurer l’apparence de Xterm

Dans la configuration par défaut, l’apparence de Xterm n’est pas très lisible. Pour corriger cela, on peut éditer un fichier ~/.Xresources en indiquant le jeu de couleurs et de polices à utiliser.

XTerm*background: #000000
XTerm*foreground: LightGrey
XTerm*font: 9x15
XTerm*VT100.geometry: 115x40

Ensuite, il faut ajouter une ligne à ~/.xinitrc pour que ce fichier soit pris en compte.

xrdb -merge ~/.Xresources &
exec wmaker

Le gestionnaire d’affichage XDM

L’installation d’un gestionnaire d’affichage (ou gestionnaire de connexion) nous évitera d’avoir à taper startx à chaque fois que nous souhaitons démarrer une session graphique.

# pkg install xdm

L’activation de XDM au démarrage s’effectue dans le fichier /etc/ttys.

# Virtual terminals
ttyv1   "/usr/libexec/getty Pc"         xterm   on  secure
ttyv2   "/usr/libexec/getty Pc"         xterm   on  secure
ttyv3   "/usr/libexec/getty Pc"         xterm   on  secure
ttyv4   "/usr/libexec/getty Pc"         xterm   on  secure
ttyv5   "/usr/libexec/getty Pc"         xterm   on  secure
ttyv6   "/usr/libexec/getty Pc"         xterm   on  secure
ttyv7   "/usr/libexec/getty Pc"         xterm   on  secure
ttyv8   "/usr/local/bin/xdm -nodaemon"  xterm   on  secure

XDM se renseigne dans le fichier ~/.xsession pour savoir ce qu’il doit lancer. Ce fichier n’existe pas sur notre système, mais nous pouvons utiliser les informations contenues dans ~/.xinitrc en créant un lien symbolique.

$ ln -s .xinitrc .xsession

Au lancement de XDM, la console graphique xconsole s’affiche en bas à droite de l’écran. On peut désactiver cette console en éditant /usr/local/lib/X11/xdm/Xsetup_0 et en commentant la ligne qui lance xconsole.

#!/bin/sh
#xconsole -geometry 480x130-0-0 -daemon -notify -verbose ...

 

Publié dans Documentation Microlinux, FreeBSD | Marqué avec , | Laisser un commentaire

Configuration post-installation de FreeBSD

FreeBSD ConfigurationCet article se penche en détail sur les manipulations à effectuer après l’installation de FreeBSD pour que notre système soit réellement utilisable. Nous allons préparer le gestionnaire de paquets, installer une poignée d’outils de base comme Git et Vim et le shell Bash, activer un super-utilisateur qui puisse utiliser Bash sans se tirer dans le pied, peaufiner la configuration de Bash pour l’administrateur et les utilisateurs, localiser le système en français et passer en UTF-8.

Préparer la gestion des paquets

Initialiser le gestionnaire de paquets pkg, qui s’installe à la première utilisation.

# pkg update
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: y
Bootstrapping pkg...
Verifying signature with trusted certificate...
Installing pkg-1.9.4_1...
Extracting pkg-1.9.4_1: 100%
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100%    944 B   0.9kB/s    00:01    
Fetching packagesite.txz: 100%    6 MiB   1.5MB/s    00:04    
Processing entries: 100%
FreeBSD repository update completed. 25857 packages processed.

Installer Git

Récupérer le paquet du logiciel de gestion de versions Git.

# pkg install git

Configurer Git.

# git config --global --edit
[user]
name = Nicolas Kovacs
email = info@microlinux.fr

Récupérer mes scripts et mes fichiers de configuration.

# cd
# git clone https://github.com/kikinovak/freebsd

Installer l’éditeur Vim

L’éditeur Vi (/usr/bin/vi) fourni par le système de base est un peu trop minimaliste et obtus. On lui préférera Vim, bien plus confortable à l’utilisation.

# pkg install vim-lite

Notons que le paquet vim est fourni avec toutes les options activées et dépend de X11.

Configuration de Vim

Le fichier de configuration global de Vim est /usr/local/etc/vim/vimrc, mais la personnalisation s’effectuera individuellement pour chaque utilisateur par le biais de ~/.vimrc. Voici un exemple.

colorscheme elflord
set textwidth=79
set scrolloff=15
set autoindent

Activer le compte toor

FreeBSD fournit un compte super-utilisateur « alternatif » toor, censé être utilisé avec un shell non-standard de façon à ne pas devoir changer le shell de root. C’est un détail crucial, car l’installation de base ne fournit pas les shells comme Bash, qui sont installés par le biais du gestionnaire du paquets ou des logiciels portés. Ces logiciels s’installent tous dans l’arborescence /usr/local/bin, qui réside sur un système de fichiers différent. Or, si le shell de root se trouve dans /usr/local/bin et que ce système de fichiers n’est pas monté, root sera incapable de se connecter pour résoudre le problème.

# passwd toor

Notez que toor détient l’UID 0 tout comme root. On utilisera ce compte pour les tâches administratives au quotidien, et on gardera le compte root pour le dépannage en mode mono-utilisateur.

Installer le shell Bash

Le shell Bash n’est pas fourni par défaut.

# pkg install bash

L’installation du paquet affiche un avertissement.

==================================================================
bash requires fdescfs(5) mounted on /dev/fd
If you have not done it yet, please do the following:
  mount -t fdescfs fdescfs /dev/fd
To make it permanent, you need the following lines in /etc/fstab:
  fdescfs  /dev/fd   fdescfs   rw,late   0   0
==================================================================

Dans un premier temps, on va invoquer la commande manuellement.

# mount -t fdescfs fdescfs /dev/fd

Si tout se passe comme prévu, on peut ajouter la ligne correspondante à /etc/fstab.

# Device	Mountpoint	FStype	Options	Dump	Pass#
/dev/ada0p2	/		ufs	rw	1	1
/dev/ada0p3	none		swap	sw	0	0
fdescfs         /dev/fd         fdescfs rw,late 0       0

Configuration de Bash pour l’utilisateur toor/root

Activer le shell Bash pour l’utilisateur.

# chsh -s bash toor
chsh: user information updated

Créer un fichier /root/.bash_logout pour effacer l’écran après la déconnexion.

clear

Pour personnaliser la console, il faut d’abord éditer un fichier /root/.bash_profile comme ceci.

if [ -f ~/.bashrc ]; then
  source ~/.bashrc
fi

Le fichier /root/.bashrc contiendra la configuration à proprement parler. Voici un exemple.

# Alias
alias ll='ls -al'
alias ..='cd ..'
alias ...='cd ../..'
alias cp='cp -i'
alias rm='rm -i'
alias mv='mv -i'

# PS1
WHITE='\[\033[1;37m\]'
RED='\[\033[0;33m\]'
NC='\[\033[0m\]'
PS1="$RED[$WHITE\u$NC@$WHITE\h$NC:$WHITE\W$RED] #$NC "

# Shell colors
alias grep='grep --color'
CLICOLOR='yes'
LSCOLORS='ExGxFxdxCxDxDxhbadExEx'
export CLICOLOR LSCOLORS

# Vim
EDITOR=vim
VISUAL=$EDITOR
export EDITOR VISUAL

Configuration de Bash pour les utilisateurs communs

Les utilisateurs « communs mortels » auront les mêmes trois fichiers ~/.bash_logout, ~/.bash_profile et ~/.bashrc dans leurs répertoires utilisateur respectifs. Ce qui changera ici, c’est l’aspect de l’invite de commande définie par la variable PS1.

# PS1
GREEN='\[\033[0;32m\]'
WHITE='\[\033[1;37m\]'
NC='\[\033[0;m\]'
PS1="$GREEN[$WHITE\u$NC@$WHITE\h$NC:$WHITE\W$GREEN] \$ $NC"

Si l’utilisateur existe déjà, il faut activer l’utilisation du shell Bash comme nous l’avons fait un peu plus haut pour toor.

# chsh -s bash kikinovak
chsh: user information updated

Il est possible d’intégrer ces trois fichiers au profil par défaut des utilisateurs, qui se situe dans /usr/share/skel sur un système FreeBSD. Il faudra les préfixer de la chaîne de caractères dot.* comme ceci.

# ls -1 /usr/share/skel/*
/usr/share/skel/dot.bash_logout
/usr/share/skel/dot.bash_profile
/usr/share/skel/dot.bashrc
/usr/share/skel/dot.cshrc
/usr/share/skel/dot.login
...

Au final, on obtient un shell fonctionnel et plaisant à voir.

Bash Couleur

Basculer vers la console VT

Dans la configuration par défaut, c’est la console sc(4) ou syscons(4) qui est utilisée.

# sysctl -d kern.vty
kern.vty: Console vty driver
# sysctl kern.vty
kern.vty: sc

On préférera la console vt(4) qui présente plusieurs avantages, notamment la capacité à représenter correctement des jeux de caractères en UTF-8, ainsi que l’intégration avec les pilotes vidéo en mode KMS (Kernel Mode Setting).

Éditer /boot/loader.conf et ajouter la ligne suivante.

kern.vty=vt

La console VT sera activée au prochain redémarrage.

Passer en UTF-8

La commande locale -a affiche toutes les locales disponibles sur le système.

# locale -a | grep UTF-8 | grep fr
fr_BE.UTF-8
fr_CA.UTF-8
fr_CH.UTF-8
fr_FR.UTF-8

Ajouter le jeu de caractères et la locale par défaut au fichier /etc/login.conf. Ce fichier concerne les shells de connexion. Éventuellement, jeter un oeil à login.conf(5) pour plus de détails.

 
default:\
  ...
  :pseudoterminals=unlimited:\
  :priority=0:\
  :ignoretime@:\
  :umask=022:\
  :charset=UTF-8:\
  :lang=fr_FR.UTF-8:

Recréer la base de données associée.

# cap_mkdb /etc/login.conf

Éditer /etc/profile et définir le jeu de caractères et la locale par défaut pour tous les shells qui ne sont pas des shells de connexion, comme par exemple GDM ou d’autres gestionnaires de connexion.

LANG=fr_FR.UTF-8; export LANG
CHARSET=UTF-8; export CHARSET

Lorsqu’on redémarre, le système affiche un avertissement quant à la disposition du clavier.

WARNING:
New keymap: In /etc/rc.conf replace 'keymap=swissfrench.iso.acc.kbd'
by keymap=ch-fr.acc'.

Avec un clavier français, l’avertissement ressemblera à ceci.

WARNING:
New keymap: In /etc/rc.conf replace 'keymap=fr.iso.acc.kbd' by 
keymap=fr.acc'.

Les dispositions de clavier de la console SC se trouvent dans /usr/share/syscons/keymaps. Pour la console VT, il faudra choisir une des dispositions dans /usr/share/vt/keymaps et la définir dans /etc/rc.conf.

keymap="ch-fr.acc.kbd"
Publié dans Documentation Microlinux, FreeBSD | Marqué avec | Laisser un commentaire

Partitionnement manuel de FreeBSD

PartitionDans cet article, nous voyons d’un peu plus près l’organisation de l’espace disque sous FreeBSD. Nous regarderons en détail le résultat du partitionnement automatique, puis nous configurerons un système traditionnel de partitions pour des systèmes de fichiers séparés. Nous n’aborderons pas le système de fichiers ZFS, qui fera l’objet d’un article séparé.

Si l’on opte pour le partitionnement automatique, l’installateur propose le schéma de partitionnement suivant.

  • une partition freebsd-boot d’une taille de 512 kilooctets
  • une partition principale / freebsd-ufs en fonction de la taille du disque
  • une partition freebsd-swap d’une taille de 1 gigaoctet

Quelques remarques :

  • GPT (GUID Partition Table) est utilisé par défaut.
  • La partition freebsd-boot d’une taille de 512 kilooctets se situe au début du disque et contient uniquement le code de démarrage de FreeBSD.
  • Par défaut, le programme gptboot s’attend à ce que la première partition UFS trouvée soit la partition /. Pas d’ambiguïté ici.
  • La partition freebsd-swap se situe à la fin du disque. Sa taille de 1 gigaoctet est indépendante de la quantité de RAM disponible.

La documentation de FreeBSD fournit un exemple détaillé pour une organisation de partitions dans laquelle les répertoires /, /var, /tmp et /usr sont des systèmes de fichiers séparés ayant chacun leur propre partition. Si l’on choisit le partitionnement manuel, il faut d’abord créer une table de partition GPT sur le disque, puis créer les partitions l’une après l’autre.

  • La partition d’amorçage d’une taille de 512 kilooctets (type freebsd-boot, label boot) sera située au début du disque.
  • La partition / (type freebsd-ufs, label rootfs) sera définie juste après.
  • La partition swap (type freebsd-swap, label swap) sera dimensionnée en fonction de la quantité de RAM disponible.
  • La partition /var (type freebsd-ufs, label varfs) fera 2 gigaoctets.
  • La partition /tmp (type freebsd-ufs, label tmpfs) fera 1 gigaoctet.
  • La partition /usr (type freebsd-ufs, label usrfs) occupera tout le reste du disque.

Voici ce que cela donne une fois que le système est installé.

root@freebsd:~ # gdisk -l /dev/ada0
GPT fdisk (gdisk) version 0.8.10

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/ada0: 41943040 sectors, 20.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): E46BAB4E-12DC-11E7-B5E3-0800275666C1
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 41943006
Partitions will be aligned on 2-sector boundaries
Total free space is 1 sectors (512 bytes)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              34            1057   512.0 KiB   A501  boot
   2            1058         4195361   2.0 GiB     A503  rootfs
   3         4195362        12583969   4.0 GiB     A502  swap
   4        12583970        16778273   2.0 GiB     A503  varfs
   5        16778274        18875425   1024.0 MiB  A503  tmpfs
   6        18875426        41943005   11.0 GiB    A503  usrfs
root@freebsd:~ # df -h
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ada0p2    1.9G    533M    1.3G    29%    /
devfs          1.0K    1.0K      0B   100%    /dev
/dev/ada0p4    1.9G     65M    1.7G     4%    /var
/dev/ada0p5    992M    8.1M    904M     1%    /tmp
/dev/ada0p6     11G    1.2G    8.6G    12%    /usr

Notons au passage que gdisk ne fait pas partie d’une installation standard de FreeBSD, qui utilise gpart par défaut. Si je l’ai utilisé ici, c’est uniquement pour des raisons de clarté de la présentation.

Publié dans Documentation Microlinux, FreeBSD | Marqué avec , | Laisser un commentaire

FreeBSD installé par une poule

Dans ce premier article sur le système d’exploitation FreeBSD, j’effectue ce que les informaticiens anglophones appellent une chicken install. L’installation d’un système d’exploitation telle qu’une poule serait capable de la réaliser. Il suffit qu’elle accepte les choix par défaut de l’installateur en actionnant la touche Entrée avec son bec. OK, OK, OK, OK, OK, etc.

Chicken Install

Pour mes premiers tests, j’ai décidé de partir sur FreeBSD 10.3 amd64, que j’ai installé successivement dans une machine virtuelle VirtualBox (freebsd.microlinux.lan) et sur deux PC de bureau Dell Optiplex (bernadette.microlinux.lan et raymonde.microlinux.lan) qui me servent de cobayes.

Obtenir FreeBSD

La page de téléchargement du projet offre un certain nombre de fichiers au choix.

  • bootonly.iso contient uniquement l’installateur et nécessite une connexion à Internet.
  • disc1.iso contient le système FreeBSD et tient sur un CD-Rom.
  • dvd1.iso contient le système FreeBSD et une floppée d’applications supplémentaires.
  • memstick.img peut s’écrire directement sur une clé USB avec la commande dd.
  • uefi-*.iso et uefi-*.img sont dédiées aux machines UEFI.

Tester l’intégrité du fichier téléchargé

Avant d’écrire le fichier sur une clé USB ou de le graver sur CD-Rom, ce n’est pas une mauvaise idée de tester son intégrité.

Télécharger le fichier CHECKSUM et éditer ce fichier en supprimant toutes les lignes concernant les fichiers que l’on n’a pas rapatriés. Ensuite, on testera la somme de contrôle comme ceci.

$ sha256sum -c CHECKSUM.SHA256-FreeBSD-10.3-RELEASE-amd64 
FreeBSD-10.3-RELEASE-amd64-disc1.iso: Réussi

Démarrer l’installation

Une fois que j’ai défini le fichier ISO comme disque virtuel de démarrage, je lance la machine virtuelle.

Je confirme le démarrage de l’installation.

J’utilise une disposition de clavier suisse romande par défaut.

Une fois que la sélection est faite, il faut remonter tout en haut de la liste pour continuer.

Dans le choix du nom d’hôte, il faut saisir le FQDN (Fully Qualified Domain Name) de la machine.

Pour l’instant, j’accepte la sélection par défaut.

Pour une première installation, j’opte pour le partitionnement automatique.

L’intégralité du disque dur (virtuel) sera dédiée à FreeBSD.

Je confirme l’effacement du disque.

FreeBSD utilise une table de partitions GPT par défaut.

Le disque dur est subdivisé en trois partitions.

Je confirme le schéma de partitionnement proposé.

Dans un premier temps, l’installateur vérifie l’intégrité des archives.

FreeBSD est installé sur le disque dur.

Ensuite, on passe à la définition du mot de passe pour root.

L’interface réseau de la machine virtuelle s’appelle em0.

Oui, je souhaite la configurer.

Oui, je souhaite utiliser une configuration DHCP.

Je n’utilise pas l’IPv6 dans mon réseau.

Je confirme le récapitulatif du DNS local.

L’horloge de la machine est réglée en UTC.

Le premier écran de sélection du fuseau horaire me somme de choisir mon continent ou ma région.

Dans le deuxième écran de sélection du fuseau horaire, je choisis mon pays.

Ici, CET signifie Central European Time, ce qui correspond à mon fuseau horaire.

Je confirme l’activation des services par défaut.

Je souhaite ajouter au moins un utilisateur « commun mortel ».

Ici, je prends soin d’ajouter l’utilisateur au groupe wheel pour qu’il puisse devenir root, étant donné que dans la configuration par défaut, root ne peut pas se connecter en SSH.

Je confirme la création de l’utilisateur.

Il ne me reste plus qu’à quitter l’installateur.

Non, je ne souhaite pas me retrouver dans un shell.

Il ne me reste plus qu’à redémarrer.

Publié dans Documentation Microlinux, FreeBSD | Marqué avec | Laisser un commentaire

Découvrir FreeNAS : partage Windows simple

SambaDans ce troisième article sur FreeNAS, nous allons mettre en place un partage Windows simple. Partons d’un cas de figure que l’on rencontre fréquemment dans les petites entreprises ou associations, ou dans une utilisation domestique.

  • Trois utilisateurs, qui ont chacun un compte sur le NAS
  • Chaque utilisateur dispose d’un partage personnel
  • Un partage protégé est accessible à deux des trois utilisateurs
  • Un partage public est accessible à tout le monde

Plus concrètement, je vais partir des trois utilisateurs suivants.

  • Alexandre Habian (ahabian), membre des groupes utilisateurs et eyrolles
  • Karine Joly (kjoly), également membre des groupes utilisateurs et eyrolles
  • Kiki Novak (kikinovak), membre du groupe utilisateurs

Notez en passant que mon éditeur Eyrolles n’est pas exactement une petite entreprise. Mais vu que l’ambiance y est plutôt familiale, j’ai décidé spontanément de le prendre comme exemple.

En dehors des partages individuels de chacun, nous aurons deux autres partages.

  • Le partage Eyrolles sera accessible aux membres du groupe eyrolles
  • Le partage Public sera accessible aux membres du groupe utilisateurs

Configuration du stockage : volume et datasets

La première chose à faire, c’est de configurer le stockage, c’est-à-dire un endroit où ranger toutes ces données. Dans un premier temps, nous allons faire abstraction de toute la nomenclature farfelue de ZFS et aller droit au but en faisant les choses de la manière la plus simple qui soit. Nous aurons l’occasion plus tard de nous préoccuper des détails.

Dans la colonne latérale, allez dans Stockage > Volumes et ouvrez le Volume Manager. Indiquez le nom du volume, stockage par exemple. Un peu plus bas, cliquez sur Disques disponibles. Nous n’en avons qu’un seul, et il devra apparaître un peu plus bas dans la section Agencement du volume, en tant que ada1. Cliquez sur Ajouter un volume et ne vous inquiétez pas si l’opération dure quelques secondes.

FreeNAS Volume Manager

Si tout s’est bien passé, notre volume apparaît dans le menu latéral à gauche, sous forme d’une nouvelle entrée /mnt/stockage dans la section Volumes.

La prochaine étape consiste à découper notre espace de stockage en créant une série de jeux de données ou datasets pour chacun de nos utilisateurs ainsi que pour les partages.

Dans Stockage > Volumes > /mnt/stockage, je clique sur Create Dataset (l’entrée n’est pas encore traduite) et je crée le dataset ahabian qui sera le répertoire utilisateur d’Alexandre Habian. Je garde les réglages par défaut sans me préoccuper des détails, et je clique sur Ajouter un jeu de données.

FreeNAS Dataset

Je me retrouve avec un nouveau dataset /mnt/stockage/ahabian en-dessous du volume /mnt/stockage. De la même manière, je crée les autres datasets kjoly, kikinovak, eyrolles et public. Au final, lorsque je clique sur l’icône Stockage en haut de l’interface (ou Stockage > Volumes > Voir les volumes dans le menu latéral), je dois obtenir quelque chose qui ressemble à ceci.

FreeNAS Stockage

Créer les groupes et les utilisateurs

La prochaine étape consiste à créer les groupes et les utilisateurs. Un simple clic sur l’icône Comptes dans la barre d’outils supérieure (ou Compte > Groupes > Voir les Groupes dans le menu latéral) nous affiche la liste complète de tous les groupes définis sur le système. Nous allons en ajouter deux.

  • Le groupe utilisateurs aura le GID 10001.
  • Le groupe eyrolles aura le GID 10002.

Cliquez sur Ajouter Groupe, renseignez l’ID de groupe 10001 et le nom de groupe utilisateurs, laissez le reste tel quel et cliquez sur OK.

FreeNAS Groupes

Procédez de même pour le groupe eyrolles avec l’ID de groupe 10002.

Une fois que les groupes sont définis, passons à la création des utilisateurs. Cliquez sur Compte > Utilisateurs > Ajouter Utilisateur.

  • Gardez l’UID proposé par défaut, par exemple 1001.
  • Saisissez le nom d’utilisateur, par exemple ahabian.
  • Décochez Créer un nouveau groupe primaire pour l’utilisateur.
  • Définissez utilisateurs comme Groupe principal dans le menu déroulant.
  • Le répertoire personnel se situera dans le dataset correspondant à l’utilisateur.
  • Fournissez le nom complet de l’utilisateur.
  • Renseignez éventuellement son adresse mail.
  • Choisissez un mot de passe et confirmez-le.
  • Ajoutez l’utilisateur au groupe secondaire eyrolles s’il doit en faire partie.
  • Confirmez la création de l’utilisateur en cliquant sur OK.

FreeNAS Utilisateurs

Pour ajouter l’utilisateur à un groupe secondaire, sélectionnez le groupe dans la colonne de gauche et cliquez sur les chevrons >> pour faire basculer le groupe dans la colonne de droite.

FreeNAS Utilisateurs

Je procède de la même manière pour créer les utilisateurs kjoly et kikinovak. Ce dernier ne fera pas partie du groupe eyrolles.

Définir les permissions

La prochaine étape consiste à configurer les droits d’accès des partages, ce qui revient à définir qui aura accès à quoi.

J’affiche la vue d’ensemble des volumes dans la section Stockage, ce qui m’affiche le volume stockage et les cinq datasets ahabian, eyrolles, kikinovak, kjoly et public. Lorsqu’on sélectionne un dataset en cliquant dessus, une série de boutons contextuels apparaissent en bas de l’écran. Le bouton de gauche permet de modifier les permissions.

FreeNAS Permissions

Je commence par le dataset eyrolles. Rappelons-nous que l’accès à ce groupe doit être accordé à tous les membres du groupe eyrolles.

Le propriétaire par défaut du dataset eyrolles, c’est l’utilisateur root. Il n’appartient de fait à personne en particulier. Or, sur les systèmes Unix, il existe un utilisateur système particulier pour ce genre de contexte, c’est l’utilisateur nobody. Dans le menu déroulant Propriétaire (utilisateur), nous allons donc passer de root à nobody.

Quant au Propriétaire (groupe) du dataset, ce ne sera pas le groupe système wheel, mais le groupe eyrolles que nous avons créé plus haut.

Le champ Mode permet de définir finement les droits d’accès en lecture, écriture et exécution pour le propriétaire, les membres du groupe et tous les autres (c’est-à-dire tous ceux qui ne sont ni le propriétaire, ni membres du groupe).

  • Le propriétaire du partage a tous les droits.
  • Les membres du groupe ont tous les droits.
  • Tous les autres n’ont aucun droit.

FreeNAS Permissions

Le dataset public appartiendra également à l’utiliateur système nobody, mais il sera affecté au groupe utilisateurs. Ici, nous serons un peu plus permissifs pour les droits d’accès. Le propriétaire et les membres du groupe auront accès en lecture, en écriture et en exécution. Quant aux autres, on leur laissera un accès restreint en lecture seule. On ne va pas rentrer dans les détails des permissions Unix, mais remarquons simplement que les droits d’exécution sont nécessaires pour naviguer dans une arborescence de répertoires.

FreeNAS Permissions

Il ne reste plus qu’à définir les permissions des datasets des utilisateurs. J’ouvre l’interface de modification des permissions pour l’utilisateur ahabian. Le propriétaire du dataset, c’est l’utilisateur lui-même. Le groupe associé est utilisateurs. J’opte pour des permissions plus restrictives ici, en accordant les droits au seul propriétaire du dataset. Ce partage permettra donc à ahabian d’avoir accès à ses données depuis n’importe quelle machine du réseau local, mais pour partager des fichiers avec d’autres, il devra utiliser l’un des deux partages eyrolles ou public.

FreeNAS Permissions

Je procède de même pour les partages des deux autres utilisateurs, kjoly et kikinovak.

Créer les partages Windows

Maintenant que les datasets, les utilisateurs et les groupes associés sont créés et que nous avons défini les droits d’accès, il ne nous reste plus qu’à ajouter les partages Windows, ce qui est une affaire de quelques clics.

Dans la section Partage, repérez l’entrée Partages Windows (SMB) et cliquez sur Ajouter Partage Windows (SMB). Pour chacun des partages, je dois configurer deux choses.

  1. le chemin d’accès vers le dataset
  2. le nom du partage

FreeNAS Partage Windows

Lors de la définition du premier partage, FreeNAS me propose d’activer le service SMB associé.

FreeNAS Samba

Pour les utilisateurs, je peux nommer les partages personnels en utilisant leurs noms respectifs. Une fois que j’ai défini mes partages, je peux les afficher via l’entrée de menu Partage > Partages Windows (SMB) > Voir les Partages Windows (SMB).

FreeNAS Partages Windows

Accéder aux partages

Sur un poste client Windows, ouvrir l’explorateur de fichiers dans la partie Réseau. La fenêtre affiche alors toutes les machines du réseau susceptibles d’offrir des partages Windows.

FreeNAS Client Windows

Une fois qu’on a cliqué sur le serveur FREENAS, l’ensemble des partages s’affiche.

FreeNAS Partages Windows

Si le partage n’est pas publiquement accessible, Windows nous somme de nous identifier.

FreeNAS Authentification

Si l’on doit accéder régulièrement à un partage, on peut définir une connexion permanente. Dans ce cas, il suffit de cliquer droit sur un partage et de choisir l’option Connecter un lecteur réseau dans le menu contextuel.

FreeNAS Partage

Une petite remarque concernant une particularité de Windows. Si jamais l’utilisateur tente de se connecter à un partage auquel il n’a pas accès normalement, Windows semble garder en mémoire l’identifiant et le mot de passe de cette tentative de connexion, et ce même si l’on n’a pas coché la case Mémoriser ces informations. Dans ce cas, il faut ouvrir le Gestionnaire d’identification de Windows, ce que l’on peut faire directement via la commande suivante.

C:\ control keymgr.dll

Dans la fenêtre qui s’ouvre, il suffit de supprimer les informations stockées pour la connexion, ce qui peut même nécessiter un redémarrage.

Publié dans Documentation Microlinux, FreeNAS | Marqué avec | Laisser un commentaire

Découvrir FreeNAS : configuration initiale

ConfigurationDans ce deuxième article sur FreeNAS, nous allons aborder pas à pas la configuration initiale de notre système nouvellement installé. Nous allons franciser l’interface d’administration, configurer la disposition du clavier de la console, définir une adresse IP statique pour le serveur ainsi qu’une passerelle et un ou plusieurs serveurs DNS et peaufiner quelques menus réglages comme le fuseau horaire.

Franciser l’interface

Dans la configuration par défaut, l’interface d’administration de FreeNAS s’affiche en anglais. Ouvrez le menu déroulant System > General > Language, sélectionnez French et n’oubliez pas de cliquer sur Save pour prendre en compte les modifications.

Le changement de langue nécessite une reconnexion à l’interface. Cliquez sur Log Out dans le panneau latéral, puis optez pour Se connecter à nouveau.

La traduction n’est pas 100 % complète. Pour en savoir plus sur l’état de la traduction, on peut jeter un oeil sur cette page.

Configurer le clavier de la console

Le clavier de la console utilise une disposition QWERTY américaine. Nous pouvons changer ceci dans Système > Général > Disposition du clavier pour la console. Choisissez French ISO-8859-1 pour un clavier AZERTY français. En ce qui me concerne, j’opte pour un clavier Swiss-French ISO-8859-1. Là encore, n’oubliez pas de cliquer sur le bouton Enregistrer.

Le nouveau clavier sera utilisé au prochain redémarrage du serveur. Cliquez sur Redémarrer dans le panneau latéral. Au terme du redémarrage du serveur, le navigateur web affichera automatiquement l’invite de connexion à FreeNAS. Ce n’est donc pas la peine de rafraîchir la page manuellement.

Configurer le réseau

Pour l’instant notre serveur est en DHCP, et nous allons le reconfigurer avec une adresse IP statique. Nous pouvons utiliser l’interface graphique ou la console FreeNAS pour le faire. La console FreeNAS me semble un brin plus intuitive, et ce sera donc l’occasion de la regarder de plus près.

Console setup
-------------

1) Configure Network Interfaces
2) Configure Link Aggregation
3) Configure VLAN Interface
4) Configure Default Route
5) Configure Static Routes
6) Configure DNS
7) Reset Root Password
8) Reset to factory defaults
9) Shell
10) System Update (requires networking)
11) Create volume backup
12) Restore volume from a backup
13) Reboot
14) Shutdown

You may try the following URLs to access the web user interface:

http://192.168.2.251

Enter an option from 1-14:

L’option 9 permet de quitter la console et bascule vers l’invite de commande du système FreeBSD qui tourne sous le capot. J’en profite pour afficher quelques infos comme le nom et l’adresse IP de l’interface réseau, l’IP de la passerelle et du serveur DNS primaire.

[root@freenas] ~# ifconfig
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> ...
     options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
     ether 08:00:27:00:00:01
     inet 192.168.2.251 netmask 0xffffff00 broadcast 192.168.2.255 
...
[root@freenas] ~# netstat -rn
Routing tables
Internet:
Destination        Gateway            Flags      Netif Expire
default            192.168.2.1        UGS         em0
127.0.0.1          link#2             UH          lo0
...
[root@freenas] ~# cat /etc/resolv.conf
# Generated by resolvconf
search local microlinux.lan
nameserver 192.168.2.1

À présent, je rebascule dans la console FreeNAS.

[root@freenas] ~# /etc/netcli

Console setup
-------------

1) Configure Network Interfaces
2) Configure Link Aggregation
3) Configure VLAN Interface
4) Configure Default Route
5) Configure Static Routes
6) Configure DNS
...

Dans un premier temps, je configure l’adresse IP statique pour l’interface em0.

Enter an option from 1-14: 1
1) em0
Select an interface (q to quit): 1
Reset network configuration? (y/n) n
Configure interface for DHCP? (y/n) n
Configure IPv4? (y/n) y
Interface name: [Entrée]
Several input formats are supported
Example 1 CIDR Notation:
    192.168.1.1/24
Example 2 IP and Netmask seperate:
    IP: 192.168.1.1
    Netmask: 255.255.255.0, /24 or 24
IPv4 Address: 192.168.2.251
IPv4 Netmask: 255.255.255.0
Saving interface configuration: Ok
Configure IPv6? (y/n) n
Restarting network: ok

L’option 4 (Configure Default Route) permet de définir la passerelle.

Enter an option from 1-14: 4   
Configure IPv4 Default Route? (y/n) y
IPv4 Default Route: 192.168.2.1
Saving IPv4 gateway: Ok
Configure IPv6 Default Route? (y/n) n
Restarting routing: ok

Enfin, l’option 6 (Configure DNS) permet de saisir un ou plusieurs serveurs DNS. Pour terminer la saisie des serveurs DNS, il suffit de confirmer par [Entrée] sur une ligne vide.

Enter an option from 1-14: 6
DNS Domain [local]: microlinux.lan
Enter nameserver IPs, an empty value ends input
DNS Nameserver 1: 192.168.2.1
DNS Nameserver 2: [Entrée]
Saving DNS configuration: ok
Reloading network config: ok

À présent on peut rebasculer dans l’interface graphique et constater que les valeurs saisies se répercutent. Il faudra éventuellement recharger la page.

FreeNAS Configuration Réseau

Pour afficher le détail de la configuration de l’interface réseau, on peut ouvrir Réseau > Interfaces, mettre en surbrillance la ligne de l’interface (em0 dans notre cas) et cliquer sur le bouton Éditer.

Notez que nous aurions très bien effectuer la configuration réseau en mode graphique. Dans ce cas de figure, différents chemins mènent à Saint-Bauzille-de-Putois.

Maintenant que l’adresse IP fixe est configurée, nous pouvons renseigner le champ Système > Général > WebGUI IPv4. En passant, on en profitera pour indiquer le fuseau horaire correct Europe/Paris. Pour finir, cliquer sur Enregistrer en bas de la page.

Configuration FreeNAS

Lire la suite

 

Publié dans Documentation Microlinux, FreeNAS | Marqué avec | Laisser un commentaire

Découvrir FreeNAS : installation

InstallationVoici le premier d’une série d’articles sur FreeNAS, dont le but est de découvrir pas à pas les fonctionnalités de ce système. Pour notre première installation, nous ferons fi des recommandations de hardware assez spécifiques de ce système. Notre but n’est pas de monter un serveur de production, mais de nous faire la main.

Je vais effectuer tour à tour deux installations de FreeNAS dans mon réseau local.

  1. dans une machine virtuelle VirtualBox accessible par un pont (bridge)
  2. sur un PC de bureau Dell Optiplex 330

Obtenir FreeNAS

Sur la page du projet FreeNAS, le lien Download propose actuellement deux versions de FreeNAS.

  • FreeNAS 9.10 (stable)
  • FreeNAS Corral (current)

J’opte pour la version 9.10 stable et je télécharge l’ISO d’une taille de près de 500 Mo.

Vérifier l’intégrité du fichier téléchargé

Une fois que l’ISO est rapatrié, je me rends sur l’archive de téléchargement, je navigue dans le répertoire correspondant à la version téléchargée et je télécharge le fichier contenant la somme de contrôle SHA256. Voici comment il se présente.

$ cat FreeNAS-9.10.2-U2.iso.sha256 
SHA256 (/freenas-9.10-releng/_BE/objs/FreeNAS-9.10.2-U2.iso) = 
2847e680c308ab90e2b44f22f5450c2d98b26d0020815fe4c6115ca50c256e9c

Je vais éditer ce fichier et supprimer le chemin d’accès de l’ISO pour ne garder que le nom du fichier téléchargé.

$ cat FreeNAS-9.10.2-U2.iso.sha256 
SHA256 (FreeNAS-9.10.2-U2.iso) = 
2847e680c308ab90e2b44f22f5450c2d98b26d0020815fe4c6115ca50c256e9c

À présent, je peux vérifier l’intégrité de mon fichier ISO.

$ sha256sum -c FreeNAS-9.10.2-U2.iso.sha256 
FreeNAS-9.10.2-U2.iso: Réussi

Confectionner le support d’installation

L’installation dans VirtualBox pourra s’effectuer directement à partir du fichier ISO téléchargé. En revanche, j’aurai besoin d’un support pour l’installation sur le PC Dell Optiplex. Je grave un CD à partir de l’ISO.

Pour les machines dépourvues de lecteur optique, il est possible de confectionner une clé USB bootable, étant donné que l’ISO est hybride. On peut l’écrire directement sur la clé.

# dd if=FreeNAS-9.10.2-U2.iso of=/dev/sdX

Préparer la machine virtuelle

Notre première installation se fera dans VirtualBox. Je pars du principe que vous êtes suffisamment familiarisés avec VirtualBox, et je ne note ici que les spécificités par rapport à l’installation de FreeNAS.

Sous le capot de FreeNAS, c’est FreeBSD qui tourne en version 64-bit.

FreeNAS VirtualBox

Le système de fichiers ZFS est extrêmement gourmand en mémoire vive. Nous aurons l’occasion de revenir plus en détail sur ZFS, mais le minimum de quantité de RAM requise pour ce système de fichiers, c’est 8 Go. Notons tout de même que pour tester FreeNAS, on peut éventuellement se contenter de moins de RAM.

FreeNAS VirtualBox

Le système sera installé sur un disque dédié d’une taille de 8 Go.

FreeNAS VirtualBox

J’alloue quatre processeurs à la machine virtuelle et j’active PAE/NX.

FreeNAS VirtualBox

Étant donné que FreeNAS démarre en mode console et s’administre à distance via une interface web, on peut se contenter du minimum syndical en matière de mémoire vidéo.

FreeNAS VirtualBox

Ici, je crée un deuxième disque dur d’une taille de 20 Go, qui sera uniquement dédié au stockage des données. Notons que le disque système ne pourra pas être utilisé pour le stockage. Je définis également mon fichier ISO comme lecteur optique virtuel, ce qui me permet de démarrer directement dessus.

FreeNAS VirtualBox

L’accès réseau se fera par pont (bridge) pour permettre aux machines de mon réseau 192.168.2.0/24 d’accéder à l’installation.

FreeNAS VirtualBox

Installer FreeNAS

Maintenant que la machine virtuelle est configurée, on va pouvoir lancer l’installation à proprement parler.

Au démarrage de l’installateur, c’est GRUB qui nous salue. Il suffit de confirmer par [Entrée].

Installation FreeNAS

Pour installer FreeNAS, confirmer le choix Install/Upgrade par défaut.

Le système sera installé sur le disque de 8 Go ada0. Le disque de 20 Go ada1 sera dédié au stockage. La sélection du disque s’effectue avec la barre [Espace].

Installation FreeNAS

L’installateur nous rappelle que le disque dédié au système ne pourra pas être utilisé à des fins de stockage.

Installation FreeNAS

Une mise en garde solennelle s’impose ici. L’installateur nous somme de choisir un mot de passe, qui ne s’affiche que sous forme d’une série d’astérisques *******. Or, la console utilise un clavier QWERTY américain par défaut, ce que nous ne pouvons pas deviner. La solution consiste ici à passer cette étape en optant pour Cancel. Nous définirons le mot de passe root lors de la connexion initiale à l’interface d’administration.

Installation FreeNAS

Du moment que le matériel le supporte, autant démarrer en mode BIOS traditionnel.

Installation FreeNAS

L’installation dure à peine quelques minutes.

Installation FreeNAS

Dans une machine virtuelle, il vaut mieux éteindre le système plutôt que de le redémarrer. Cela permettra de supprimer le lecteur optique virtuel avant le redémarrage initial.

Installation FreeNAS

Le premier redémarrage peut durer jusqu’à plusieurs minutes. Le système doit notamment générer quelques paramètres pour les clés cryptographiques.

Installation FreeNAS

Au terme du démarrage, c’est la console FreeNAS qui s’affiche avec une série d’options, ainsi que l’adresse IP qui permet de se connecter à l’interface web.

Installation FreeNAS

Ouvrons à présent l’interface web de FreeNAS depuis un poste de travail du réseau. Puisque nous n’avons pas défini de mot de passe lors de l’installation, nous devrons le faire lors de la connexion initiale.

Installation FreeNAS

L’Assistant de Configuration (Initial Wizard) s’affiche. Cet assistant peut s’avérer pratique dans certains cas, mais nous allons configurer les choses manuellement, pas à pas, ce qui nous permettra de mieux comprendre ce que nous faisons. Quittez l’assistant en cliquant sur Exit.

Installation FreeNAS

Pour l’instant, l’interface d’administration de FreeNAS s’affiche en anglais. Nous allons bientôt activer la traduction française.

Installation FreeNAS

Installer FreeNAS sur un PC de bureau

À quelques détails près, la procédure d’installation sera identique pour un PC de bureau. Dans le cas de mon Dell Optiplex, le support d’installation est un CD-Rom, et le système sera installé sur une clé USB dédiée. Notons que si le PC avait été dépourvu de lecteur optique, j’aurais pu utiliser deux clés USB. Et non, il n’est pas possible d’installer FreeNAS sur le clé USB d’installation elle-même.

Étant donné qu’il ne s’agit que d’une installation pour tester FreeNAS, je fais fi de l’avertissement de l’installateur qui m’informe que la quantité de RAM est insuffisante. Les disques se présentent comme ceci.

  • ada0 – disque dur SATA de 160 Go
  • da0 – clé USB de 8 Go

Au terme de l’installation, je lance le BIOS et je configure le démarrage sur la clé USB.

Lire la suite

Publié dans Documentation Microlinux, FreeNAS | Marqué avec | Laisser un commentaire

Serveur mail sous Slackware (2) Dovecot

Logo DovecotAprès notre premier article sur Postfix, voici le deuxième article sur la mise en place d’un serveur mail sur une Dedibox tournant sous Slackware Linux, qui traite de Dovecot. Dovecot est un serveur IMAP et POP3 pour les systèmes d’exploitation Unix et dérivés. Il est conçu avec la sécurité comme première préoccupation. Nous le configurons ici pour le seul protocole IMAP, et nous partons d’emblée sur une gestion multi-domaines.

Prérequis

Pour nos tests, on utilisera une adresse kikinovak@slackbox.fr, qu’on aura
configurée dans Postfix.

Dans le pare-feu, il faudra ouvrir le port 993 (IMAPS = IMAP over SSL) en TCP.

Dovecot utilise un certificat SSL/TLS, qu’il faudra générer au préalable. Pour les détails, voir l’article sur Certbot. Si l’on souhaite gérer les mails de plusieurs domaines, il faudra générer un certificat SAN multi-domaines.

Installation

Dovecot ne fait pas partie d’une installation standard de Slackware. On va donc le compiler à partir des sources, en utilisant le script de SlackBuilds.org.

Créer quelques utilisateurs et groupes système nécessaires pour Dovecot.

# groupadd -g 202 dovecot
# useradd -d /dev/null -s /bin/false -u 202 -g 202 dovecot
# groupadd -g 248 dovenull
# useradd -d /dev/null -s /bin/false -u 248 -g 248 dovenull

Au final, on doit avoir quelque chose comme ceci.

# grep dove /etc/passwd
dovecot:x:202:202::/dev/null:/bin/false
dovenull:x:248:248::/dev/null:/bin/false
# grep dove /etc/group
dovecot:x:202:
dovenull:x:248:

Lancer la compilation de Dovecot et installer le paquet résultant.

Là encore, comme pour Postfix, si l’on choisit le paquet MLES, la création des utilisateurs et des groupes système est gérée automatiquement par le script de post-installation.

Configuration initiale de Dovecot

Éditer /etc/dovecot/dovecot.conf.

# /etc/dovecot/dovecot.conf
protocols = imap 
listen = *
ssl_cert = </etc/letsencrypt/live/ ... /fullchain.pem
ssl_key = </etc/letsencrypt/live/ ... /privkey.pem
mail_location = maildir:~/Maildir
auth_mechanisms = plain
passdb {
 driver = shadow
 args =
}
passdb {
 driver = passwd
 args =
}
userdb {
 driver = passwd
 args =
}

Activer et démarrer Dovecot.

# chmod +x /etc/rc.d/rc.dovecot
# /etc/rc.d/rc.dovecot start

Se connecter avec Mutt, en local ou à distance.

$ mutt -f imaps://kikinovak@slackbox.fr

Ajouter l’authentification SMTP à Postfix

Postfix supporte certes le protocole SASL (Simple Authentication and Security Layer), mais ne peut pas gérer l’authentification par lui-même. En revanche, Dovecot peut le faire pour lui.

Dans un premier temps, on va ajouter la stance suivante à dovecot.conf, qui concerne l’authentification par le biais du fichier socket /var/spool/postfix/private/auth.

...
service auth {
  unix_listener auth-userdb {
    mode = 0600
    user = postfix
    group = postfix
  }
  unix_listener /var/spool/postfix/private/auth {
    mode = 0666
  }
  user = $default_internal_user
}

Ensuite, il faut ajouter le mécanisme d’authentification login comme ceci.

auth_mechanisms = plain login
...

Au total, notre fichier /etc/dovecot/dovecot.conf ressemble donc à ceci.

protocols = imap 
listen = *
ssl_cert = </etc/letsencrypt/live/ ... /fullchain.pem
ssl_key = </etc/letsencrypt/live/ ... /privkey.pem
mail_location = maildir:~/Maildir
auth_mechanisms = plain login
passdb {
  driver = shadow
  args   =
}
passdb {
  driver = passwd
  args   =
}
userdb {
  driver = passwd
  args   =
}
service auth {
  unix_listener auth-userdb {
    mode = 0600
    user = postfix
    group = postfix
  }
  unix_listener /var/spool/postfix/private/auth {
    mode = 0666
  }
  user = $default_internal_user
}

Ensuite, il faut ajouter quelques lignes à la fin du fichier de configuration de Postfix.

smtpd_tls_cert_file    = /etc/letsencrypt/live/ ... /fullchain.pem
smtpd_tls_key_file     = /etc/letsencrypt/live/ ... /privkey.pem
smtpd_tls_security_level        = may
smtpd_sasl_auth_enable          = yes
broken_sasl_auth_clients        = yes
smtpd_sasl_tls_security_options = $smtp_sasl_security_options
smtpd_sasl_type                 = dovecot
smtpd_sasl_path                 = /var/spool/postfix/private/auth
smtpd_recipient_restrictions    = permit_mynetworks,
                                  permit_sasl_authenticated,
                                  reject_unauth_destination

Et pour finir, prendre en compte la nouvelle configuration :

# /etc/rc.d/rc.dovecot restart
# /etc/rc.d/rc.postfix restart

Supprimer Dovecot

Arrêter le service :

# /etc/rc.d/rc.dovecot stop

Supprimer le paquet :

# removepkg dovecot

Supprimer les fichiers de configuration :

# rm -rf /etc/dovecot/

Supprimer le script de démarrage :

# rm -f /etc/rc.d/rc.dovecot

Supprimer les utilisateurs système correspondants.

# userdel -r dovecot 
# userdel -r dovenull 

Les groupes système sont également supprimés par les deux précédentes commandes.

Publié dans Documentation Microlinux, Slackware | Marqué avec , , , | Laisser un commentaire

Certificats SSL/TLS avec Certbot sous Slackware

Cet article décrit la gestion des certificats SSL/TLS gratuits sur un serveur dédié tournant sous Slackware Linux. Un certificat électronique peut être vu comme une carte d’identité numérique. Il est utilisé principalement pour identifier et authentifier une personne physique ou morale, ou pour chiffrer des échanges. Il est signé par un tiers de confiance qui atteste du lien entre l’identité physique et l’entité numérique. Le standard le plus utilisé pour la création des certificats numériques est le X.509.

Les prix des certificats électroniques sont extrêmement variables, et certaines entreprises comme par exemple Verisign les font payer très cher. En revanche, il est tout à fait possible de les avoir gratuitement :

Let’s Encrypt est une autorité de certification lancée le 3 décembre 2015 en version bêta publique. Elle fournit des certificats SSL/TLS gratuits grâce au client Certbot installé sur le serveur qui automatise la plupart des tâches. On n’est donc plus obligé de payer une fortune et/ou de sauter à travers des cerceaux en feu pour créer et renouveler les certificats.

Les certificats générés avec Certbot sont reconnus par l’ensemble des navigateurs Web modernes. Cette technologie repose sur le protocole ACME (Automated Certificate Management Environment).

Installation

Le portail SlackBuilds.org fournit un script pour construire et installer le paquet letsencrypt. Il dépend d’une quantité importante de modules Python. Sur mes serveurs tournant sous Slackware64 14.0, 14.1 et 14.2, j’ai dû en installer pas moins de vingt-huit. Les dépendances sont toutes disponibles sur SlackBuilds.org.

Voici l’ordre dans lequel on peut construire les paquets :

  1. psutil
  2. pysetuptools [1]
  3. pytz
  4. python-future
  5. werkzeug
  6. mock
  7. configobj
  8. pyparsing
  9. zope.interface
  10. zope.event
  11. zope.component
  12. pycparser
  13. ipaddress
  14. enum34
  15. six
  16. idna
  17. cffi
  18. pyasn1
  19. cryptography
  20. pyOpenSSL
  21. ndg_httpsclient
  22. python2-pythondialog
  23. augeas
  24. python-augeas
  25. python-requests
  26. pyrfc3339
  27. python-parsedatetime
  28. python-configparse
  29. letsencrypt

[1] Depuis la version 14.2, Slackware inclut le paquet python-setuptools.

Plug-ins

Le client Certbot supporte une série de plug-ins pour Apache et Nginx. Pour l’instant, ces plug-ins fonctionnent uniquement sous Debian. On se contentera donc du plug-in standalone, qui fonctionne très bien sous Slackware.

Afficher les plug-ins installés :

# certbot --text plugins
Saving debug log to /var/log/letsencrypt/letsencrypt.log
* webroot
Description: Place files in webroot directory
Interfaces: IAuthenticator, IPlugin
Entry point: webroot = certbot.plugins.webroot:Authenticator

* standalone
Description: Spin up a temporary webserver
Interfaces: IAuthenticator, IPlugin
Entry point: standalone = certbot.plugins.standalone:Authenticator
  • L’option --text spécifie la sortie au format texte simple au lieu d’utiliser l’interface NCurses.

Tester Certbot et générer un certificat

Pour commencer, nous allons générer un certificat pour le domaine slackbox.fr. Étant donné que la requête utilise le port 443, il faut d’abord arrêter le serveur Web. En passant, il faudra éventuellement vérifier si le port 443 est bien ouvert dans le pare-feu.

# /etc/rc.d/rc.httpd stop

Dans un premier temps, nous allons tester la génération du certificat comme ceci :

# certbot --text certonly --preferred-challenges tls-sni-01 \
  --email info@microlinux.fr --renew-by-default --agree-tos \
  --standalone -d www.slackbox.fr -d slackbox.fr \
  --webroot-path /srv/httpd/vhosts/slackbox-secure/htdocs \
  --test-cert

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for www.slackbox.fr
tls-sni-01 challenge for slackbox.fr
Waiting for verification...
Cleaning up challenges
Generating key 2048 bits /etc/letsencrypt/keys/0005_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0005_csr-certbot.pem

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
 /etc/letsencrypt/live/www.slackbox.fr/fullchain.pem. Your cert will
 expire on 2017-05-04. To obtain a new or tweaked version of this
 certificate in the future, simply run certbot again. To
 non-interactively renew *all* of your certificates, run "certbot
 renew"

Pour en savoir un peu plus sur les options utilisées, on peut afficher l’aide de certbot comme ceci :

# certbot --help all | less

Si tout s’est passé comme prévu, on peut réitérer la commande ci-dessus en omettant l’option --test-cert pour générer le certificat pour de vrai.

Les fichiers générés se trouvent tous dans le répertoire /etc/letsencrypt/live/<domaine>. On va donc jeter un oeil :

# ls -1 /etc/letsencrypt/live/www.slackbox.fr/
cert.pem  
chain.pem  
fullchain.pem  
privkey.pem

À quoi correspondent ces fichiers ?

  • privkey.pem : c’est la clé privée pour le certificat. Ce fichier ne doit surtout pas être divulgué. Le serveur doit pouvoir y accéder pour que SSL/TLS fonctionne. C’est ce qu’Apache utilisera comme fichier SSLCertificateKeyFile.
  • cert.pem : le certificat du serveur. C’est ce qui correspond au SSLCertificateFile d’Apache.
  • chain.pem : les certificats requis par le navigateur hormis le certificat du serveur. Requis par Apache < 2.4.8 pour le SSLCertificateChainFile.
  • fullchain.pem : tous les certificats, y compris celui du serveur. Il s’agit là de la concaténation de chain.pem et de cert.pem. C’est requis par Apache >= 2.4.8 pour le SSLCertificateFile.

Utiliser et tester le certificat

Pour commencer, on peut mettre en place un hébergement sécurisé avec le serveur Web Apache. La procédure détaillée fait l’objet d’un article à part. Voici la stance correspondante dans la configuration d’Apache :

# /etc/httpd/extra/httpd-ssl.conf 

DocumentRoot "/srv/httpd/vhosts/slackbox-secure/htdocs"
...
SSLCertificateFile "/chemin/vers/cert.pem"
SSLCertificateKeyFile "/chemin/vers/privkey.pem"
SSLCertificateChainFile "/chemin/vers/fullchain.pem"
...

Renouveler un certificat

La durée de vie d’un certificat est de 90 jours, ce qui n’est pas beaucoup. Pour prolonger la validité d’un certificat, il suffit de le renouveler en réinvoquant exactement la même commande utilisée pour le générer initialement.

Certificats et permissions

Si l’on souhaite utiliser plusieurs applications sécurisées pour un même domaine (Web, courrier, messagerie XMPP), on se retrouve confronté à un problème de permissions. Concrètement, si le serveur Web ainsi que le serveur de messagerie Prosody doivent accéder en lecture au certificat et à la clé privée, on peut utiliser la solution qui suit.

On crée un groupe système certs, on ajoute les utilisateurs système respectifs à ce groupe et on règle les permissions des fichiers en fonction, c’est-à-dire root:certs. Concrètement :

# groupadd -g 240 certs
# chgrp -R certs /etc/letsencrypt
# chmod -R g=rx /etc/letsencrypt

Si l’on souhaite qu’une application accède au certificat et à la clé privée, il suffit qu’on ajoute l’utilisateur correspondant au groupe système certs. Exemple pour la messagerie XMPP Prosody :

# usermod -a -G certs prosody

Notez que ce n’est pas la peine d’ajouter l’utilisateur apache au groupe certs. Au démarrage, le serveur Apache s’exécute avec les droits root, puis lance une série de processus enfants avec des droits restreints :

# ps aux | grep httpd | grep -v grep
root   3168 0.0 0.2 ... /usr/sbin/httpd -k start
apache 3169 0.0 0.2 ... /usr/sbin/httpd -k start
apache 3170 0.0 0.3 ... /usr/sbin/httpd -k start
apache 3171 0.0 0.3 ... /usr/sbin/httpd -k start
apache 3254 0.0 0.3 ... /usr/sbin/httpd -k start

Automatiser la procédure

La procédure de génération et de renouvellement peut être automatisée à l’aide d’un petit script. Par exemple :

#!/bin/bash
#
# Create/renew SSL/TLS certificates for slackbox.fr

DOMAIN="slackbox.fr"
DIRNAM="slackbox"
CERTBOT="/usr/bin/certbot"
CHGRP="/usr/bin/chgrp"
CHMOD="/usr/bin/chmod"
CERTGRP="certs"
EMAIL="info@microlinux.fr"
OPTIONS="certonly \
         --preferred-challenges tls-sni-01 \
         --email $EMAIL \
         --renew-by-default \
         --agree-tos \
         --text \
         --standalone"

# Create $CERTGRP group 
if ! grep -q "^$CERTGRP:" /etc/group ; then
  groupadd -g 240 $CERTGRP
  echo ":: Added $CERTGRP group."
  sleep 3
fi

# Stop Apache
echo ":: Stopping Apache."
if ps ax | grep -v grep | grep httpd > /dev/null ; then
  /etc/rc.d/rc.httpd stop 1 > /dev/null 2>&1
  sleep 5
fi

$CERTBOT $OPTIONS -d www.$DOMAIN -d $DOMAIN \
  --webroot-path /srv/httpd/vhosts/$DIRNAM-secure/htdocs

$CERTBOT $OPTIONS -d mail.$DOMAIN \
  --webroot-path /srv/httpd/vhosts/$DIRNAM-webmail/htdocs

$CERTBOT $OPTIONS -d cloud.$DOMAIN \
  --webroot-path /srv/httpd/vhosts/$DIRNAM-owncloud/htdocs

# Fix permissions
echo ":: Setting permissions."
$CHGRP -R $CERTGRP /etc/letsencrypt
$CHMOD -R g=rx /etc/letsencrypt

# Start Apache
echo ":: Starting Apache."
/etc/rc.d/rc.httpd start

Si l’on range ce script dans /etc/cron.monthly/, les certificats sont renouvelés tous les 1er du mois à 4h20 du matin.

Certificat SAN multi-domaines

Dans certains cas de figure, on peut avoir besoin de regrouper les certificats pour plusieurs domaines dans un seul certificat SAN (Subject Alternative Names). Pour générer un certificat SAN multi-domaine, on pourra adapter le script ci-dessus.

Voici un exemple pour un certificat SAN pour les domaines slackbox.fr et unixbox.fr et les sous-domaines mail.slackbox.fr et mail.unixbox.fr.

HOST=$(/bin/hostname --fqdn)
CERTBOT="/usr/bin/certbot"
CHGRP="/usr/bin/chgrp"
...
$CERTBOT $OPTIONS \
  --webroot-path /srv/httpd/vhosts/default/htdocs \
  -d $HOST \
  --webroot-path /srv/httpd/vhosts/slackbox-secure/htdocs \
  -d www.slackbox.fr -d slackbox.fr \
  --webroot-path /srv/httpd/vhosts/slackbox-webmail/htdocs \
  -d mail.slackbox.fr \
  --webroot-path /srv/httpd/vhosts/unixbox-secure/htdocs \
  -d www.unixbox.fr -d unixbox.fr \
  --webroot-path /srv/httpd/vhosts/unixbox-webmail/htdocs \
  -d mail.unixbox.fr

Le certificat résultant sera stocké dans /etc/letsencrypt/live, dans le répertoire correspondant au FQDN du serveur, en l’occurrence sd-41893.dedibox.fr. Malheureusement, on a de fortes chances de tomber sur une erreur du style Too many certificates already issued for domain dedibox.fr, comme quoi d’autres ont eu la même idée avant nous. On devra donc remplacer le nom d’hôte du serveur par quelque chose d’autre.

HOST=bacasable.microlinux.eu
CERTBOT="/usr/bin/certbot"
CHGRP="/usr/bin/chgrp"

Révoquer un certificat

Si jamais, pour une raison ou pour une autre, on a besoin de révoquer un certificat, on peut le faire comme ceci.

# cd /etc/letsencrypt/live
# certbot --text revoke --cert-path chemin/vers/cert.pem

 

Publié dans Documentation Microlinux, Slackware | Marqué avec , , , , , | 6 commentaires

Serveur mail sous Slackware (1) Postfix

Voici le premier d’une série d’articles sur la mise en place d’un serveur mail sur une Dedibox tournant sous Slackware Linux. Postfix LogoPostfix est un serveur mail, et plus exactement un MTA (Mail Transfer Agent). Il gère l’envoi et la réception de mails par Internet en utilisant le protocole SMTP. Le monde de l’Open Source offre toute une panoplie de MTA, parmi lesquels on trouve Postfix, Exim, Qmail et Sendmail. La distribution Slackware comprend Sendmail comme MTA par défaut. Nous allons lui préférer Postfix, qui est beaucoup plus facile à configurer.

Prérequis

Dans le pare-feu, il faudra ouvrir le port 25 en TCP.

Vérifier si le serveur n’est pas blacklisté quelque part.

mxtoolbox

Il faut impérativement disposer d’un ou de plusieurs noms de domaines enregistrés et valides.

  • slackbox.fr
  • unixbox.fr

Sur une machine externe, vérifier la configuration DNS des domaines pour lesquels on souhaite gérer le courrier.

$ host -t MX slackbox.fr
slackbox.fr mail is handled by 10 mail.slackbox.fr.
$ host mail.slackbox.fr
mail.slackbox.fr has address 195.154.65.130
$ host slackbox.fr
slackbox.fr has address 195.154.65.130
slackbox.fr mail is handled by 10 mail.slackbox.fr.
$ host 195.154.65.130
130.65.154.195.in-addr.arpa domain name pointer sd-41893.dedibox.fr.

Installation

Postfix ne fait pas partie d’une installation standard de Slackware. On va donc le compiler à partir des sources, en utilisant le script de SlackBuilds.org.

Au préalable, créer quelques utilisateurs et groupes système pour Postfix.

# groupadd -g 200 postfix
# useradd -u 200 -d /dev/null -s /bin/false -g postfix postfix
# groupadd -g 201 postdrop

Au final, on doit avoir quelque chose comme ceci.

# grep post /etc/passwd
postfix:x:200:200::/dev/null:/bin/false
# grep post /etc/group
postfix:x:200:
postdrop:x:201:

Lancer la compilation de Postfix et installer le paquet résultant.

Si l’on choisit le paquet MLES, la création des utilisateurs et des groupes système est gérée automatiquement par le script de post-installation.

Configuration initiale

Les fichiers de configuration utilisés par Postfix se situent dans /etc/postfix.

  • Le fichier master.cf gère la configuration du démon master de Postfix. Dans la plupart des configurations de base, on n’aura pas à intervenir sur ce fichier.
  • Le fichier main.cf contient les paramètres de contrôle des démons de Postfix. C’est celui que l’on modifiera le plus souvent.

Le fichier main.cf fourni par défaut fait presque 700 lignes, la plupart étant des commentaires. On peut éventuellement commencer par aérer ce fichier pour ne garder que les directives.

# cd /etc/postfix
# mv main.cf main.cf.orig
# grep -h -v '^[[:space:]]*\#' main.cf.orig | \
    grep -v '^[[:space:]]*$' > main.cf

On obtient quelque chose comme ceci.

compatibility_level = 2
queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
mail_owner = postfix
unknown_local_recipient_reject_code = 550
debug_peer_level = 2
debugger_command =
  PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
  ddd $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/sbin/sendmail
newaliases_path = /usr/bin/newaliases
mailq_path = /usr/bin/mailq
setgid_group = postdrop
html_directory = /usr/doc/postfix-3.1.4/html
manpage_directory = /usr/man
sample_directory = /etc/postfix
readme_directory = /usr/doc/postfix-3.1.4/README_FILES
inet_protocols = ipv4
meta_directory = /etc/postfix
shlib_directory = /usr/lib/postfix

Si un paramètre n’est pas présent dans main.cf, Postfix utilisera sa valeur par défaut. Pour la plupart, ces valeurs sont définies « en dur » dans le code source de Postfix, tandis que certaines sont initialisées à la compilation et quelques-unes au moment du lancement du programme.

Le programme postconf est très utile pour examiner les valeurs courantes et par défaut du fichier main.cf. Pour afficher la valeurs de certains paramètres de configuration, il suffit de les fournir en argument.

# postconf inet_protocols
inet_protocols = ipv4

L’option -d affichera la valeur par défaut des paramètres demandés.

# postconf -d inet_protocols
inet_protocols = all

Nous allons supprimer la plupart des paramètres redondants ou autrement inutiles, pour commencer avec quelques directives de base.

# /etc/postfix/main.cf

# Désactiver la rétrocompatibilité 
compatibility_level = 2

# Désactiver l'IPv6
inet_protocols = ipv4

# Identification 
smtpd_banner = $myhostname ESMTP $mail_name (Slackware Linux)

# Nom d'hôte pleinement qualifié du serveur
myhostname = sd-41893.dedibox.fr

# Domaine du serveur
mydomain = dedibox.fr

# Domaine pour qualifier les adresses sans partie domaine
myorigin = $myhostname

# Domaines locaux
mydestination = sd-41893.dedibox.fr, 
                localhost.localdomain, 
                localhost

# Envoi de mails sans authentification
mynetworks = 127.0.0.0/8

# Relais
relayhost =

# Format de stockage
home_mailbox = Maildir/

# Tables de correspondance
alias_maps = hash:/etc/postfix/aliases
alias_database = hash:/etc/postfix/aliases
  • Dans la configuration par défaut, Postfix démarre en mode rétrocompatible et affiche une alerte au démarrage (Postfix is running with backwards-compatible default settings). La directive compatibility_level=2 désactive la rétrocompatibilité.
  • Si l’IPv6 est désactivé au niveau du système, il faudra également le faire ici grâce à la directive inet_protocols.
  • smtpd_banner définit la chaîne de caractères avec laquelle Postfix s’identifie auprès d’un autre MTA.
  • myhostname est censé contenir le nom d’hôte pleinement qualifié du serveur, c’est-à-dire le résultat de la commande hostname --fqdn.
  • myorigin définit le domaine auquel sont associés des mails envoyés localement. Par défaut, myorigin a la même valeur que myhostname.
  • mydestination fournit la liste des domaines pour lesquels les messages reçus doivent être stockés dans une boîte mail locale. Attention : même si Postfix gère plusieurs domaines, mydestination ne doit spécifier que le domaine principal. Les domaines virtuels seront gérés par la directive virtual_alias_domains, que nous verrons plus loin.
  • mynetworks définit les adresses depuis lesquelles Postfix accepte les mails sans authentification via SMTP. Les plages d’adresses fournies ici désignent donc toutes les machines auxquelles Postfix fait confiance, si l’on peut dire. Sur un serveur dédié public, il est impératif de définir uniquement l’hôte local pour mynetworks, sous peine de se retrouver avec une « pompe à merde », le terme communément utilisé pour les serveurs mails mal configurés qui sont utilisés par des tiers malintentionnés pour l’envoi massif de spams sans authentification. Attention : les spammeurs du monde entier adorent ce genre de machines.
  • relayhost définit le MTA auquel on est censé transférer les mails qui ne doivent pas être acheminés localement. Dans notre configuration, cette directive doit rester vide. On l’utilisera sur un serveur de réseau local pour transférer les mails à un MTA public sur Internet.
  • Le format de stockage par défaut de Postfix, c’est mbox. On préférera le format Maildir, bien plus adapté pour une configuration IMAP.
  • alias_maps définit l’emplacement de la table de correspondance, et alias_database la base de données correspondante. Certaines informations ne peuvent pas être facilement représentées dans main.cf. Les tables de correspondance permettent de les stocker dans des fichiers externes. Postfix n’utilise pas directement les fichiers texte, ce serait trop lent. Au lieu de cela, les tables de correspondance de type « hash » (ou « tables de hachage) servent pour construire des fichiers indexés, grâce à la bibliothèque Berkeley DB. Le programme postmap est utilisé pour construire les fichiers indexés. Pour mettre à jour les alias, on utilisera la commande newaliases.

Éditer la table de correspondance.

# /etc/postfix/aliases
postmaster: root
root: kikinovak

Construire le fichier indexé.

# newaliases 

Activer et démarrer Postfix.

# chmod +x /etc/rc.rc.postfix
# /etc/rc.d/rc.postfix start

Basculer vers un compte utilisateur normal et envoyer un mail vers un compte externe, que l’on terminera par un point « . » sur une ligne à part.

# su - kikinovak
$ mail info@microlinux.fr
Subject: Test Postfix
Ceci est un test.
.
EOT

Éventuellement, jeter un oeil dans le journal de Postfix pour voir si le mail est bien parti.

# tail /var/log/maillog

Se connecter au compte externe et vérifier si le message a bien été envoyé, puis répondre à ce message. Si tout se passe bien, le répertoire utilisateur contient un nouveau répertoire ~/Maildir, qui ressemble à ceci.

$ tree Maildir/
Maildir/
|-- cur
|-- new
|   `-- 1360401556.V803I70000bM517366.sd-41893
`-- tmp

C’est un simple fichier texte, que l’on peut afficher avec less.

$ less Maildir/new/1360401556.V803I70000bM517366.sd-41893 
Return-Path: <info@microlinux.fr>
X-Original-To: kikinovak@sd-41893.dedibox.fr
Delivered-To: kikinovak@sd-41893.dedibox.fr
Received: from smtp.nfrance.com (smtp-6.nfrance.com [80.247.225.6])
...

Gérer les mails en ligne de commande avec Mutt

Mutt est un MUA (Mail User Agent) en ligne de commande. On peut l’utiliser sur des machines dépourvues d’interface graphique.

Avant de lancer Mutt, éditer le fichier de configuration ~/.muttrc.

set mbox_type=Maildir
set folder="~/Maildir"
set spoolfile="~/Maildir"
set mbox="+Mailbox"

my_hdr From: kikinovak@sd-41893.dedibox.fr (Niki Kovacs)
my_hdr Reply-To: kikinovak@sd-41893.dedibox.fr (Niki Kovacs)

Lancer Mutt.

$ mutt

La fenêtre principale de Mutt affiche la boite de réception. Les nouveaux mails sont marqués par un N. Une barre d’état en haut de l’écran affiche les principaux raccourcis. En règle générale, Mutt fonctionne avec les mêmes raccourcis que Vim.

Pour lire un message, il suffit de le sélectionner et d’appuyer sur [Entrée].

Mutt

Créer les comptes Linux pour la messagerie

Bien sûr, c’est plus élégant de créer des comptes virtuels gérés par une base de données et tout le bling bling. Le Web regorge d’ailleurs de tutos de ce genre, rivalisant de complexité. Pour commencer, nous allons rester fidèles au principe KISS et passer par des comptes Linux traditionnels.

Dans l’exemple qui suit, nous gérons le courrier des deux domaines slackbox.fr et unixbox.fr, avec les adresses mail suivantes.

  • fantasio@slackbox.fr
  • gaston.lagaffe@slackbox.fr
  • jeanne.dupont@slackbox.fr
  • gaston.lagaffe@unixbox.fr
  • bertrand.labevue@unixbox.fr

Dans un premier temps, nous allons créer des comptes Linux traditionnels, un par compte mail, en respectant – plus ou moins – les conventions de nommage classiques. Notons que les utilisateurs n’ont pas de shell de connexion, c’est-à-dire qu’ils ne pourront pas se connecter directement au serveur.

# useradd -m -g users -s /bin/false -c "Fantasio" fantasio
# useradd -m -g users -s /bin/false -c "Gaston Lagaffe" glagaffe
# useradd -m -g users -s /bin/false -c "Gaston Lagaffe" glagaffe2
# useradd -m -g users -s /bin/false -c "Jeanne Dupont" jdupont
# useradd -m -g users -s /bin/false -c "Bertrand Labévue" blabevue

Pour ne pas avoir à inventer des mots de passe raisonnablement compliqués pour chaque utilisateur, on peut utiliser l’outil pwgen, disponible sur SlackBuilds.org. Voici un exemple pour créer un mot de passe aléatoire long de huit caractères, composé de chiffres et de lettres majuscules et minuscules.

# pwgen -n -N 1

On va créer notre propre « base de données » sous forme de simple fichier texte mails.txt.

Nom              Mail                         Login     Pass
================================================================
Fantasio         fantasio@slackbox.fr         fantasio  LjaLScHa
Gaston Lagaffe   gaston.lagaffe@slackbox.fr   glagaffe  4qe0PsXY
                 gaston.lagaffe@unixbox.fr    glagaffe2 ug8u8Uvf
Jeanne Dupont    jeanne.dupont@slackbox.fr    jdupont   juRqqXsi
Bertrand Labévue bertrand.labevue@unixbox.fr  blabevue  01WedFcV
...

Étant donné qu’il contient des informations sensibles, on va le stocker dans un
endroit approprié, à l’abri des regards curieux.

# ls -l /root/mails.txt
-rw------- 1 root root 452 19 mars  06:53 /root/mails.txt

Les alias

Un alias est un nom supplémentaire pour recevoir du courrier électronique. En réalité, les mails sont acheminés vers un compte qui existe déjà. Les alias sont définis dans le fichier /etc/postfix/aliases.

...
# Utilisateurs
gaston.lagaffe: glagaffe, glagaffe2 
jeanne.dupont: jdupont
bertrand.labevue: blabevue
...

À chaque modification de ce fichier, il faut reconstruire /etc/postfix/aliases.db, la base
de données des alias.

# newaliases

Notons que pour des raisons de sécurité, Postfix n’achemine pas de mails vers root. Dans ce cas, il suffit de définir un alias vers un utilisateur judicieusement choisi qui les recevra à la place de root. Au total, on pourra avoir quelque chose comme ceci.

# /etc/postfix/aliases
postmaster: root
root: kikinovak
gaston.lagaffe: glagaffe, glagaffe2
jeanne.dupont: jdupont
bertrand.labevue: blabevue

Définir les destinataires autorisés

Dans la configuration par défaut, tous les comptes Linux peuvent recevoir du courrier, y compris les comptes système comme root, named ou nobody si l’on utilise le fichier /etc/postfix/aliases fourni par défaut.

Pour tester ce comportement, on peut créer un utilisateur bidon avec adduser et lui envoyer un mail à l’adresse bidon@sd-41893.dedibox.fr. On constate alors que ça passe comme une lettre à la poste.

# tree /home/bidon/Maildir/
/home/bidon/Maildir/
├── cur
├── new
│   └── 1489396170.V803I1c00037M362342.sd-41893
└── tmp

On va donc instaurer quelques restrictions pour éviter de spammer tout ce petit monde. Pour ce faire, on va créer un fichier /etc/postfix/local-recips avec la liste de tous les destinataires autorisés, en suivant la syntaxe suivante.

# /etc/postfix/local-recips
fantasio   x
glagaffe   x
glagaffe2  x
jdupont    x
blabevue   x

À partir de ce fichier, on va générer une base de données dans un format lisible pour Postfix.

# cd /etc/postfix
# postmap local-recips

Nous pouvons vérifier si le fichier a été généré correctement.

# postmap -s hash:local-recips
blabevue  x
jdupont   x
fantasio  x
glagaffe  x
glagaffe2 x

À chaque modification de local-recips, il faudra réinvoquer postmap local-recips pour reconstruire le fichier de base de données local-recips.db.

Pour prendre en compte les nouvelles restrictions, éditer /etc/postfix/main.cf et ajouter le paramètre suivant.

# Tables de correspondance
alias_maps = hash:/etc/postfix/aliases
alias_database = hash:/etc/postfix/aliases
local_recipient_maps = hash:/etc/postfix/local-recips $alias_maps

Prendre en compte les modifications.

# /etc/rc.d/rc.postfix reload

À partir de là, seuls les utilisateurs explicitement définis dans local-recips pourront recevoir du courrier.

Comptes Linux et adresses de messagerie

La prochaine étape consiste à faire correspondre les comptes Linux et les adresses de messagerie. Pour ce faire, on va créer un fichier /etc/postfix/canonical.

# /etc/postfix/canonical 
blabevue    bertrand.labevue@unixbox.fr
fantasio    fantasio@slackbox.fr
glagaffe    gaston.lagaffe@slackbox.fr
glagaffe2   gaston.lagaffe@unixbox.fr
jdupont     jeanne.dupont@slackbox.fr

Convertir le tableau en un format lisible pour Postfix.

# cd /etc/postfix
# postmap canonical

Définir le paramètre correspondant dans /etc/postfix/main.cf.

# Tables de correspondance
alias_maps = hash:/etc/postfix/aliases
alias_database = hash:/etc/postfix/aliases
local_recipient_maps = hash:/etc/postfix/local-recips $alias_maps
canonical_maps = hash:/etc/postfix/canonical

Domaines virtuels avec des utilisateurs distincts

Les domaines virtuels (Hosted Domains) sont tous les domaines qui ne correspondent pas au nom d’hôte du serveur, c’est-à-dire au résultat de la commande hostname -d.

Créer un fichier /etc/postfix/virtual avec un tableau qui fait correspondre chaque adresse mail d’un domaine virtuel à un compte Linux.

# /etc/postfix/virtual
bertrand.labevue@unixbox.fr        blabevue
fantasio@slackbox.fr               fantasio
gaston.lagaffe@slackbox.fr         glagaffe
gaston.lagaffe@unixbox.fr          glagaffe2
jeanne.dupont@slackbox.fr          jdupont

Là aussi, rendre ce fichier lisible pour Postfix.

# postmap virtual

Adapter /etc/postfix/main.cf pour prendre en compte les domaines virtuels.

# Domaines locaux
mydestination = sd-41893.dedibox.fr, 
                localhost.localdomain, 
                localhost

# Domaines virtuels
virtual_alias_domains = slackbox.fr,
                        unixbox.fr

...

# Tables de correspondance
alias_maps = hash:/etc/postfix/aliases
alias_database = hash:/etc/postfix/aliases
local_recipient_maps = hash:/etc/postfix/local-recips $alias_maps
canonical_maps = hash:/etc/postfix/canonical
virtual_alias_maps = hash:/etc/postfix/virtual

Il ne reste qu’à recharger Postfix pour prendre en compte la nouvelle configuration.

# /etc/rc.d/rc.postfix reload

Utiliser le port 587 pour l’envoi

Certains FAI – comme par exemple Orange – bloquent l’accès au port 25. Dans ce cas, il faut configurer Postfix pour passer par le port 587 pour l’envoi de messages.

Éditer /etc/postfix/master.cf et décommenter la ligne suivante.

smtp       inet  n    -    n    -    -    smtpd
#smtp      inet  n    -    n    -    1    postscreen
#smtpd     pass  -    -    n    -    -    smtpd
#dnsblog   unix  -    -    n    -    0    dnsblog
#tlsproxy  unix  -    -    n    -    0    tlsproxy
submission inet  n    -    n    -    -    smtpd

Relancer Postfix pour prendre en compte la nouvelle configuration.

# /etc/rc.d/rc.postfix restart

Régler les problèmes de permissions

Après une mise à jour, il se peut que l’on ait des problèmes de permissions. Voici ce qu’il faut faire.

# /etc/rc.d/rc.postfix stop
# killall -9 postdrop
# cd /var/spool/postfix
# chown -R root:postdrop public maildrop
# postfix set-permissions
# postfix check
# /etc/rc.d/rc.postfix start

Supprimer Postfix

Arrêter le service :

# /etc/rc.d/rc.postfix stop

Supprimer le paquet :

# removepkg postfix 

Supprimer les fichiers de configuration :

# rm -rf /etc/postfix/ 

Supprimer le script de démarrage :

# rm -f /etc/rc.d/rc.postfix

Supprimer les utilisateurs et les groupes système correspondants :

# userdel -r postfix
# groupdel postdrop

Remarque : userdel -r postfix supprime également le groupe postfix.

Publié dans Documentation Microlinux, Slackware | Marqué avec , , , | 2 commentaires