Configurer la disposition du clavier sous CentOS

Disposition clavierCet article fournit un aperçu rapide sur la configuration du clavier sous CentOS 7. Dans certains cas de figure, on souhaitera modifier la disposition du clavier telle qu’elle a été définie lors de l’installation. Cette modification peut être temporaire ou permanente. Avec l’avènement de systemd sous CentOS 7, la configuration utilise la commande localectl.

Configuration temporaire

Pour changer la disposition du clavier de la console de façon temporaire, on utilisera la commande loadkeys.

Clavier français AZERTY :

# loadkeys fr

Clavier allemand QWERTZ :

# loadkeys de

Clavier QWERTZ suisse romand :

# loadkeys ch-fr

Configuration permanente

On utilisera la commande localectl pour configurer le clavier de façon permanente. L’option status affiche la configuration actuelle.

# localectl status
   System Locale: LANG=fr_FR.UTF-8
       VC Keymap: ch-fr
      X11 Layout: ch
     X11 Variant: fr

Sur cette machine, j’utilise un clavier QWERTZ suisse romand en mode console (VC Keymap) aussi bien qu’en mode graphique (X11 Layout).

L’option list-keymaps affiche la liste complète des dispositions clavier.

# localectl list-keymaps

Admettons que je veuille basculer mon système en clavier français AZERTY pour la console et l’environnement graphique. Dans un premier temps, je filtre la sortie pour afficher les dispositions clavier correspondant à la langue française.

# localectl list-keymaps | grep fr

À partir de là, les options set-keymap et set-x11-keymap permettent respectivement de définir la disposition du clavier pour la console et le mode graphique.

# localectl set-keymap fr
# localectl set-x11-keymap fr

On notera que dans la configuration par défaut de localectl, set-keymap et set-x11-keymap sont liés. Autrement dit, la définition d’un clavier AZERTY pour la console définira également un clavier AZERTY pour le mode graphique, et vice versa. L’option --no-convert permet de désactiver ce comportement.

# localectl set-keymap --no-convert fr
# localectl set-x11-keymap --no-convert ch-fr
# localectl status
   System Locale: LANG=fr_FR.UTF-8
       VC Keymap: fr
      X11 Layout: ch-fr
Publié dans CentOS, Documentation Microlinux | Marqué avec , | Laisser un commentaire

Configurer les cartes vidéo NVidia sous CentOS

NVidiaCet article décrit l’installation et la configuration des pilotes propriétaires NVidia sous CentOS. Dans la configuration par défaut, les cartes graphiques NVidia utilisent le pilote libre nouveau. Celui-ci fonctionne tout à fait honorablement, mais pour profiter pleinement des capacités de ce genre de cartes, il vaut mieux opter pour le pilote propriétaire nvidia.

Nous avons le choix entre deux prodécures d’installation bien différentes.

  1. Soit nous passons par le dépôt de paquets tiers ELRepo. Ce dépôt est spécialisé dans les pilotes non libres et fournit tout ce qu’il faut pour configurer les cartes NVidia.
  2. Soit nous téléchargeons les pilotes directement sur le site de NVidia, auquel cas il faudra les construire localement.

Passer en mode console

La configuration du pilote s’effectue à partir du mode console. Sous CentOS 7, la commande suivante sert à basculer manuellement vers ce mode.

# systemctl isolate multi-user.target

Ensuite, on peut démarrer dessus par défaut.

# systemctl set-default multi-user.target

Blacklister le pilote nouveau

Le pilote libre nouveau entre en conflit avec le pilote propriétaire nvidia.

# lsmod | grep nouveau
nouveau              1527946  1 
video                  24400  1 nouveau
mxm_wmi                13021  1 nouveau

On va donc empêcher son chargement. Éditer ou créer un fichier /etc/modprobe.d/blacklist.conf comme ceci.

blacklist nouveau

Il faut également empêcher nouveau d’être chargé au démarrage, en éditant /etc/default/grub comme ceci.

GRUB_CMDLINE_LINUX="rhgb \
                    quiet \
                    rd.driver.blacklist=nouveau \
                    nouveau.modeset=0

Si l’on utilise le pilote propriétaire du dépôt ELRepo, la configuration de GRUB et le blocage du pilote nouveau se fait automatiquement.

Prendre en compte les modifications.

# grub2-mkconfig -o /boot/grub2/grub.cfg

Redémarrer et vérifier si le pilote nouveau a bien été blacklisté.

# lsmod | grep nouveau

Identifier la carte et le pilote correspondant

Afficher le modèle de la carte.

# lspci | grep -i vga
01:00.0 VGA compatible controller: NVIDIA Corporation GT218 
[GeForce 210] (rev a2)

Autre exemple.

# lspci | grep -i vga
01:00.0 VGA compatible controller: NVIDIA Corporation G96 
[GeForce 9400 GT] (rev a1)

Le dépôt ELRepo fournit l’utilitaire nvidia-detect qui permet d’afficher le pilote correspondant à notre carte.

# yum --enablerepo=elrepo install nvidia-detect

Carte GeForce GT218 sous CentOS 7

Notre première carte est un modèle très courant.

# nvidia-detect
kmod-nvidia-340xx

J’installe le pilote recommandé.

# yum --enablerepo=elrepo install kmod-nvidia-340xx

À partir de là, il suffit de redémarrer, et le tour est joué.

Carte GeForce 9400 GT sous CentOS 7

Notre deuxième carte est une GeForce 9400, et ici, les choses se présentent plutôt mal.

# nvidia-detect 
kmod-nvidia-340xx
WARNING: The driver for this device does not support 
the current Xorg version

Tentons notre chance avec le pilote fourni par NVidia. Au préalable, il va falloir installer quelques outils de construction pour ce pilote.

# yum install gcc make kernel-devel

Ranger le pilote rapatrié dans un endroit convenable en définissant les droits d’exécution.

# cd /root/nvidia
# chmod +x NVIDIA-Linux-x86_64-340.102.run

Lancer la construction.

# ./NVIDIA-Linux-x86_64-340.102.run

L’interface de construction pose une série de questions. Étant donné que je dispose d’un système 64-bit pur, je n’installe pas les bibliothèques de compatibilité 32-bits. Si l’on n’a pas lancé l’utilitaire de configuration automatique, on peut toujours l’invoquer plus tard.

# nvidia-xconfig

La commande génère un fichier de configuration /etc/X11/xorg.conf.

Touches finales

Tester le bon fonctionnement du pilote en tant qu’utilisateur normal.

$ startx

Si tout s’est bien passé, on peut revenir en mode graphique.

# systemctl set-default graphical.target
# systemctl isolate graphical.target

 

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

Organiser les hôtes virtuels Apache sous CentOS

Apache Virtual HostsComme la plupart des distributions Linux, Red Hat et CentOS fournissent un répertoire comprenant une série de fichiers de configuration modulaires pour Apache, en l’occurrence /etc/httpd/conf.d. Ces fichiers sont pris en compte grâce à la directive Include qui figure dans le fichier de configuration principal /etc/httpd/conf/httpd.conf.

# Load config files in the "/etc/httpd/conf.d" directory, if any.
IncludeOptional conf.d/*.conf

Le répertoire /etc/httpd/conf.d contient un fichier README qui nous renseigne un peu plus sur le fonctionnement particulier de cette configuration modulaire.

This directory holds configuration files for the Apache HTTP Server;
any files in this directory which have the ".conf" extension will be
processed as httpd configuration files.  The directory is used in
addition to the directory /etc/httpd/conf.modules.d/, which contains
configuration files necessary to load modules.

Files are processed in alphabetical order.

L’info à retenir ici, c’est que les bouts de fichiers de configuration pour Apache sont traités par ordre alphabétique. Partant de là, on peut répartir la configuration des hôtes virtuels sur plusieurs fichiers pour plus de lisibilité, avec un VirtualHost par fichier, et en nommant chaque fichier en correspondance avec le nom d’hôte. Voici la solution que j’ai adoptée sur mes serveurs.

Dans un premier temps, les fichiers contenant la configuration globale d’Apache sont préfixés 00-* comme ceci.

# cd /etc/httpd/conf.d
# ls
autoindex.conf  php.conf  README  ssl.conf  userdir.conf  
welcome.conf
# for FILE in $(ls *.conf); do
> mv $FILE 00-$FILE
> done
# ls
00-autoindex.conf  00-php.conf  00-ssl.conf  00-userdir.conf  
00-welcome.conf README

Ensuite, j’ai deux hôtes virtuels qui pointent vers la page par défaut, un pour le HTTP, l’autre pour le HTTPS. Les deux sont préfixés 10-* comme ceci.

  • 10-default.conf
  • 10-default-ssl.conf

Enfin, les hébergements à proprement parler sont tous préfixés 20-* et nommés en fonction du nom d’hôte. Les hébergements sécurisés portent tous le suffixe -ssl.conf. Voici ce que l’on obtient au total.

# ls -1
00-autoindex.conf
00-php.conf
00-ssl.conf
00-userdir.conf
00-welcome.conf
10-default.conf
10-default-ssl.conf
20-freebsd.slackbox.fr.conf
20-mail.slackbox.fr.conf
20-mail.slackbox.fr-ssl.conf
20-mail.unixbox.fr.conf
20-mail.unixbox.fr-ssl.conf
20-nextcloud.slackbox.fr.conf
20-nextcloud.slackbox.fr-ssl.conf
20-nextcloud.unixbox.fr.conf
20-nextcloud.unixbox.fr-ssl.conf
20-slackware.slackbox.fr.conf
20-www.slackbox.fr.conf
20-www.unixbox.fr.conf
README

Pour un hébergement sécurisé comme 20-mail.slackbox.fr-ssl.conf, le fichier 20-mail.slackbox.fr.conf pourra contenir une redirection HTTP > HTTPS.

 

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

Certificats SSL/TLS avec Certbot sous CentOS

Certificat[Travail en cours.]

Cet article décrit la gestion des certificats SSL/TLS gratuits sur un serveur dédié tournant sous CentOS 7. 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

Certbot est fourni par le dépôt EPEL.

# yum install certbot

On notera au passage que le paquet dépend d’une quantité importante de modules Python.

Plug-ins

Le client Certbot supporte une série de plug-ins pour Apache et Nginx. L’option plugins permet d’afficher les plug-ins installés.

# certbot 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

Notre installation dispose des plug-ins webroot et standalone.

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.

# systemctl stop httpd

Éventuellement, il faudra créer l’arborescence de l’hébergement sécurisé au préalable.

# mkdir -pv /var/www/html/slackbox-secure/html
mkdir: created directory ‘/var/www/html/slackbox-secure’
mkdir: created directory ‘/var/www/html/slackbox-secure/html’

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

# certbot certonly --non-interactive --email info@microlinux.fr \
  --preferred-challenges tls-sni-01 --standalone --agree-tos \
  --renew-by-default -d www.slackbox.fr -d slackbox.fr \
  --webroot-path /var/www/html/slackbox-secure/html --test-cert

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Starting new HTTPS connection (1): acme-staging.api.letsencrypt.org
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/0004_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0004_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-07-24. 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.

Sur une Dedibox, on peut tenter de créer un certificat propre à la machine.

# certbot certonly --non-interactive --email info@microlinux.fr \
  --preferred-challenges tls-sni-01 --standalone --agree-tos \
  --renew-by-default -d sd-41893.dedibox.fr \
  --webroot-path /var/www/html/default/html 

Avec un peu de chance, ça passe. Dans le cas contraire, on est gratifié d’un message d’erreur de dépassement de quota en raison d’un nombre de sous-domaines trop élevé pour le domaine dedibox.fr. Cela dépend des jours.

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.

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

 

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

Hébergement sécurisé avec Apache et SSL sous CentOS

HTTPS

[Travail en cours.]

Cet article décrit la mise en place d’un hébergement sécurisé sur un serveur Apache tournant sous CentOS 7. Le protocole HTTP (Hypertext Transfer Protocol) transmet les données entre le serveur et le navigateur « en clair ». Les données personnelles, mots de passe et autres numéros de Carte Bleue sont donc interceptables. Pour résoudre ce problème, on utilisera le protocole HTTPS, qui ajoute une couche de cryptage SSL (Secure Sockets Layer) au protocole HTTP.

Le transfert crypté des données ne constitue qu’un aspect dans l’établissement d’une connexion sécurisé. L’autre aspect tout aussi important, c’est que l’utilisateur doit être sûr de communiquer avec la bonne personne. Autrement dit, votre numéro de Carte Bleue a beau être transmis de façon sécurisée, encore faut-il que la plateforme de paiement ne soit pas située sur un serveur géré par la mafia albanaise.

Pour savoir si l’on a bien affaire au bon interlocuteur, on utilisera un certificat. Cette véritable carte d’identité électronique contient non seulement la clé publique du serveur pour crypter les transmissions, mais également des renseignements sur le site ainsi que la signature de l’autorité de certification.

La génération d’un certificat électronique fait l’objet d’un article à part. Pour nos essais, nous utiliserons un certificat SSL/TLS fourni par le client Certbot. Si l’on décide de partir sur un certificat auto-signé, la configuration devra être adaptée en conséquence.

Dans l’exemple ci-dessous, nous allons configurer un hébergement public https://sd-41893.dedibox.fr.

Prérequis

Le protocole HTTPS utilise le port 443. Il faut donc songer avant toute chose à ouvrir ce port dans le pare-feu.

Installation

Le chiffrement SSL/TLS pour Apache est fourni par le paquet mod_ssl.

# yum install mod_ssl

On notera l’apparition d’un fichier de configuration ssl.conf dans /etc/httpd/conf.d.

Configurer Apache et SSL

Notre hébergement HTTPS sera rangé en-dessous de /var/www/html comme nos hôtes virtuels HTTP. Éditer /etc/httpd/conf.d/ssl.conf en renseignant les directives DocumentRoot et ServerName ainsi que l’emplacement du certificat SSL et de la clé privée.

##
## SSL Virtual Host Context
##
<VirtualHost _default_:443>
DocumentRoot "/var/www/html/default/html"
ServerName sd-41893.dedibox.fr:443
...
SSLCertificateFile /chemin/vers/cert.pem
SSLCertificateKeyFile /chemin/vers/privkey.pem
SSLCertificateChainFile /chemin/vers/fullchain.pem
...
</VirtualHost>

Redémarrer Apache.

# systemctl restart httpd

Ouvrir le site avec Firefox. On notera la présence du petit cadenas vert en haut à gauche dans la barre d’adresses pour indiquer l’établissement d’une connexion sécurisée.

Dedibox HTTPS

Améliorer la sécurité de notre hébergement

Rendons-nous sur la page SSL Server Test du portail Qualys SSL Labs pour effectuer un audit de la sécurité de notre hébergement.

Qualys Labs SSL Server Test

Pour l’heure, la résultat est plutôt médiocre et comporte une série de vulnérabilités, que nous allons éliminer l’une après l’autre en suivant les suggestions affichées.

La vulnérabilité à l’attaque POODLE se résoud en désactivant SSLv3 dans ssl.conf. L’option SSLProtocol se situe dans la configuration de l’hôte virtuel. Il faut la déplacer au début du fichier dans les options globales, en ajoutant -SSLv3, comme ceci.

#
# When we also provide SSL we have to listen to the 
# the HTTPS port in addition.
#
Listen 443 https

##
##  SSL Global Context
##
##  All SSL configuration in this context applies both to
##  the main server and all SSL-enabled virtual hosts.
##

#   SSL Protocol support:
# List the enable protocol levels with which clients will be able 
# to connect.  Disable SSLv2 access by default:
SSLProtocol all -SSLv2 -SSLv3

Prendre en compte les modifications et relancer un test sur le site de Qualys Labs en cliquant sur Clear cache.

Qualys Labs SSL Server Test

C’est déjà un peu mieux. La prochaine suggestion concerne la désactivation du chiffrement RC4. Cette fois-ci, il faut récupérer l’option SSLCipherSuite dans la configuration de l’hôte virtuel et la placer en tête du fichier dans les options globales, en ajoutant !RC4.

#   SSL Protocol support:
# List the enable protocol levels with which clients will be able to
# connect.  Disable SSLv2 access by default:
SSLProtocol all -SSLv2 -SSLv3

#   SSL Cipher Suite:
#   List the ciphers that the client is permitted to negotiate.
#   See the mod_ssl documentation for a complete list.
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA:!RC4

Recharger la configuration d’Apache et relancer un test.

Qualys SSL Labs Server Test

On avance petit à petit. Pour nous débarrasser de la vulnérabilité restante, repérer l’option commentée SSLHonorCipherOrder et l’insérer juste après SSLCipherSuite en la décommentant.

#   SSL Cipher Suite:
#   List the ciphers that the client is permitted to negotiate.
#   See the mod_ssl documentation for a complete list.
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA:!RC4
SSLHonorCipherOrder on

Cette fois-ci, nous avons bel et bien éliminé l’ensemble des failles de sécurité connues concernant le chiffrement.

Qualys SSL Labs Server Test

La politique HSTS

HSTS (HTTP Strict Transport Security) est un mécanisme de politique de sécurité proposé pour HTTP, permettant à un serveur web de déclarer à un agent utilisateur (navigateur web) compatible qu’il doit interagir avec lui en utilisant une connexion sécurisée (comme HTTPS). La politique est donc communiquée à l’agent utilisateur par le serveur via la réponse HTTP, dans le champ d’en-tête nommé Strict-Transport-Security. La politique spécifie une période de temps durant laquelle l’agent utilisateur doit accéder au serveur uniquement de façon sécurisée.

Pour activer cette politique dans la configuration d’Apache, il suffit d’ajouter la ligne suivante dans la définition de l’hôte virtuel.

# /etc/httpd/extra/httpd-ssl.conf 
...
<VirtualHost _default_:443>
# HSTS
Header always set Strict-Transport-Security \
  "max-age=63072000; includeSubDomains"
...
</VirtualHost>

L’audit de sécurité nous montre qu’on est assez proche de la perfection.

Qualys SSL Labs Server Test

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

Installer et configurer Recoll sous CentOS

RecollCet article décrit l’installation et la configuration de Recoll sur un poste de travail tournant sous CentOS 7. Recoll est un outil personnel de recherche textuelle pour Unix et Linux. Il est basé sur le moteur d’indexation Xapian, pour lequel il offre une interface graphique facile à utiliser. Il traite la plupart des types de documents, que ceux-ci soient comprimés ou non, en utilisant une série d’applications externes pour l’extraction du texte. Si l’on en croit la description des développeurs, Recoll est capable d’indexer un document Microsoft Word enregistré comme pièce jointe dans un e-mail rangé dans un dossier Thunderbird lui-même archivé dans un fichier Zip.

Installation

Recoll n’est fourni par aucun dépôt de paquets. Les développeurs de l’application fournissent une série de paquets RPM pour CentOS sur la page de téléchargement. Nous allons récupérer les dépendances du paquet d’une autre manière.

La seule dépendance stricte de Recoll, c’est le paquet xapian-core-libs fourni par le dépôt EPEL.

# yum install xapian-core-libs

Recoll utilise une poignée d’outils externes qui lui permettent d’indexer certains types de fichiers. Dans la configuration par défaut, il nous manque deux de ces outils, perl-Image-ExifTool et untex. Le premier est fourni par le dépôt EPEL.

# yum install perl-Image-ExifTool

Quant à untex, on peut le trouver sur le site des Linux Forensics Tools.

Télécharger et installer le paquet.

# yum localinstall untex-1.3-3.1.el7.x86_64.rpm

Maintenant que toutes les dépendances externes sont satisfaites, on peut récupérer le paquet recoll depuis la page de téléchargement du projet. Le paquet RPM compilé par les soins des développeurs n’est pas tout à fait à jour par rapport à la dernière version disponible. En attendant, on va faire avec les moyens de bord.

Installer le paquet.

# yum localinstall recoll-1.21.5-1.el7.centos.x86_64.rpm

Configuration et utilisation

Au premier démarrage, Recoll veut savoir comment vous souhaitez organiser l’indexation de vos documents. Cliquez sur Planning de l’indexation.

Recoll

Dans la fenêtre subséquente, choisissez Démarrage de l’indexation au fil de l’eau.

Recoll

Enfin, configurez le lancement du démon de recherche et démarrez-le.

Recoll

Selon le nombre de documents que vous stockez sur votre machine, l’indexation initiale mettra un certain temps. Une fois que l’ensemble des données est indexé, les opérations de recherche sont extrêmement rapides, et les résultats plutôt pertinents.

Recoll

En conclusion, Recoll est un outil de recherche intuitif et puissant, susceptible d’améliorer le workflow au quotidien.

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

Configurer une imprimante/scanner réseau HP sous CentOS

HPCet article décrit de manière succincte la configuration d’une imprimante/scanner HP en réseau sur un poste de travail tournant sous CentOS 7.

Vérifier si le serveur d’impression CUPS tourne correctement.

# systemctl status cups
cups.service - CUPS Printing Service
 ...
 Active: active (running)

Installer HPLIP.

# yum install hplip-gui

Ce paquet installe automatiquement les dépendances hplip et hpijs.

Dans le réseau local, l’imprimante est configurée avec un nom d’hôte correspondant.

# nmap -sP hp-officejet
Nmap scan report for hp-officejet (192.168.2.252)
Host is up (0.00012s latency).
rDNS record for 192.168.2.252: hp-officejet.microlinux.lan
MAC Address: 88:51:FB:15:3A:4A (Hewlett Packard)
Nmap done: 1 IP address (1 host up) scanned in 0.08 seconds

Ouvrir un terminal et lancer le téléchargement du plug-in HP.

$ hp-plugin

La commande devra être invoquée en tant que simple utilisateur, même si par la suite l’assistant requiert la saisie du mot de passe root.

hp-plugin

Une fois que le plug-in est installé, lancer le HP Device Manager dans le menu d’applications et cliquer sur Setup Device.

HPLIP

Choisir le type de connexion Network/Ethernet/Wireless. Si jamais l’autodétection ne fonctionne pas, afficher les options avancées (Advanced Options), cocher Manual Discovery et saisir le nom d’hôte ou l’adresse IP de l’imprimante. On pourra conserver la valeur par défaut 1 pour Jetdirect port.

HPLIP

Dans notre cas, l’autodétection fonctionne très bien.

HPLIP

Les deux champs Decription et Location sont facultatifs, mais je les renseigne quand-même. Je décoche la configuration du fax, que je n’utilise pas. Notez que je ne coche pas non plus l’impression de la page de test. Cette fonctionnalité de HPLIP souffre d’un bug, même si l’imprimante fonctionne par ailleurs.

HPLIP

La configuration de l’imprimante nécessite les droits d’administrateur.

HPLIP

Si tout se passe bien, le HP Device Manager affiche l’imprimante dans la fenêtre principale.

HPLIP

L’opération devra être répétée sur chacun des postes clients à partir desquels on souhaite imprimer.

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

Configurer un serveur web Apache sous CentOS

Apache est le principal serveur Web du monde de l’Open Source. D’après les statistiques de Netcraft, plus de la moitié des sites Web du monde tournent sur un serveur Apache.

Une installation typique d’Apache est généralement constituée d’un assemblage cohérent de paquets.

  • le serveur Apache à proprement parler
  • des bibliothèques diverses et variées
  • des plug-ins
  • des langages de programmation
  • etc.

Cette page décrit la configuration d’un serveur Web de type LAMP (Linux + Apache + MySQL/MariaDB + PHP) sur CentOS 7.

Prérequis

Apache utilise le port 80 en TCP pour le protocole HTTP. Il faudra donc songer à ouvrir ce port dans le pare-feu.

Installation

Le serveur Apache est fourni par le paquet httpd.

# yum install httpd

Passer SELinux en mode permissif.

# setenforce 0

Activer et lancer Apache.

# systemctl enable httpd
# systemctl start httpd

Tester le bon fonctionnement du serveur.

# links http://localhost

On doit voir quelque chose de ce genre.

=================================================================
                           Testing 123..
This page is used to test the proper operation of the Apache HTTP
server after it has been installed. If you can read this page it 
means that this site is working properly. This server is powered 
by CentOS.
=================================================================

Dans le réseau local, ouvrir l’adresse IP du serveur avec un navigateur.

  • http://192.168.2.5

On peut également invoquer le nom d’hôte.

  • http://amandine.microlinux.lan

Sur un serveur dédié, on essaiera successivement l’adresse IP, le nom de domaine et l’alias associé.

  • http://195.154.65.130
  • http://slackbox.fr
  • http://www.slackbox.fr

Voici à quoi ressemble la page par défaut dans un navigateur graphique.

Apache Test

Configuration de base

Le principal fichier de configuration d’Apache, c’est /etc/httpd/conf/httpd.conf. Avant de modifier quoi que ce soit, on va faire une copie du fichier de configuration par défaut.

# cd /etc/httpd/conf
# cp httpd.conf httpd.conf.orig

On peut déjà renseigner quelques directives.

# /etc/httpd/conf/httpd.conf
...
ServerAdmin info@microlinux.fr
...
ServerName  amandine.microlinux.lan
...
  • L’adresse mail de l’administrateur apparaîtra sur certaines pages générées par le serveur, notamment les pages d’erreur.
  • Le nom du serveur peut être déterminé automatiquement, mais il vaut mieux le spécifier explicitement.

Sur un serveur dédié, on aura ceci.

# /etc/httpd/httpd.conf
...
ServerName sd-41893.dedibox.fr
...

Prendre en compte les modifications.

# systemctl reload httpd

Organisation des fichiers de configuration

Le fichier /etc/httpd/conf/httpd.conf ne contient pas l’intégralité de la configuration d’Apache. Jetons un oeil à la dernière ligne de ce fichier.

# Load config files in the "/etc/httpd/conf.d" directory, if any.
IncludeOptional conf.d/*.conf

En langage tam-tam, cela signifie qu’il faut également tenir compte de tous les fichiers *.conf contenus dans le répertoire /etc/httpd/conf.d.

# cd /etc/httpd/conf.d/
# ls *.conf
autoindex.conf userdir.conf welcome.conf

Héberger un site statique

Apache est immédiatement utilisable dans sa configuration par défaut. Le serveur affiche le contenu du répertoire /var/www/html, défini par la directive DocumentRoot dans le fichier /etc/httpd/conf/httpd.conf.

DocumentRoot "/var/www/html"

Ce répertoire est vide par défaut. En l’absence de contenu, c’est la page de test qui s’affiche, en fonction de la configuration prédéfinie dans /etc/httpd/conf.d/welcome.conf.

Pour nous épargner la corvée de créer du contenu bidon, nous pouvons très bien récupérer un site web existant. On choisira la documentation de Slackware, qui vient sous forme d’une série de pages HTML statiques.

# cd /var/www/html/
# wget -r -np -nH --cut-dirs=1 http://www.slackbook.org/html/

Apache n’est pas censé tourner en tant que root, mais en tant qu’utilisateur spécial défini par les directives User et Group dans /etc/httpd/conf/httpd.conf.

User apache
Group apache

On va donc attribuer toutes les pages de notre site local à cet utilisateur et à ce groupe. En passant, on va restreindre les droits d’accès au minimum nécessaire.

# cd /var/www
# chown -R apache:apache html/
# find html/ -type d -exec chmod 0750 \{} \;
# find html/ -type f -exec chmod 0640 \{} \;

À présent, on peut ouvrir le site dans un navigateur (Firefox, Links, Lynx) et apprécier le résultat.

Apache et SELinux (1)

Jetons un premier coup d’oeil sur ce que pense SELinux de notre configuration.

# sealert -a /var/log/audit/audit.log 
100% done
found 0 alerts in /var/log/audit/audit.log

On notera que le site web statique récupéré avec wget a été créé d’emblée avec le contexte de sécurité approprié httpd_sys_content_t. Tout va donc très bien jusqu’ici.

Héberger plusieurs sites sur un serveur local

Le principe des hôtes virtuels (Virtual Hosts) consiste à faire fonctionner un ou plusieurs sites Web sur une même machine. L’utilisateur final ne perçoit pas qu’en fait il s’agit d’un même serveur physique.

Sur un serveur local, on pourra essayer d’héberger trois sites.

  • http://slackware.amandine hébergera la documentation de Slackware.
  • http://freebsd.amandine affichera la documentation de FreeBSD.
  • http://amandine pointera vers la page par défaut du serveur.

Pour commencer, on va déplacer le site existant dans un nouveau répertoire slackware/html.

# cd /var/www/html
# mkdir -pv ../slackware/html
mkdir: création du répertoire « ../slackware »
mkdir: création du répertoire « ../slackware/html »
# mv * ../slackware/html/
# mv ../slackware/ .

Puis, on va créer un autre répertoire freebsd/html, dans lequel on va télécharger un autre site, en l’occurrence la documentation de FreeBSD.

# mkdir -pv freebsd/html
mkdir: création du répertoire « freebsd »
mkdir: création du répertoire « freebsd/html »
# cd freebsd/html
# wget -r -p -np -nH --cut-dirs=4 \
  http://www.freebsd.org/doc/fr_FR.ISO8859-1/books/handbook/

Enfin, on va mettre en place une page par défaut dans le répertoire default/html. Pour ce faire, on va utiliser la page qui s’affiche lorsqu’il n’y a pas de contenu.

# cd /var/www/html/
# mkdir -pv default/html
mkdir: création du répertoire « default »
mkdir: création du répertoire « default/html »
# cp -R /usr/share/httpd/noindex/* default/html/

Au total, on a donc…

# ls -l
total 12
drwxr-xr-x 3 root root 4096 23 févr. 06:36 default
drwxr-xr-x 3 root root 4096 23 févr. 06:21 freebsd
drwxr-xr-x 3 root root 4096 23 févr. 06:19 slackware

On va définir les permissions à la louche.

# chown -R apache:apache *
# find . -type d -exec chmod 0750 \{} \;
# find . -type f -exec chmod 0640 \{} \;

Créer un fichier /etc/httpd/conf.d/default.conf. Ce fichier définira le site affiché par défaut, c’est-à-dire lorsqu’on invoque l’adresse IP ou le nom d’hôte de la machine.

# /etc/httpd/conf.d/default.conf
#
# Page par défaut
<VirtualHost *:80>
  ServerAdmin info@microlinux.fr
  DocumentRoot "/var/www/html/default/html"
  ServerName amandine.microlinux.lan
  ServerAlias amandine
  ErrorLog logs/default-error_log
  CustomLog logs/default-access_log common
</VirtualHost>

Une remarque en passant. Nous aurions pu très bien ajouter cette stance dans le fichier /etc/httpd/conf/httpd.conf. La création de fichiers *.conf individuels dans /etc/httpd/conf.d est motivée avant tout par un souci de clarté et de lisibilité.

Prendre en compte les modifications.

# systemctl reload httpd

Vérifier si la page par défaut du serveur s’affiche comme prévu.

 # links http://amandine.microlinux.lan

À présent, nous pouvons ajouter les deux autres sites. Le site http://slackware.amandine sera configuré comme ceci.

# /etc/httpd/conf.d/slackware.conf
#
# La documentation de Slackware
<VirtualHost *:80>
  ServerAdmin info@microlinux.fr
  DocumentRoot "/var/www/html/slackware/html"
  ServerName slackware.amandine.microlinux.lan
  ServerAlias slackware.amandine
  ErrorLog logs/slackware-error_log
  CustomLog logs/slackware-access_log common
</VirtualHost>

La configuration de http://freebsd.amandine suivra la même logique.

# /etc/httpd/conf.d/freebsd.conf
#
# La documentation de FreeBSD
<VirtualHost *:80>
  ServerAdmin info@microlinux.fr
  DocumentRoot "/var/www/html/freebsd/html"
  ServerName freebsd.amandine.microlinux.lan
  ServerAlias freebsd.amandine
  ErrorLog logs/freebsd-error_log
  CustomLog logs/freebsd-access_log common
</VirtualHost>

Pour l’instant, les noms d’hôtes slackware.amandine et freebsd.amandine ne correspondent à rien dans notre réseau local. Nous devons les ajouter à /etc/hosts sur le serveur.

# Amandine
192.168.2.5 amandine.microlinux.lan amandine
192.168.2.5 freebsd.amandine.microlinux.lan freebsd.amandine
192.168.2.5 slackware.amandine.microlinux.lan slackware.amandine

Redémarrer Dnsmasq pour propager l’info DNS.

# systemctl restart dnsmasq

Prendre en compte la nouvelle configuration d’Apache.

# systemctl reload httpd

Tester les deux sites en local avec Links ou Firefox sur une machine du réseau local.

  • http://slackware.amandine.microlinux.lan
  • http://freebsd.amandine.microlinux.lan

Régler les problèmes d’encodage

Dans la configuration actuelle, la documentation de FreeBSD n’affiche pas correctement les caractères accentués.

Encodage ISO

Ce comportement est dû à la directive AddDefaultCharset dans le fichier /etc/httpd/conf/httpd.conf.

AddDefaultCharset UTF-8

Or, le code source de la page d’accueil de FreeBSD spécifie un encodage différent.

<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>

Pour remédier à cela, il suffit de commenter la directive AddDefaultCharset, ce qui permettra aux pages hébergées de spécifier leur propre encodage.

#AddDefaultCharset UTF-8

Ne pas oublier de prendre en compte la nouvelle configuration.

# systemctl reload httpd

Une fois que l’on a rectifié l’encodage, Links affiche correctement la page. Firefox est plus dur de la feuille, et il faut éventuellement rectifier l’encodage manuellement (Affichage > Encodage de caractères) pour une page présente dans le cache du navigateur.

Héberger plusieurs sites sur une machine publique

Sur un serveur dédié avec un ou plusieurs domaines publiquement accessibles, la configuration de la page par défaut ressemblera à ceci.

# /etc/httpd/conf.d/default.conf
#
# Page par défaut
<VirtualHost *:80>
  ServerAdmin info@microlinux.fr
  DocumentRoot "/var/www/html/default/html"
  ServerName sd-41893.dedibox.fr
  ErrorLog logs/default-error_log
  CustomLog logs/default-access_log common
</VirtualHost>

La documentation de Slackware sera hébergée sur l’hôte slackware.slackbox.fr.

# /etc/httpd/conf.d/slackware.conf
#
# La documentation de Slackware
<VirtualHost *:80>
  ServerAdmin info@microlinux.fr
  DocumentRoot "/var/www/html/slackware/html"
  ServerName slackware.slackbox.fr
  ErrorLog logs/slackware-error_log
  CustomLog logs/slackware-access_log common
</VirtualHost>

Et pour l’hébergement de la documentation de FreeBSD, on suivra la même logique.

# /etc/httpd/conf.d/freebsd.conf
#
# La documentation de FreeBSD
<VirtualHost *:80>
  ServerAdmin info@microlinux.fr
  DocumentRoot "/var/www/html/freebsd/html"
  ServerName freebsd.slackbox.fr
  ErrorLog logs/freebsd-error_log
  CustomLog logs/freebsd-access_log common
</VirtualHost>

Cette fois-ci, l’information sur les hôtes slackware.slackbox.fr et freebsd.slackbox.fr devra être ajoutée dans le fichier zone de BIND, sous forme d’alias.

; /var/named/zone.slackbox.fr 
...
slackbox.fr.        A       195.154.65.130
ns      IN          A       195.154.65.130
mail    IN          A       195.154.65.130
www     CNAME               slackbox.fr.
ftp     CNAME               slackbox.fr.
slackware CNAME             slackbox.fr.     
freebsd   CNAME             slackbox.fr.     

Ne pas oublier de redémarrer BIND en incrémentant le numéro de série.

# systemctl restart named

Tester l’affichage des différents sites.

  • http://slackware.slackbox.fr
  • http://freebsd.slackbox.fr
  • http://www.slackbox.fr (page par défaut)
  • http://sd-41893.dedibox.fr (page par défaut)

Héberger des sites dynamiques avec PHP

Installer PHP.

# yum install php

Mettre en place un hôte virtuel http://phpinfo.amandine et éditer la configuration correspondante. L’hôte virtuel contiendra une seule page index.php que l’on éditera comme ceci.

<?php
 echo phpinfo();
?>

Ajouter une entrée correspondante dans la configuration DNS et redémarrer Apache.

# systemctl restart httpd

Afficher la page http://phpinfo.amandine dans un navigateur. On doit obtenir quelque chose qui ressemble grosso modo à ceci.

Infos PHP

Le fichier /etc/php.ini contient la configuration de PHP. On peut commencer par définir le fuseau horaire du serveur, nécessaire pour le bon fonctionnement de certaines applications.

[Date]
; Defines the default timezone used by the date functions
; http://php.net/date.timezone
date.timezone = Europe/Paris

Redémarrer Apache et vérifier les données correspondantes dans la page qui affiche les infos PHP.

Utiliser MySQL/MariaDB à partir de PHP

Pour utiliser MySQL/MariaDB à partir de PHP, il suffit d’installer le module correspondant et de redémarrer Apache.

# yum install php-mysql
# systemctl restart httpd

Téléchargement

Des modèles de fichiers de configuration pour les hôtes virtuels sont disponibles dans mon dépôt Github, dans le répertoire centos/el7/vhosts :

$ git clone https://github.com/kikinovak/centos
Publié dans CentOS, Documentation Microlinux | Marqué avec , | Laisser un commentaire

Configurer un serveur DNS avec BIND sous CentOS

DNSCet article décrit la mise en place d’un serveur DNS avec BIND sur un serveur dédié tournant sous CentOS 7. Le système de noms de domaine ou DNS (Domain Name System) permet d’établir une correspondance entre les adresses IP et les noms de domaine. Le DNS évite ainsi d’avoir à se rappeler des adresses IP.

Prérequis

Dans le pare-feu, ouvrir le port 53 en TCP et en UDP. Les gourous de la sécurité ont longtemps conseillé d’ouvrir le port 53 en UDP seulement pour les requêtes DNS. Or, ces dernières peuvent également utiliser le port 53 en TCP si l’UDP n’est pas accepté.

Installation

Outre le serveur bind à proprement parler, on installera le paquet bind-utils, qui fournit une collection d’outils comme dig, host et nslookup.

# yum install bind bind-utils

Basculer SELinux en mode permissif.

# setenforce 0

Serveur cache DNS

La configuration par défaut fournie par Red Hat est déjà assez sophistiquée. On va la sauvegarder pour partir sur quelque chose de plus simple.

# cd /etc
# mv named.conf named.conf.orig

Éditer /etc/named.conf comme ceci.

// /etc/named.conf

options {
  directory "/var/named";
};

zone "." IN {
  type hint;
  file "named.ca";
};

include "/etc/named.rfc1912.zones";

Régler les permissions de ce fichier.

# chown root:named /etc/named.conf
# chmod 0640 /etc/named.conf

Activer et démarrer BIND.

# systemctl enable named
# systemctl start named

Exécuter dig sur un domaine extérieur en vérifiant le temps de requête.

# dig centos.org @localhost
...
;; ANSWER SECTION:
centos.org.		60	IN	A	85.12.30.226
;; AUTHORITY SECTION:
centos.org.		14400	IN	NS	ns4.centos.org.
centos.org.		14400	IN	NS	ns1.centos.org.
centos.org.		14400	IN	NS	ns3.centos.org.
;; ADDITIONAL SECTION:
ns4.centos.org.		86400	IN	A	62.141.54.220
ns3.centos.org.		86400	IN	A	88.208.217.170
ns1.centos.org.		86400	IN	A	199.187.126.93
;; Query time: 110 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Apr 17 11:13:02 CEST 2017
;; MSG SIZE  rcvd: 157

Le temps de réponse devrait être bien plus court après une deuxième invocation de dig.

# dig centos.org @localhost
...
;; Query time: 5 msec

Configurer la journalisation

Dans notre configuration actuelle, les logs inondent /var/log/messages. Pour éviter ça, on va configurer une journalisation propre à BIND en ajoutant la stance correspondante à /etc/named.conf.

options {
  directory "/var/named";
};

logging {
  channel single_log {
    file "/var/log/named.log" versions 3 size 2m;
    severity info;
    print-time yes;
    print-severity yes;
    print-category yes;
  };
  category default {
    single_log;
  };
};

BIND ne peut pas créer ce fichier à la volée. On va donc le faire à sa place, en attribuant les permissions correctes.

# touch /var/log/named.log
# chown named:named /var/log/named.log

Relancer BIND pour prendre en compte les modifications.

# systemctl restart named

BIND et SELinux (1)

On peut déjà jeter un premier coup d’oeil sur ce que pense SELinux de notre configuration. Comme on peut s’y attendre, la définition d’un fichier journal personnalisé nous affiche une erreur. Voyons à quoi cela ressemble.

# sealert -a /var/log/audit/audit.log
100% done
found 1 alerts in /var/log/audit/audit.log
------------------------------------------------------------------
SELinux is preventing /usr/sbin/named from open access on the file 
/var/log/named.log.
*****  Plugin restorecon (99.5 confidence) suggests   *****
If you want to fix the label. 
/var/log/named.log default label should be named_log_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /var/log/named.log

Appliquons le contexte approprié comme indiqué.

# restorecon -v /var/log/named.log 
restorecon reset /var/log/named.log context unconfined_u:object_r:
var_log_t:s0->unconfined_u:object_r:named_log_t:s0

Effectivement, le problème est résolu.

# echo > /var/log/audit/audit.log
# systemctl restart named
# sealert -a /var/log/audit/audit.log
100% done
found 0 alerts in /var/log/audit/audit.log

Désactiver l’IPv6

Si l’on n’utilise pas l’IPv6, on peut désactiver le protocole en éditant /etc/sysconfig/named.

OPTIONS="-4"

Il faudra également ajouter une option à /etc/named.conf.

options {
  directory "/var/named";
  filter-aaaa-on-v4 yes;
};

Redémarrer BIND pour prendre en compte les modifications.

# systemctl restart named

Utiliser les DNS de base de chez Online

Online met à disposition deux serveurs DNS de base que nous allons utiliser de préférence.

options {
  directory "/var/named";
  filter-aaaa-on-v4 yes;
  forwarders {
    62.210.16.6;
    62.210.16.7;
  };
};

Redémarrer BIND.

# systemctl restart named

Serveur maître primaire

À présent, nous allons configurer BIND comme serveur maître primaire du domaine slackbox.fr. Le nom de domaine sera réservé au bureau d’enregistrement (registrar) BookMyName.com.

Pour ajouter une zone DNS à BIND afin de le transformer en serveur maître primaire, il faut tout d’abord indiquer l’emplacement du fichier de zone à /etc/named.conf. Pour plus de lisibilité, nous allons créer un fichier /etc/named.conf.local.

// /etc/named.conf.local 

zone "slackbox.fr" {
  type master;
  file "zone.slackbox.fr";
};

Le fichier named.conf.local aura les mêmes permissions que named.conf.

# chown root:named /etc/named.conf.local
# chmod 0640 /etc/named.conf.local

Éditer /etc/named.conf en incluant ce fichier.

zone "." IN {
  type hint;
  file "named.ca";
};

include "/etc/named.rfc1912.zones";
include "/etc/named.conf.local";

Le fichier /var/named/zone.slackbox.fr devra être édité comme ceci.

; /var/named/zone.slackbox.fr
$TTL 86400
$ORIGIN slackbox.fr.
@ IN SOA ns.slackbox.fr. hostmaster.slackbox.fr. (
   2017041701   ; sn
        10800   ; refresh (3 heures)
          600   ; retry (10 minutes)
      1814400   ; expiry (3 semaines)
        10800 ) ; minimum (3 heures)
        IN          NS      ns.slackbox.fr.
        IN          NS      nssec.online.net.
        IN          MX      10 mail.slackbox.fr.
slackbox.fr.        A       195.154.65.130
ns      IN          A       195.154.65.130
mail    IN          A       195.154.65.130
www     CNAME               slackbox.fr.
ftp     CNAME               slackbox.fr.

Définir les permissions qui vont bien.

# chown root:named /var/named/zone.slackbox.fr
# chmod 0640 /var/named/zone.slackbox.fr

Quelques remarques sur la syntaxe et les options utilisées.

  • La directive $TTL (Time To Live) définit le temps en secondes qu’un enregistrement pourra être gardé dans le cache par un autre serveur de noms.
  • La directive $ORIGIN définit le nom de domaine automatiquement ajouté à tous les noms de domaine incomplets (c’est-à-dire « non qualifiés ») définis dans un enregistrement DNS. Le nom de domaine est toujours un FQDN (Fully Qualified Domain Name) et se termine en conséquence par un point.
  • L’enregistrement SOA (Start Of Authority) définit les principales caractéristiques pour la zone ou le domaine avec un certain nombre de paramètres.
  • Le symbole @ se substitue à la valeur de $ORIGIN, concrètement à slackbox.fr.
  • IN définit la classe Internet. D’autres valeurs existent, mais elles sont rarement utilisées.
  • L’enregistrement NS définit le serveur de noms primaire pour la zone.
  • hostmaster.slackbox.fr définit l’adresse mail de l’administrateur de la zone. L’adresse hostmaster est recommandée, mais n’importe quelle adresse mail valide peut être définie ici. Étant donné que le symbole @ a une signification spécifique dans le contexte, on utilise les points comme séparateurs, ce qui explique la syntaxe bizarre. L’adresse mail définie ici est donc hostmaster@slackbox.fr.
  • 2017041701 définit le numéro de série associé à la zone. Par convention, on utilise le format AAAAMMJJSS. Le numéro de série doit impérativement être mis à jour à chaque fois que l’on modifie le domaine.
  • La valeur refresh contrôle la mise à jour des informations du serveur de noms esclave de la zone. Les valeurs typiques se situent entre 3 heures (10800) et 24 heures (86400).
  • La valeur retry définit le temps d’attente avant une deuxième tentative lorsque le serveur de noms esclave n’arrive pas à contacter le serveur maître pour rafraîchir les informations. Les valeurs typiques se situent entre 10 minutes (600) et 60 minutes (3600).
  • La valeur expiry définit le laps de temps au bout duquel les enregistrements de zone sont considérés comme ne faisant plus autorité. On choisira une valeur assez élevée, située entre une semaine (604800) à trois semaines (1814400).
  • La valeur minimum définit le laps de temps durant lequel des réponses négatives (NXDOMAIN) peuvent être gardées en cache par le serveur de noms esclave. Cette valeur se situera entre 0 et 3 heures (10800).
  • L’enregistrement NS (NS Resource Record) définit le ou les serveurs de noms pour le domaine ou la zone.
  • L’enregistrement A (A Resource Record) définit l’adresse IPv4 d’un hôte du domaine ou de la zone.

Vérifier la définition correcte de la zone.

# named-checkzone slackbox.fr /var/named/zone.slackbox.fr
zone slackbox.fr/IN: loaded serial 2017041701
OK

À chaque fois que l’on modifie le fichier de zone, on doit obligatoirement incrémenter le numéro de série. Ne pas oublier de redémarrer BIND après chaque modification.

# systemctl restart named

Dans l’interface de gestion de BookMyName.com (entrée de menu Gérer), il faudra indiquer qu’on gère nous-mêmes notre propre DNS. Pour ce faire, cliquer sur le nom de domaine dans la liste des noms de domaine, puis sur Modifier dans l’entrée de menu Vos DNS. Notez que dans la deuxième ligne, l’adresse IP correspondant à nssec.online.net est facultative.

DNS secondaire

La présence d’un serveur DNS secondaire est nécessaire pour les noms de domaine en .fr. Ce n’est pas la peine de louer un deuxième serveur, Online met gracieusement un DNS secondaire à disposition.

Dans la console Online, afficher les données du serveur. Dans le menu à gauche, cliquer sur DNS secondaires et définir une nouvelle entrée.

Éditer /etc/named.conf/local et autoriser le transfert de la zone vers le DNS secondaire d’Online.

// /etc/named.conf/local 
...
zone "slackbox.fr" {
  type master;
  allow-transfer { 62.210.16.8; }; 
  file "zone.slackbox.fr";
};

Reverse DNS

Il ne reste plus qu’à configurer les reverse DNS. Pour une configuration correcte du serveur, il faut que son adresse IP pointe vers le résultat de la commande hostname --fqdn. En l’occurrence, nous devons faire pointer 195.154.65.130 vers sd-41893.dedibox.fr. Là aussi, il faut se rendre dans la console Online > Liste de vos serveurs > Serveur > Réseau > Modifier les reverses et fournir le nom d’hôte souhaité. Pour la prise en compte des modifications, il faudra patienter un peu.

BIND et SELinux (2)

Vérifions à nouveau si notre configuration fonctionne bien avec SELinux.

# sealert -a /var/log/audit/audit.log
100% done
found 0 alerts in /var/log/audit/audit.log

On notera au passage que named.conf.local a été créé d’emblée avec le contexte de sécurité etc_t tout comme named.conf.

À partir de là, on peut sereinement réactiver SELinux en mode Strict.

# setenforce 1

Quelques vérifications

Voici une série de commandes pour tester la configuration correcte d’un domaine.

1. Configuration du DNS

# host slackbox.fr
slackbox.fr has address 195.154.65.130
slackbox.fr mail is handled by 10 mail.slackbox.fr.

2. Configuration du reverse DNS

# host 195.154.65.130
130.65.154.195.in-addr.arpa domain name pointer sd-41893.dedibox.fr.

3. Nom d’hôte du serveur mail

# host -t MX slackbox.fr
slackbox.fr mail is handled by 10 mail.slackbox.fr.

4. Adresse IP du serveur mail.

# host mail.slackbox.fr
mail.slackbox.fr has address 195.154.65.130

Téléchargement

Des modèles de fichiers named.conf, named.conf.local et zone.exemple.fr sont disponibles dans mon dépôt Github, dans le répertoire el7/bind.

$ git clone https://github.com/kikinovak/centos
Publié dans CentOS, Documentation Microlinux | Marqué avec , , | Laisser un commentaire

Synchronisation OwnCloud sous CentOS 7 et KDE

OwnCloudJe viens d’installer CentOS 7 avec un bureau KDE 4.14.8 sur mon ordinateur portable ASUS S300. Dans cet article, je décris la synchronisation de cet environnement de travail avec un stockage en réseau OwnCloud.

CentOS et RHEL disposent d’un client OwnCloud dans les dépôts EPEL, mais celui-ci n’est pas à jour. Les développeurs de OwnCloud maintiennent un dépôt de téléchargement pour RHEL/CentOS 7, qui permet d’obtenir la dernière version du client. Sur la page du projet OwnCloud, suivre le lien Get your OwnCloud, puis les boutons successifs Desktop Clients > Linux > CentOS > RHEL. Rapatrier le fichier isv:ownCloud:desktop.repo. On pourra éventuellement le renommer en owncloud-client.repo et l’éditer un peu. Pour ma part, j’ai modifié le nom du dépôt pour avoir quelque chose de plus lisible, et j’ai défini une priorité de 10 pour éviter un quelconque écrasement des paquets de base de CentOS.

[owncloud-client]
name=OwnCloud Desktop Client (RHEL 7)
...
enabled=1
priority=10

À partir de là, on peut installer le paquet owncloud-client dans sa dernière version. Lancer le client et fournir les paramètres de connexion.

OwnCloud Client

Effectuer la synchronisation initiale avec le serveur distant.

OwnCloud Client

Sur le portable, le gestionnaire de mots de passe Kwallet se lance automatiquement au démarrage de la session à cause de la connexion sans fil préconfigurée. Or, si Kwallet ne se lance pas pour une raison ou pour une autre – par exemple sur une station de travail – il faudra utiliser une astuce, faute de quoi le client OwnCloud s’obstinera à redemander le mot de passe de connexion au démarrage de la session.

Ouvrir la Configuration du système dans KDE, puis Démarrage et arrêt. Dans Fichier Bureau, mettre en surbrillance la ligne ownCloud et cliquer sur Propriétés.

owncloud-kwallet

L’onglet Application permet de modifier la commande qui lance le client, et c’est précisément ce que nous allons faire.

/usr/bin/kwalletd 2> /dev/null ; /usr/bin/owncloud

À partir de là, il suffira de fournir le mot de passe maître à Kwallet au démarrage de la session.

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