Créer un site web responsive avec WordPress et Zerif Lite

Cet article décrit la création d’un site web professionnel basé sur WordPress et le thème Zerif Lite, un thème adaptatif extrêmement populaire. L’avantage d’un tel thème adaptatif (responsive design), c’est qu’il s’affiche correctement sur tous les types de supports : moniteurs d’ordinateur, smartphones, tablettes, etc. Sans oublier le fait que depuis quelque temps, les sites qui ne se conforment pas à ces exigences sont pénalisés par Google.

Installation de Zerif Lite

Au moment de la rédaction de ces lignes, Zerif Lite est banni du catalogue officiel des thèmes WordPress pour une histoire de non-conformité du code. En attendant que les développeurs règlent leurs embrouilles, nous allons télécharger Zerif Lite sur le site ThemeIsle. Le fichier zerif-lite.zip pèse près de 3 Mo.

Avant d’installer le thème, il faudra éventuellement vérifier la valeur de la variable upload_max_filesize dans php.ini. Dans la configuration par défaut de Slackware, les fichiers en upload ne peuvent pas dépasser 2 Mo.

; php.ini
...
; Maximum allowed size for uploaded files.
; http://php.net/upload-max-filesize
upload_max_filesize = 4M

Installer le thème : Apparence > Thèmes > Ajouter > Mettre un thème en ligne > Parcourir > Sélectionner > Installer.

L’activation du thème nécessite l’installation du plug-in Pirate Forms. Cliquer sur Commencer l’installation de l’extension, puis installer et activer le plug-in en question.

Éventuellement, on peut supprimer la panoplie de thèmes installés par défaut en cliquant à chaque fois sur Détails du thème > Supprimer.

Voilà comment se présente la page des Thèmes de notre installation.

Configurer Zerif Lite

La configuration de Zerif Lite passe principalement par l’outil de personnalisation accessible via Apparence > Personnaliser. Alternativement, on peut utiliser le bouton Personnalisez votre site sur la page d’accueil du Tableau de bord. Quand on débute avec ce genre de thème professionnel, on peut facilement éprouver la nausée devant l’abondance des options et se sentir intimidé par le côté « usine à gaz » de l’interface de configuration. Pour ma part, j’ai passé pas moins de trois jours à faire le tour des fonctionnalités et du potentiel de peaufinage de ce thème.

Je ne vais mentionner ici que les points qui me semblent importants. Si vous souhaitez en savoir (beaucoup) plus, allez jeter un oeil sur la documentation officielle du thème.

Le principe d’un site responsive professionnel, c’est que les infos principales de votre entreprise sont toutes concentrées sur une page d’accueil unique subdivisée en une série de sections (Objectifs, À propos, Notre Équipe, Témoignages, Contact, News) accessibles via des ancres prédéfinies (#focus, #aboutus, #team, #testimonials, #contact, #latestnews). Cette page unique fera office de « vitrine » pour un site qui, par ailleurs, pourra être organisé comme n’importe quel CMS, avec des articles de blog, des pages statiques organisées de manière hiérarchique, etc.

Identité du site

Le thème Zerif Lite est livré avec du contenu « bidon » que l’on va remplacer progressivement avec notre contenu à nous. Ouvrir Apparence > Personnaliser > Identité du site et définir le titre, par exemple :

  • Titre du site : Microlinux
  • Slogan : Solutions informatiques durables

Le logo par défaut a une taille de 109×32 pixels. J’adapte le logo existant de mon entreprise en le découpant et en le redimensionnant, et il s’insère très bien malgré une taille plus importante de 268×32 pixels. Au moment d’insérer le logo – et plus généralement les images dans mon site – je veille à bien renseigner les champs Titre et Texte Alternatif pour bien référencer les images.

L’icône du site doit avoir une taille de 512×512 pixels. Étant donné que mon logo est rectangulaire et pas carré, je modifie l’image avec GIMP en augmentant la taille du canevas afin qu’elle soit parfaitement carrée.

Options générales

Dans les Options Générales > Général, je désactive le défilement doux (smooth scrolling), qui semble poser des problèmes avec certains navigateurs. J’indique également les mentions légales du site.

Dans les Icônes sociaux du pied, j’indique le lien vers les comptes Facebook et Twitter de l’entreprise. À partir du moment où un champ est vide, le lien correspondant ne s’affiche pas.

Enfin, le champ Contenu du pied me permet de renseigner l’adresse, le mail et le téléphone de l’entreprise.

Peaufiner le pied de page

La version gratuite du thème Zerif Lite arbore la mention Zerif Lite Fièrement propulsé par WordPress dans le pied de page juste en-dessous des mentions légales du site. La version professionnelle payante du thème permet de supprimer cette mention. Ou alors on a recours à une astuce de CSS.

Le plug-in Web Developer pour Firefox contient un Inspecteur, qui permet entre autres choses d’identifier les différents éléments CSS d’une page. Ouvrir l’Inspecteur via Outils > Développement web > Inspecteur, afficher la page et cliquer sur l’élément que l’on souhaite identifier. La colonne de droite de l’inspecteur affiche le code CSS de l’élément en question.

Dans le cas présent, c’est la classe CSS zerif-copyright-box qu’il faut modifier. Ouvrir la section CSS additionnel dans l’outil de personnalisation et ajouter le code CSS suivant :

.zerif-copyright-box {
  display: none;
}

Voici comment se présente le pied de page après modification :

Section de gros titre et image d’arrière-plan

La section Gros titre contient le titre principal du site – celui qui s’affiche au milieu de la page – ainsi que deux boutons d’action, un rouge et un vert. Pour mon entreprise, ce sera quelque chose comme ceci :

  • Titre : Solutions informatiques durables
  • Bouton rouge : Nos prestations
  • Bouton vert : Pourquoi Linux ?

Dans la configuration par défaut, le titre s’affiche en majuscules. Je souhaite l’afficher en caractères normaux, je lance donc l’Inspecteur de Firefox, et j’identifie la classe CSS intro-text. Je modifie le CSS comme ceci :

.intro-text {
  text-transform: none;
}

Le bouton rouge Nos prestations est censé renvoyer vers la section Objectifs, grâce à l’ancre #focus. Quant au bouton vert Pourquoi Linux, je vais faire un léger abus de la section À propos et utiliser sa présentation à d’autres fins. Le lien ira donc vers l’ancre #aboutus.

Pour l’image de fond (Apparence > Personnaliser > Image d’arrière-plan) je choisis une image généreusement dimensionnée de 4288×2730 pixels, et qui s’insère bien dans le thème général. Là aussi, je n’oublie pas de fournir un titre et un texte alternatif. Dans les pré-réglages de l’image, j’opte pour Remplir l’écran.

Notons enfin que l’Effet Parallax relève plutôt de la catégorie farces et attrapes. Il est désactivé dans la configuration par défaut, et nous n’allons pas y toucher.

La section Objectifs

Une vue d’ensemble sur les prestations de l’entreprise sera présentée dans la section Notre objectif. Dans la configuration par défaut, cette section comporte un titre et un sous-titre ainsi que quatre widgets prédéfinis. On va adapter tout cela à nos besoins.

  • Titre : Nos prestations
  • Sous-titre : Tout ce que Microlinux peut faire pour vous

Comme dans la section Gros titre, le titre de cette section est transformé en majuscules. Pour obtenir une typographie normale, il faut ajouter une stance au code CSS :

.section-header h2 {
  text-transform: none;
}

Chaque widget est composé d’un titre, d’un texte bref, d’un lien et d’une image. L’idéal, c’est d’utiliser des icônes d’une taille de 96×96 pixels pour illustrer les widgets. Les liens respectifs pointeront vers une série de pages statiques que nous devrons encore rédiger.

La section À propos

J’utiliserai cette section de manière un peu abusive, pour présenter non pas ma personne, mais les avantages de Linux, le système d’exploitation déployé par mon entreprise. Étant donné que la question revient très souvent, j’ai décidé de la mettre en lumière ici. D’une part, la section À propos est subdivisé en quatre zones de texte.

  • Titre
  • Sous-titre
  • Gros titre à gauche
  • Texte

D’autre part, la zone permet de définir des fonctionnalités. Chacune de ces fonctionnalités comporte un titre et une zone de texte, ainsi qu’un champ Pourcentage qui est censé renseigner le visiteur sur le degré de maîtrise de telle ou telle compétence. Il suffit de supprimer le contenu de ce champ (ou de définir une valeur nulle) pour que celui-ci ne s’affiche plus sur le site.

La section Témoignages

Comme son nom l’indique, cette section permet d’afficher des témoignages de clients satisfaits. La section comporte un titre et un sous-titre ainsi qu’une série de widgets personnalisables. On pourra faire l’économie du lien vers l’auteur et de l’image en guise d’avatar pour ne renseigner que les seuls champs Auteur, Détails de l’auteur et Texte. Un détail plaisant, c’est que le nom d’auteur apparaît en écriture « manuscrite » sur le site.

La section Nouveautés

Pas grand-chose à paramétrer dans cette section, hormis le titre et le sous-titre, étant donné qu’elle est censée renvoyer vers les pages de blog (c’est-à-dire les articles) du site. La configuration s’effectuera au niveau des articles.

Une fois qu’on a alimenté le blog d’une série d’articles, voilà comment ça se présente au niveau de la section Nouveautés. Cette présentation peut être considérablement améliorée.

Chaque article offre la possibilité de définir une image à la une. C’est elle qui s’affichera dans la section Nouveautés. Là encore, l’idéal est de trouver une icône d’une taille de 96×96 pixels. Ce n’est pas grave si les dimensions ne correspondent pas tout à fait, on a un peu de marge.

D’autre part, l’extrait de texte affiché par défaut peut être personnalisé. Afficher l’interface de modification des articles, déplier le menu Options de l’écran en haut à droite  et cocher la case Extrait. Dorénavant, un nouveau champ sous l’article permet de définir un extrait personnalisé, qui s’affichera sur la page des Nouveautés.

Améliorer l’aspect des pages

L’aspect des pages et des articles peut être amélioré avec un petit coup de CSS. Dans la configuration par défaut, la police par défaut est un petit peu trop petite, et l’espace entre les paragraphes est trop important, alors que les lignes sont plutôt serrées. Pour arranger ça, on va ajouter la stance CSS suivante.

.site-main p, li, a, em, strong {
  margin: 0 0 8px;
  font-size: 18px;
  line-height: 130%;
}

Le champ Commentaires des articles n’est pas très joli à voir. Il peut être amélioré grâce à l’extension Jetpack. Cette extension offre une multitude de fonctionnalités, mais pour l’instant, on n’utilisera que la seule personnalisation de la zone de commentaires. Installer et activer cette extension, en établissant la connexion à un compte WordPress (offre gratuite), et sans activer les fonctionnalités recommandées. Ensuite, activer les commentaires personnalisés via Tableau de bord > Jetpack > Réglages > Engagement > Commentaires.

La barre latérale des pages et des articles est assez chargée dans la configuration. Elle contient un champ de recherche, une liste d’articles et de commentaires récents, une série de liens vers les archives, la liste des catégories, et autres choses encore. On va opter pour une configuration épurée et garder le seul champ de recherche, en supprimant tout le reste.

Ouvrez Tableau de bord > Apparence > Widgets et repérez le widget Colonne latérale. Supprimez les widgets Articles récents, Commentaires récents, Archives, Catégories et Méta en les faisant glisser vers le côté gauche de l’interface. Nous ne conserverons que le seul widget Rechercher.

Configurer le menu de navigation

Dans la configuration par défaut, le menu de navigation en haut à droite de l’écran ne comporte qu’une seule entrée qui pointe vers la page d’exemple. La personnalisation du menu passe par Apparence > Menus.

Choisir un nom pour le menu personnalisé (par exemple Microlinux ou tout simplement Menu) et cliquer sur Créer le menu. Supprimer les widgets Accueil et Page d’exemple en les dépliant successivement et en cliquant sur Retirer. Dans la colonne de gauche, l’option Liens personnalisés nous servira à créer les entrées de menu. Saisir l’URL et le texte du lien et cliquer sur Ajouter au menu.

Une fois qu’on a créé le menu personnalisé, ouvrir l’onglet Gérer les emplacements et sélectionner Menu principal > Microlinux.

 

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

Hébergement WordPress sous Slackware

Cet article décrit l’installation du moteur de blog WordPress sur un serveur Slackware. WordPress est le CMS (Content Management System) ou SGC (Système de Gestion de Contenu) le plus utilisé au monde. Actuellement, près de 27 % des sites web dans le monde utilisent WordPress d’après les statistiques de W3Techs.com.

Prérequis

Installation

Créer la base de données :

# mysql -u root -p
mysql> create database wordpress;
mysql> grant all on wordpress.* to wordpressuser@localhost
    -> identified by '********'; 
mysql> flush privileges;
myslq> quit;
Bye

Télécharger WordPress sur le site de l’éditeur :

# cd ~/webapps/wordpress
# links fr.wordpress.org

Suivre les liens Téléchargement > Télécharger au format .tar.gz. Télécharger l’application et quitter Links.

L’hôte virtuel se situera dans /var/www/vhosts/slackbox-wordpress/htdocs. Créer le répertoire parent, décompresser l’archive téléchargée à l’intérieur de ce répertoire et renommer le répertoire wordpress/ résultant en htdocs/ :

# mkdir -p /var/www/vhosts/slackbox-wordpress
# cd /var/www/vhosts/slackbox-wordpress
# tar xvzf /root/webapps/wordpress/wordpress-4.7.2-fr_FR.tar.gz
# mv wordpress htdocs

Régler les droits d’accès et les permissions de fichiers :

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

Créer un hôte virtuel, comme ceci par exemple :

# /etc/httpd/extra/https-ssl.conf
...
# https://wordpress.slackbox.fr
<VirtualHost 195.154.65.130:443>
# HSTS
Header always set Strict-Transport-Security \
  "max-age=63072000; includeSubDomains"
DocumentRoot "/srv/httpd/vhosts/slackbox-wordpress/htdocs"
ServerName wordpress.slackbox.fr:443
ServerAdmin info@microlinux.fr
ErrorLog "/var/log/httpd/wordpress.slackbox.fr-error_log"
TransferLog "/var/log/httpd/wordpress.slackbox.fr-access_log"
SSLEngine on
SSLCertificateFile "/chemin/vers/cert.pem"
SSLCertificateKeyFile "/chemin/vers/privkey.pem"
SSLCertificateChainFile "/chemin/vers/chain.pem"
<FilesMatch "\.(cgi|shtml|phtml|php)$">
    SSLOptions +StdEnvVars
</FilesMatch>
BrowserMatch "MSIE [2-5]" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0
CustomLog "/var/log/httpd/ssl_request_log" \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>

En passant, on peut définir une redirection pour que toutes les connexions se fassent en HTTPS, c’est plus propre :

# /etc/httpd/extra/httpd-vhosts.conf
...
# Redirection HTTPS pour wordpress.slackbox.fr
<VirtualHost *:80>
    ServerName wordpress.slackbox.fr
    Redirect / https://wordpress.slackbox.fr
</VirtualHost>

Redémarrer Apache :

# /etc/rc.d/rc.httpd restart

Pointer le navigateur sur l’URL de l’application et suivre les instructions de l’installateur.

La prochaine étape consiste à choisir un titre et à définir un rédacteur principal pour le site.

L’installation est terminée, et on se retrouve dans le Tableau de bord.

Configurer Apache pour les permaliens personnalisés

Dans sa configuration par défaut, WordPress utilise un format de liens du style https://wordpress.slackbox.fr/?p=123. On va préférer un format du genre https://zerif.slackbox.fr/exemple-article/. Dans le Tableau de bord, aller dans Réglages > Permaliens et sélectionner Nom de l’article.

Le problème, c’est qu’à partir de là, les pages ne s’affichent plus :

L’utilisation des permaliens personnalisés de WordPress nécessite de reconfigurer Apache. Dans un premier temps, nous allons activer le module mod_rewrite en décommentant la ligne correspondante dans /etc/httpd/httpd.conf.

#LoadModule userdir_module lib64/httpd/modules/mod_userdir.so
LoadModule alias_module lib64/httpd/modules/mod_alias.so
LoadModule rewrite_module lib64/httpd/modules/mod_rewrite.so

WordPress a créé un fichier .htaccess à la racine de l’installation. Voici à quoi il ressemble :

# cat /var/www/vhosts/slackbox-wordpress/htdocs/.htaccess
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

Le contenu de ce fichier devra être transféré dans la configuration de notre hôte virtuel :

# /etc/httpd/extra/https-ssl.conf
...
# https://wordpress.slackbox.fr
<VirtualHost 195.154.65.130:443>
Header always set Strict-Transport-Security \
 "max-age=63072000; includeSubDomains"
DocumentRoot "/srv/httpd/vhosts/slackbox-wordpress/htdocs"
ServerName wordpress.slackbox.fr:443
ServerAdmin info@microlinux.fr
<Directory "/srv/httpd/vhosts/slackbox-wordpress/htdocs">
  <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
  </IfModule>
</Directory>
ErrorLog "/var/log/httpd/wordpress.slackbox.fr-error_log"
TransferLog "/var/log/httpd/wordpress.slackbox.fr-access_log"
...

Redémarrer Apache pour prendre en compte les modifications. Dorénavant, les pages s’affichent correctement avec les permaliens personnalisés.

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

Accéder rapidement aux partages Samba depuis Windows

Je configure assez souvent des partages Samba sous Linux pour des clients tournant sous Windows. Une question qui revient régulièrement, c’est la création d’un accès rapide à ces partages. Voici donc un petit descriptif illustré pour un poste client tournant sous Windows 7 64-bits.

Prenons comme exemple le dossier Marketing qui se situe sur le serveur NESTOR dans le partage Public.

Créez un raccourci en effectuant un clic droit sur le fichier, puis en optant pour Créer un raccourci.

Faites glisser ce raccourci vers le Bureau.

Enfin, renommez le raccourci à votre convenance et supprimez le raccourci initial.

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

Hébergement ERP/CRM Dolibarr sous Slackware

Cet article décrit l’installation et la maintenance de Dolibarr sur un serveur Slackware. Dolibarr est un ERP/CRM (Enterprise Resource Planing & Customer Relationship Management) libre qui permet aux entreprises, aux associations ou aux micro-entrepreneurs, de gérer une activité professionnelle ou associative : contacts, factures, commandes, stocks, agenda, etc.

Prérequis

Dans l’exemple ci-dessous, nous installerons Dolibarr sur un serveur dédié. Il nous faut donc :

Installation

Créer la base de données :

# mysql -u root -p
mysql> create database dolibarr;
mysql> grant all on dolibarr.* to dolibarruser@localhost
    -> identified by '********'; 
mysql> flush privileges;
myslq> quit;
Bye 

Télécharger Dolibarr sur le site de l’éditeur :

# cd ~/webapps/dolibarr
# links http://www.dolibarr.fr

Suivre les liens Téléchargements > Espace téléchargement Sourceforge > Files > Dolibarr ERP-CRM > 4.0.3 > dolibarr-4.0.3.tgz > direct link > Enregistrer > OK.

Quitter Links et décompresser l’archive téléchargée à la racine des hôtes virtuels :

# cd /var/www/vhosts
# tar xvzf /root/webapps/dolibarr/dolibarr-4.0.3.tgz

Renommer en fonction de l’hébergement :

# mv dolibarr-4.0.3 slackbox-dolibarr

Régler les droits d’accès et les permissions de fichiers :

# chown -R apache:apache slackbox-dolibarr/
# find slackbox-dolibarr/ -type d -exec chmod 0750 \{} \;
# find slackbox-dolibarr/ -type f -exec chmod 0640 \{} \;

Créer un fichier de configuration vide :

# cd slackbox-dolibarr
# touch htdocs/conf/conf.php

Définir les permissions de ce fichier :

# chown apache:apache htdocs/conf/conf.php
# chmod 0640 htdocs/conf/conf.php

Créer le répertoire qui servira aux documents générés ou stockés par Dolibarr. Attention, il doit bien être à l’extérieur de l’arborescence du site, pour des raisons de sécurité évidentes :

# mkdir documents

Définir les permissions du répertoire :

# chown -R apache:apache documents/
# chmod 0750 documents/

Créer un hôte virtuel, comme ceci par exemple :

# /etc/httpd/extra/https-ssl.conf
...
# https://compta.slackbox.fr
<VirtualHost 195.154.65.130:443>
# HSTS
Header always set Strict-Transport-Security \
  "max-age=63072000; includeSubDomains"
DocumentRoot "/srv/httpd/vhosts/slackbox-dolibarr/htdocs"
ServerName compta.slackbox.fr:443
ServerAdmin info@microlinux.fr
ErrorLog "/var/log/httpd/compta.slackbox.fr-error_log"
TransferLog "/var/log/httpd/compta.slackbox.fr-access_log"
SSLEngine on
SSLCertificateFile "/chemin/vers/cert.pem"
SSLCertificateKeyFile "/chemin/vers/privkey.pem"
SSLCertificateChainFile "/chemin/vers/chain.pem"
<FilesMatch "\.(cgi|shtml|phtml|php)$">
    SSLOptions +StdEnvVars
</FilesMatch>
BrowserMatch "MSIE [2-5]" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0
CustomLog "/var/log/httpd/ssl_request_log" \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>    

En passant, on peut définir une redirection pour que toutes les connexions se fassent en HTTPS, c’est plus propre :

# /etc/httpd/extra/httpd-vhosts.conf
...
# Redirection HTTPS pour compta.slackbox.fr
<VirtualHost *:80>
    ServerName compta.slackbox.fr
    Redirect / https://compta.slackbox.fr
</VirtualHost>

Redémarrer Apache :

# /etc/rc.d/rc.httpd restart

Pointer le navigateur sur l’URL de l’application et suivre les instructions de l’installateur. Je ne fournis pas ici d’instructions détaillées, je relève juste sommairement les étapes de l’installation :

  1. Sélectionner la langue (French).
  2. Vérifier si tous les prérequis techniques sont remplis.
  3. Vérifier les chemins d’accès vers le site et les documents.
  4. Cocher Forcer les connexions sécurisées (HTTPS).
  5. Saisir l’identifiant et le mot de passe de l’utilisateur MySQL.
  6. Définir un identifiant et un mot de passe pour l’utilisateur Dolibarr.

Une fois l’installation terminée, on peut la verrouiller comme ceci :

# cd /var/www/vhosts/slackbox-dolibarr/documents
# touch install.lock
# chown apache:apache install.lock
# chmod 0440 install.lock

Accéder à l’interface d’administration et procéder à la configuration de base. Saisir au minimum le nom de la société et le pays où elle est implantée, et activer les modules dont on a besoin. Voici comment se présente notre application :

Mise à jour

Vérifier si l’installation existante comporte un fichier install.lock et supprimer ce fichier le cas échéant.

# cd /var/www/vhosts/slackbox-dolibarr/documents
# rm install.lock

Récupérer la dernière version de Dolibarr :

# cd ~/webapps/dolibarr
# links http://www.dolibarr.fr

Là encore, suivre les liens Téléchargements > Espace téléchargement Sourceforge > Files > Dolibarr ERP-CRM > 4.0.4 > dolibarr-4.0.4.tgz > direct link > Enregistrer > OK.

Quitter Links et décompresser l’archive téléchargée à la racine des hôtes virtuels :

# cd /var/www/vhosts
# tar xvzf  /root/webapps/dolibarr/dolibarr-4.0.4.tgz

Recopier les nouveaux fichiers dans le répertoire dolibarr-x.y.z vers le répertoire contenant l’ancienne version de Dolibarr. Ceci a pour effet de remplacer les anciens fichiers par les nouveaux, tout en conservant les fichiers qui sont spécifiques à l’installation, comme le fichier conf.php ou encore les modules complémentaires installés. Au cas où la commande cp comporte un alias vers cp -i, on utilisera l’astuce suivante pour éviter la confirmation pour chaque fichier :

# scp -r dolibarr-x.y.z/* slackbox-dolibarr/

À partir de là, on pourra supprimer l’arborescence initiale :

# rm -rf dolibarr-x.y.z/

Régler les droits d’accès et les permissions de fichiers :

# chown -R apache:apache slackbox-dolibarr/
# find slackbox-dolibarr/ -type d -exec chmod 0750 \{} \;
# find slackbox-dolibarr/ -type f -exec chmod 0640 \{} \;

Pointer le navigateur sur la page d’installation, dans le sous-répertoire install :

  • https://chemin_vers_dolibarr/install/

Choisir Mise à jour dans le menu proposé, en respectant les versions intermédiaires, et lancer les étapes de migration successives. Une fois la mise à jour terminée, verrouiller le répertoire d’installation :

# touch documents/install.lock
# chown apache:apache documents/install.lock
# chmod 0440 documents/install.lock

Vérifier les droits d’accès du fichier de configuration et les modifier le cas échéant :

# chmod 0440 htdocs/conf/conf.php

Installer le module Multi-société

Créer un répertoire custom qui contiendra les modules tiers :

# mkdir htdocs/custom

Éditer le fichier htdocs/conf/conf.php et définir le chemin vers les modules.
Il suffira éventuellement de décommenter les deux lignes correspondantes :

$dolibarr_main_url_root='http://myserver';
$dolibarr_main_document_root='/path/of/dolibarr/htdocs';
$dolibarr_main_url_root_alt='http://myserver/custom';
$dolibarr_main_document_root_alt='/path/of/dolibarr/htdocs/custom';
...

Décompresser le module :

# unzip module_multicompany_3.4.0.zip

Déplacer l’arborescence résultante vers l’endroit approprié :

# mv multicompany/ chemin_vers_dolibarr/htdocs/custom/

Régler les droits d’accès :

# chown -R apache:apache chemin_vers_dolibarr/htdocs/custom/

Élargir la colonne des libellés

Lorsqu’on affiche la liste des Produits ou des Services, la colonne Libellé n’est pas assez large pour afficher certains produits dont la dénomination est plus longue. Pour remédier à cela, on peut aller dans htdocs/product et éditer le fichier list.php, en remplaçant la valeur maximale 40 par une valeur supérieure, comme ceci par exemple :

// Label
if (! empty($arrayfields['p.label']['checked']))
{
print '<td>'.dol_trunc($objp->label,60).'</td>';
}
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-sept. Les dépendances sont toutes disponibles sur SlackBuilds.org.

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

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

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.

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/www.slackbox.fr/
# letsencrypt revoke --cert-path cert.pem

 

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

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

Cet article décrit la mise en place d’un hébergement sécurisé sur un serveur Apache tournant sous Slackware. 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://www.slackbox.fr.

Prérequis

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

Configurer Apache et SSL

Notre hébergement HTTPS sera rangé en-dessous de /srv/httpd/vhosts comme nos hôtes virtuels HTTP. Éditer le fichier /etc/httpd/extra/httpd-ssl.conf. La version par défaut de ce fichier est amplement commentée. Je ne reproduis ici que les directives sans les commentaires :

# /etc/httpd/extra/httpd-ssl.conf
Listen 443
SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4
SSLProxyCipherSuite HIGH:MEDIUM:!MD5:!RC4
SSLHonorCipherOrder on
SSLProtocol all -SSLv3
SSLProxyProtocol all -SSLv3
SSLPassPhraseDialog  builtin
SSLSessionCache        "shmcb:/var/run/ssl_scache(512000)"
SSLSessionCacheTimeout  300

# https://www.slackbox.fr
<VirtualHost 195.154.65.130:443>
DocumentRoot "/srv/httpd/vhosts/slackbox-secure/htdocs"
ServerName www.slackbox.fr:443
ServerAdmin info@microlinux.fr
ErrorLog "/var/log/httpd/www.slackbox.fr-error_log"
TransferLog "/var/log/httpd/www.slackbox.fr-access_log"
SSLEngine on
SSLCertificateFile "/chemin/vers/cert.pem"
SSLCertificateKeyFile "/chemin/vers/privkey.pem"
SSLCertificateChainFile "/chemin/vers/chain.pem"
<FilesMatch "\.(cgi|shtml|phtml|php)$">
    SSLOptions +StdEnvVars
</FilesMatch>
BrowserMatch "MSIE [2-5]" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0
CustomLog "/var/log/httpd/www.slackbox.fr-ssl_request_log" \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>

Activer SSL dans la configuration d’Apache :

# /etc/httpd/httpd.conf
...
LoadModule .../modules/mod_socache_shmcb.so
...
LoadModule ssl_module lib64/httpd/modules/mod_ssl.so
...
# Secure (SSL/TLS) connections
Include /etc/httpd/extra/httpd-ssl.conf
...
  • L’astuce consiste ici à faire une recherche sur la chaîne de caractères « ssl » pour éditer le fichier.

Redémarrer Apache :

# /etc/rc.d/rc.httpd restart

Ouvrir notre site sécurisé :

Effectuer un audit de la sécurité de notre hébergement sur le site Qualys SSL Labs :

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 195.154.65.130:443>
# HSTS
Header always set Strict-Transport-Security \
  "max-age=63072000; includeSubDomains"
...
</VirtualHost>

Refaire un audit de sécurité :

Plusieurs hébergements SSL sur un même serveur

Les versions récentes d’Apache supportent plusieurs hébergements sécurisés grâce aux hôtes virtuels. Le fonctionnement est le même que pour les hôtes virtuels classiques, au détail près que les hôtes virtuels sécurisés seront également définis dans /etc/httpd/extra/httpd-ssl.conf. Bien évidemment, chaque hôte virtuel devra disposer de son propre certificat.

Sur les anciennes versions d’Apache, il fallait ajouter une option générale pour la configuration des hôtes virtuels sécurisés :

# /etc/httpd/extra/httpd-ssl.conf 
...
Listen 443
SSLStrictSNIVHostCheck off
...
Publié dans Documentation Microlinux, Slackware | Marqué avec , , , , , | Laisser un commentaire

Installer un serveur de réseau local Slackware 14.2

Cet article décrit l’installation de Slackware Linux 14.2 sur un serveur de réseau local comme par exemple le HP Proliant Microserver. Ce modèle de serveur ne contient pas de lecteur optique. Il faut donc confectionner une clé USB bootable au préalable.

Démarrer sur le support d’installation

Options de démarrage :

  • huge.s (64-bit)
  • hugesmp.s (32-bit)
  • vga=788 (affichage 800×600)
  • vga=791 (affichage 1024×768)

Choix du clavier : azerty/fr-latin1.map pour un clavier AZERTY français.

Faire le ménage sur les disques

Avant de faire quoi que ce soit, désactiver d’éventuels vestiges d’assemblages RAID provenant d’une installation antérieure :

# mdadm --stop --scan

Effacer les métadonnées RAID persistantes sur les partitions, comme ceci par exemple :

# mdadm --zero-superblock /dev/sda1
# mdadm --zero-superblock /dev/sda2
# mdadm --zero-superblock /dev/sda3
# mdadm --zero-superblock /dev/sdb1
# mdadm --zero-superblock /dev/sdb2
# mdadm --zero-superblock /dev/sdb3
...

Remettre les tables de partitions à zéro :

# dd if=/dev/zero of=/dev/sda bs=512 count=64
# dd if=/dev/zero of=/dev/sdb bs=512 count=64

Partitionnement et définition des assemblages RAID

Partitionner les disques :

# cfdisk /dev/sdX

Schéma de partitionnement :

  • un disque RAID pour /boot, de 100 Mo, formaté en ext2
  • un disque RAID pour la partition swap, équivalent à la RAM disponible
  • un disque RAID pour /, formaté en ext4

Les partitions RAID sont de type FD (Linux raid autodetect).

Deux disques en RAID 1 :

# mdadm --create /dev/md1 --level=1 --raid-devices=2 \
  --metadata=0.90 /dev/sda1 /dev/sdb1
# mdadm --create /dev/md2 --level=1 --raid-devices=2 \
  --metadata=0.90 /dev/sda2 /dev/sdb2
# mdadm --create /dev/md3 --level=1 --raid-devices=2 \
  --metadata=0.90 /dev/sda3 /dev/sdb3

Quatre disques en RAID 5 :

# mdadm --create /dev/md1 --level=1 --raid-devices=4 \
  --metadata=0.90 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1
# mdadm --create /dev/md2 --level=1 --raid-devices=4 \
  --metadata=0.90 /dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdd2
# mdadm --create /dev/md3 --level=5 --raid-devices=4 \
  --metadata=0.90 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3
  • Les grappes /dev/md1 et /dev/md2 sont assemblées en RAID 1.
  • La grappe /dev/md3 est assemblée en RAID 5.

Formater la partition swap pour que l’installateur la reconnaisse :

# mkswap /dev/md2

Lancer l’installation

Démarrer le programme d’installation :

# setup
  • L’installateur proposera les disques RAID /dev/mdX au formatage.

Sélectionner les séries de paquets :

  • [*] A
  • [*] AP
  • [*] D
  • [ ] E (désélectionner)
  • [*] F
  • [*] K
  • [ ] KDE (désélectionner)
  • [ ] KDEI
  • [*] L
  • [*] N
  • [*] T
  • [*] TCL
  • [*] X
  • [ ] XAP (désélectionner)
  • [ ] XFCE (désélectionner)
  • [*] Y

Le groupe T est bizarrement nécessaire pour compiler le paquet ffmpeg dont on pourra éventuellement avoir besoin sur un serveur de flux audio.

SELECT PROMPTING MODE : full. Alternativement, le mode terse offre un résultat identique mais avec une présentation plus compacte.

MAKE USB FLASH BOOT : Skip making a USB boot stick

INSTALL LILO : Try to install LILO automatically

CONFIGURE LILO TO USE FRAME BUFFER CONSOLE : standard

Pour la résolution de la console et les paramètres à passer au kernel (prochain écran), on peut très bien ne rien mettre et peaufiner le tout en éditant /etc/lilo.conf plus tard.

OPTIONAL LILO append="" LINE : nomodeset quiet ipv6.disable=1

USE UTF-8 TEXT CONSOLE : Yes – UTF8 a beau avoir quelques petits problèmes
avec certains utilitaires en mode console, notamment avec des pages man en langue étrangère qui s’affichent mal, il n’empêche qu’il est dorénavant établi comme standard un peu partout. Le choix par défaut No s’explique uniquement par un excès de prudence de la part du distributeur.

SELECT LILO DESTINATION : MBR - Install to Master Boot Record

MOUSE CONFIGURATION : imps2- Microsoft PS/2 Intellimouse

La configuration de la souris ne concerne que son utilisation en mode console, avec GPM. On peut simplement accepter le choix par défaut, qui correspond à toutes les souris modernes.

GPM CONFIGURATION : No. Le service GPM permet de copier/coller du texte avec la souris en mode console. Étant donné que nous nous servons de Vim pour cela, nous décidons de ne pas le démarrer.

CONFIGURE NETWORK: Yes

ENTER HOSTNAME : il s’agit de choisir un nom d’hôte pour le serveur. Choisissez-en un à votre convenance et écrivez-le en minuscules, comme ceci :

  • slackbox
  • grossebertha
  • serveur-linux
  • etc.

ENTER DOMAINNAME FOR <machine> : choisissez un nom de domaine « en bois », comme par exemple :

  • local
  • microlinux.lan
  • crpconsulting.montpellier
  • etc.

CONFIGURATION TYPE FOR <machine.domaine> : static IP. Renseigner les paramètres réseau « côté Internet ».

SET DHCP HOSTNAME : Laisser vide tout simplement.

CONFIRM STARTUP SERVICES TO RUN :

  • [ ] rc.fuse (désélectionner)
  • [ ] rc.inetd (désélectionner)
  • [ ] rc.messagebus (désélectionner)
  • [*] rc.syslog
  • [*] rc.sshd

CONSOLE FONT CONFIGURATION : No

HARDWARE CLOCK SET TO UTC ? YES - Hardware clock is set to UTC

TIMEZONE CONFIGURATION : Europe/Paris

SELECT DEFAULT WINDOW MANAGER FOR X : xinitrc.twm

Le gestionnaire de fenêtres rudimentaire TWM est installé avec le groupe de paquets X. Même si nous le définissons comme environnement par défaut, nous ne l’utiliserons pas.

Définir un mot de passe pour root. On ne le verra pas apparaître à l’écran.

Ne pas redémarrer avant d’avoir configuré LILO pour le RAID, faute de quoi on plante le système !

Sortir de l’installateur (EXIT) et chrooter dans le système nouvellement installé :

# chroot /mnt

Construire l’initrd et configurer LILO

Sur un système en RAID 5, attendre la synchronisation complète de la grappe :

# watch cat /proc/mdstat

Cette astuce permet d’accélérer la synchronisation des disques de façon significative :

# echo 50000 > /proc/sys/dev/raid/speed_limit_min

Créer le fichier de configuration pour la grappe RAID :

# mdadm --examine --scan > /etc/mdadm.conf

Préparer l’initrd :

# cd /etc
# cp mkinitrd.conf.sample mkinitrd.conf

Détecter les modules nécessaires au démarrage :

# /usr/share/mkinitrd/mkinitrd_command_generator.sh

Éditer /etc/mkinitrd.conf en utilisant l’option :set nobackup de Vim :

# /etc/mkinitrd.conf
SOURCE_TREE="/boot/initrd-tree"
CLEAR_TREE="1"
OUTPUT_IMAGE="/boot/initrd.gz"
KERNEL_VERSION="$(uname -r)"
KEYMAP="fr-latin1"
MODULE_LIST="ext4"
ROOTDEV="/dev/md3"
ROOTFS="ext4"
RESUMEDEV="/dev/md2"
RAID="1"
LVM="0"
UDEV="1"
MODCONF="0"
WAIT="1"
  • Ici, RAID="1" ne désigne pas un quelconque niveau de RAID, mais signifie simplement que l’on utilise le RAID.

Il faudra éventuellement ajouter explicitement les modules pour le contrôleur de disques. Exemple sur un serveur IBM XServer 225 :

MODULE_LIST="ext4:mptbase:mptscsih:mptspi"

Générer l’initrd :

# mkinitrd -F

Éditer /etc/lilo.conf :

# /etc/lilo.conf 
...
append="nomodeset quiet vt.default_utf8=1 ipv6.disable=1"
boot=/dev/md1
compact
lba32
raid-extra-boot = mbr-only
...
timeout = 30
...
image = /boot/vmlinuz-generic-3.10.17
  initrd = /boot/initrd.gz
  root = /dev/md3
  label = MLES-14.1-64bit
  read-only

Là aussi, activer l’option :set nobackup dans Vim pour ne pas se retrouver avec une copie de sauvegarde lilo.conf~.

# lilo

On peut tranquillement ignorer le message d’erreur qui dit que « /dev/sdb n’est pas sur le premier disque » :o)

Quitter l’environnement chrooté et redémarrer :

# exit
# reboot

Premier redémarrage

Tester la connexion à Internet :

# ping -c 4 www.google.fr

Éventuellement, utiliser Links pour télécharger et installer le paquet user-settings-console sur le dépôt de Microlinux, dans le répertoire server-$VERSION-$ARCH/slackware{64}/profile :

# links http://www.microlinux.fr/microlinux/

Téléchargez le paquet user-settings-console (en utilisant la touche [D] comme Download dans le navigateur Links) et installez-le :

# installpkg user-settings-console-14.2-noarch-1_microlinux.txz 

Si l’on n’a pas accès au réseau au premier redémarrage, on peut éventuellement permuter l’affectation des interfaces réseau eth0 et eth1, en éditant /etc/udev/rules.d/70-persistent-net.rules.

Procéder à un réglage initial de l’horloge système :

# ntpdate pool.ntp.org

Télécharger les scripts Microlinux

Je fournis une collection de scripts et de fichiers de configuration prêts à l’emploi pour accélérer le processus d’installation. Récupérez toute cette arborescence en utilisant la commande suivante :

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

Configurer slackpkg

Dans la configuration par défaut, le gestionnaire de paquets slackpkg ne fonctionne qu’avec les dépôts officiels de Slackware. Nous devons installer le plugin slackpkg+ de Matteo Rossini pour activer l’utilisation de dépôts de paquets tiers. Microlinux vous évite la corvée en fournissant des paquets slackpkg+ préconfigurés pour l’utilisation des dépôts MLES.

Là encore, utilisez le navigateur Links pour accéder aux dépôts distants :

# links http://www.microlinux.fr/microlinux/

Téléchargez le paquet slackpkg+ dans le répertoire server-$VERSION-$ARCH/slackware{64}/ap et installez-le :

# installpkg slackpkg+-1.3.2-noarch-1_microlinux.txz

Éditez /etc/slackpkg/mirrors et sélectionnez un miroir Slackware en fonction
de votre pays, par exemple :

# /etc/slackpkg/mirrors 
...
# GERMANY (DE)
ftp://ftp.fu-berlin.de/unix/linux/slackware/slackware64-14.2/
...

Assurez-vous de ne choisir qu’un seul miroir pour Slackware stable. Si vous êtes en France, optez pour le miroir ftp.fu-berlin.de ou mirror.switch.ch. Le miroir OVH est inutilisable comme à peu près tout ce qui vient de chez OVH.

Récupérez les clés GPG :

# slackpkg update gpg

Mettez à jour les informations sur les paquets disponibles :

# slackpkg update

Élaguer et installer les paquets MLES

Chaque sous-répertoire server-$VERSION-$ARCH/tools/ fournit un script trim.sh qui se charge de deux choses :

  1. supprimer quelques paquets superflus
  2. installer quelques paquets supplémentaires

Élaguez votre système Slackware de base :

# cd microlinux/server-$VERSION-$ARCH/tools/
# ./trim.sh
  • Le script dans l’arborescence 64-bit n’est qu’un lien symbolique vers la version 32-bit.

Lancer la mise à jour du système de base Slackware :

# slackpkg upgrade-all

À partir de là, les paquets MLES peuvent être installés comme ceci :

# slackpkg install microlinux-server

Peaufiner la configuration du réseau

Éditer /etc/rc.d/rc.inet1.conf et ajouter la configuration de la carte côté réseau local :

# /etc/rc.d/rc.inet1.conf 

# Config information for eth0:
IPADDR[0]="192.168.1.2"
NETMASK[0]="255.255.255.0"
USE_DHCP[0]=""
DHCP_HOSTNAME[0]=""

# Config information for eth1:
IPADDR[1]="192.168.2.1"
NETMASK[1]="255.255.255.0"
USE_DHCP[1]=""
DHCP_HOSTNAME[1]=""

...

# Default gateway IP address:
GATEWAY="192.168.1.1"

Corriger la configuration de l’installateur dans /etc/hosts. Par exemple :

# /etc/hosts
127.0.0.1     localhost.localdomain localhost
192.168.2.1   nestor.microlinux.lan nestor

Prendre en compte les modifications :

# /etc/rc.d/rc.inet1 restart

Pare-feu

Dans ma collection de scripts, le répertoire template/firewall/ contient un modèle de pare-feu presque prêt à l’emploi :

# cd template/firewall/
# cp rc.firewall.router /etc/rc.d/rc.firewall

Adapter la configuration du script, puis :

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

Deux remarques :

  • Si le serveur n’est équipé que d’une seule carte réseau et qu’il ne fait donc pas office de routeur, on choisira le modèle de pare-feu rc.firewall.lan au lieu de rc.firewall.router.
  • Le script rc.firewall.router gère également le relais des paquets. On n’utilisera donc pas le script /etc/rc.d/rc.ip_forward proposé par Slackware.
Publié dans Documentation Microlinux, Slackware | Marqué avec , | Laisser un commentaire

Mettre en place un serveur Samba sous Slackware

Cet article décrit la mise en place d’un serveur de fichiers Samba sous Slackware pour un réseau hétérogène composé de clients sous Windows et sous Linux. Samba permet l’échange de fichiers entre Windows, Linux et Mac OS X. Le nom Samba est dérivé du protocole SMB (Server Message Block), utilisé par Microsoft depuis le début des années 90 pour le partage de données et d’imprimantes.

Prérequis

Dans le pare-feu, ouvrir les ports suivants :

  • 135 en TCP
  • 137 en UDP
  • 138 en UDP
  • 139 en TCP
  • 445 en TCP

Si les comptes utilisateurs des clients Linux sont sur un partage NFS, il faut impérativement utiliser l’option no_root_squash dans /etc/exports, sous peine de se retrouver avec une flopée de bugs bizarres de GVFS dûs à des problèmes de permissions.

Configuration

Créer les répertoires des partages respectifs :

# mkdir -pv -m 1777 /srv/samba/{public,confidentiel}
mkdir: création du répertoire « /srv/samba »
mkdir: création du répertoire « /srv/samba/public »
mkdir: création du répertoire « /srv/samba/confidentiel »

Éditer /etc/samba/smb.conf comme ceci par exemple :

# /etc/samba/smb.conf
 
[global]
workgroup = WORKGROUP
netbios name = %h
server string = Serveur de fichiers %h
dns proxy = yes 
domain master = no
log file = /var/log/samba/log.%m
max log size = 1000
syslog = 0
bind interfaces only = yes
interfaces = 192.168.2.0/24 localhost
hosts allow = 192.168.2. 127.
security = user
passdb backend = tdbsam
unix password sync = no
invalid users = root
encrypt passwords = yes
guest account = smbguest
map to guest = bad user
force group = users
create mode = 0660
directory mode = 0770

[Public]
path = /srv/samba/public
comment = Partage Public
public = yes
only guest = yes
read only = no

[Confidentiel]
path = /srv/samba/confidentiel
comment = Partage Confidentiel
read only = no
invalid users = root nobody smbguest
  • workgroup = WORKGROUP définit le nom du groupe de travail. Les clients Windows doivent tous être membres de ce groupe de travail.
  • netbios name = %h définit le nom qui apparaîtra dans le Voisinage Réseau de Windows. Théoriquement, on pourrait très bien indiquer deux noms de machine différents pour les protocoles TCP/IP et NetBIOS. En pratique, on essaiera de rester cohérent, et on utilisera le nom d’hôte du serveur (%h).
  • server string = Serveur de fichiers %h indique le nom avec lequel le serveur s’identifie. Là aussi, %h sera remplacé par le nom d’hôte.
  • dns proxy = yes active l’utilisation du serveur DNS local pour résoudre les noms d’hôtes Windows.
  • La directive domain master désigne un serveur Samba « maître » pour le domaine local. On utilisera yes sur le serveur principal et no sur les autres serveurs. « Serveur principal » signifie ici quelque chose comme « la machine la plus fiable », « le serveur qu’on éteint le moins souvent », etc.
  • log file = /var/log/samba/log.%m définit la journalisation. Pour chaque client qui utilise Samba, un fichier journal log.client est créé. Quant aux deux services Samba smbd et nmbd, ils utilisent des événements globaux dans les deux fichiers /var/log/samba/log.smbd et /var/log/samba/log.nmbd. Ni le nom ni l’emplacement de ces deux fichiers ne peuvent être modifiés.
  • max log size = 1000 limite la taille maximale du fichier journal à 1000 kilooctets. Lorsqu’un fichier journal dépasse cette taille, Samba le renomme en fichier.old.
  • syslog = 0 signifie que seuls les messages d’erreur sont journalisés dans /var/log/syslog. Pour obtenir une journalisation plus « bavarde », on remplacera la valeur 0 par 1, 2, 3, etc.
  • La directive interfaces définit les interfaces réseau par lesquelles Samba est censé communiquer. On veillera à faire apparaître les partages uniquement dans le réseau local. Ne pas oublier localhost, faute de quoi les outils d’administration comme smbclient ne fonctionneront pas sur le serveur. Les réglages par interfaces sont activés par la directive bind interfaces only.
  • Les directives hosts allow et hosts deny permettent respectivement d’autoriser et d’interdire l’accès de certaines machines du réseau à Samba.
  • La directive security = user définit le modèle de sécurité. Elle est optionnelle, étant donné qu’il s’agit du réglage par défaut de Samba.
  • passdb backend = tdbsam définit la gestion des mots de passe. TDB signifie Trivial Database et désigne un format de stockage binaire. Physiquement, les mots de passe sont stockés dans le fichier /etc/samba/private/passdb.tdb.
  • unix password sync = no désactive la synchronisation des mots de passe Samba avec les mots de passe Linux. Celle-ci est liée à toute une série de restrictions qui risquent de nous compliquer la vie, et il vaut mieux s’en passer.
  • guest account = smbguest désigne l’utilisateur Linux auquel on fait correspondre les utilisateurs invités.
  • map to guest = bad user renvoie vers le compte invité toute tentative de connexion avec un identifiant inexistant.
  • force group = users attribue tous les fichiers et répertoires nouvellement créés au groupe users.
  • Les paramètres create mode = 660 et directory mode = 770 assurent que tous les fichiers (rw-rw----) et répertoires (rwxrwx---) créés par un membre du groupe puissent être lus par tous les autres membres du groupe.
  • Le nom du partage ([Public], [Confidentiel]), ne doit pas dépasser douze caractères.

Créer et gérer les utilisateurs Samba

Créer un utilisateur public smbguest pour Samba :

# useradd -c "Utilisateur Samba" -g users -s /bin/false smbguest
# passwd -l smbguest
# smbpasswd -a smbguest -d
  • L’utilisateur ne dispose pas de shell de connexion (-s /bin/false).
  • Le mot de passe du compte Linux est verrouillé par passwd -l (lock).
  • L’option -a (add) indique à smbpasswd d’ajouter un utilisateur.
  • Celui-ci sera immédiatement désactivé par l’option -d (disabled).

Créer un ou plusieurs utilisateurs Samba normaux. Deux cas de figure se présentent ici. Si l’utilisateur a déjà un compte système :

# smbpasswd -a kikinovak

Éventuellement, vérifier si l’utilisateur fait bien partie du groupe users :

# groups kikinovak | grep users
kikinovak : users floppy audio video cdrom plugdev power netdev

Si ce n’est pas le cas, il faudra l’ajouter comme ceci :

# usermod -a -G users kikinovak

Autrement, s’il n’a pas de compte système :

# useradd -g users -d /dev/null -s /bin/false kikinovak
# passwd -l kikinovak
# smbpasswd -a kikinovak
  • Ici, l’utilisateur n’a ni répertoire utilisateur, ni shell de connexion.
  • Son compte Linux est également verrouillé.

Afficher la liste des utilisateurs Samba :

# pdbedit -L

Supprimer un utilisateur Samba :

# smbpasswd -d 

Éventuellement, on supprimera son compte Linux correspondant :

# userdel -r 

Gestion et utilisation

Tester la configuration :

# testparm

Activer et gérer Samba :

# chmod +x /etc/rc.d/rc.samba
# /etc/rc.d/rc.samba start|stop|restart

Afficher les partages sur le serveur :

# smbclient -L localhost -N

Émuler un dossier Corbeille

Lorsqu’un supprime un fichier sur un partage Samba, il va directement aux oubliettes. Or, tout le monde a pris l’habitude d’avoir une deuxième chance et de pouvoir récupérer des fichiers supprimés dans la Corbeille.

Il existe sous Samba une façon d’activer une corbeille grâce au module Recycle,
qui se situe dans /usr/lib/vfs/recycle.so.

Pour mettre en place cette corbeille, nous allons ajouter une stance correspondante à chacun de nos partages :

# /etc/samba/smb.conf 
...
[Confidentiel]
path = /srv/samba/confidentiel
comment = Partage Confidentiel
read only = no
invalid users = root nobody smbguest

vfs object = recycle
  recycle:repository = .Corbeille
  recycle:keeptree = Yes
  recycle:touch = Yes
  recycle:versions = Yes
  recycle:maxsixe = 0
  recycle:exclude = *.tmp
  recycle:exclude_dir = /tmp
  recycle:noversions = *.doc
...
  • recycle:repository = .Corbeille indique l’endroit où seront stockés les fichiers supprimés.
  • recycle:keeptree = Yes indique si la structure des répertoires doit être conservée (Yes) ou si les fichiers dans le répertoire qui est supprimé doivent être conservés séparément dans la corbeille (No).
  • recycle:touch = Yes indique si la date d’accès du fichier doit être modifiée lors du déplacement dans la corbeille.
  • recycle:versions = Yes permet de conserver deux fichiers supprimés ayant le même nom. La version la plus récente sera renommée en conséquence.
  • recycle:maxsize = 0 empêche les fichiers d’une taille de 0 octet d’être envoyés à la corbeille.
  • recycle:exclude = *.tmp liste les fichiers qui ne passeront pas par la Corbeille.
  • recycle:exclude_dir = /tmp offre la même fonctionnalité pour les répertoires.
  • recycle:noversions = *.doc spécifie la désactivation du contrôle de version pour certains types de fichiers. Évidemment, cette option est utile uniquement lorsque recycle:versions est activé.

Accéder à la corbeille d’un partage :

  • Sous Linux, activer l’affichage des fichiers cachés.
  • Sous Windows, ajouter \.Corbeille au chemin du partage.

Pour vider la corbeille régulièrement, on pourra utiliser le script suivant en l’adaptant à ses besoins :

#!/bin/sh
#
# /etc/cron.weekly/sambacleanup.sh

FIND=/usr/bin/find
RM=/bin/rm
SHARES="/srv/samba/public \
        /srv/samba/confidentiel"

for SHARE in $SHARES; do
  if [ -d $SHARE/.Corbeille ]; then
    $FIND $SHARE/.Corbeille -mtime +60 -exec $RM -rf {} \;
  fi
done
  • Le script est exécuté une fois par semaine.
  • Il supprime définitivement tous les fichiers vieux de plus de deux mois.

Téléchargement

Des modèles de fichiers pour smb.conf et sambacleanup.sh sont disponibles dans mon dépôt Github, dans le répertoire template/samba :

# git clone https://github.com/kikinovak/microlinux

 

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

Synchronisation NTP sous Slackware

Lorsque plusieurs personnes manipulent des données partagées sur des postes clients différents, il est essentiel que ces postes soient tous à la même heure. Malheureusement, l’horloge intégrée dans les machines n’est pas suffisamment exacte. Le protocole NTP (Network Time Protocol) permet aux machines d’un réseau de mettre leurs pendules à l’heure. Il permet la synchronisation des machines entre elles. Les serveurs de temps public sur Internet permettent de recevoir le temps exact. À partir de là, on a plusieurs possibilités d’utiliser NTP.

  1. La commande ntpdate procède à un ajustement ponctuel de l’horloge du BIOS.
  2. L’ajustement ponctuel ne suffit pas pour un serveur qui est censé tourner sans discontinuer. L’horloge du serveur risque de dévier de plus en plus de l’heure exacte. Dans ce cas, il faudra configurer le démon ntpd contenu dans le paquet ntp, qui se charge de contacter les serveurs de temps publics à intervalles réguliers pour procéder ensuite à une série de corrections de l’heure locale.
  3. Le démon ntpd peut à son tour être configuré comme serveur de temps pour les machines locales.

Dans la pratique quotidienne, on utilisera ntpdate pour l’ajustement initial de l’heure locale, et ntpd pour la synchronisation régulière.

Prérequis

Le démon ntpd utilise le port 123 en UDP. Il faut donc ouvrir ce port sur le serveur pour permettre aux postes clients de se connecter.

Synchronisation d’un serveur local ou dédié avec un serveur NTP

Créer le fichier journal :

# touch /var/log/ntp.log

Éventuellement, aller sur pool.ntp.org et choisir la liste des serveurs en fonction du pays.

Configurer le service :

# /etc/ntp.conf

driftfile /etc/ntp/drift
logfile /var/log/ntp.log

server 0.fr.pool.ntp.org
server 1.fr.pool.ntp.org
server 2.fr.pool.ntp.org
server 3.fr.pool.ntp.org

server 127.127.1.0
fudge 127.127.1.0 stratum 10

restrict default nomodify nopeer notrap
restrict 127.0.0.1 mask 255.0.0.0
  • La directive fudge 127.127.1.10 stratum 10 constitue un serveur « bidon » en guise d’IP « fallback« , au cas où la source de temps extérieure deviendrait momentanément indisponible. En cas d’indisponibilité du serveur distant, NTP continuera à tourner en se basant sur ce fonctionnement-là.
  • NTP offre une panoplie de règles pour contrôler l’accès au service, que l’on pourra utiliser en-dehors des règles de pare-feu. Ici, les directives restrict signifient qu’on empêche les machines distantes de modifier la configuration du serveur (première ligne) et qu’on fait confiance à la machine elle-même (deuxième ligne). La directive restrict sans option derrière, mais suivie du seul nom d’hôte, équivaut à un allow all.

Gestion et utilisation

Avant de lancer le service, effectuer l’ajustement initial de l’horloge :

# ntpdate pool.ntp.org
  • La commande ntpdate est normalement considérée comme obsolète, mais elle sert toujours à effectuer des corrections importantes. Théoriquement, c’est la commande ntpd -g qui est censée remplacer ntpdate, mais son utilisation s’avère problématique sur des systèmes déréglés de plus d’une heure.

Activer le service :

# chmod +x /etc/rc.d/rc.ntpd

Gérer le service :

# /etc/rc.d/rc.ntpd start|stop|restart|status

Afficher la liste des serveurs auxquels on est connecté :

# ntpq -p
remote           refid      st t when poll reach   delay   offset 
=================================================================
*panopea.unstabl 213.251.128.249  2 u   30   64  377   56.136  ...
+88-190-17-126.r 145.238.203.14   2 u   29   64  377   77.571  ...
+62.210.255.117  192.93.2.20      2 u   29   64  377   77.097  ...
-ntp.univ-poitie 145.238.203.10   3 u   29   64  377   57.747  ...
LOCAL(0)        .LOCL.          10 l  164   64  374    0.000   ...
  • Le petit astérisque * en début de ligne signifie que la machine est correctement synchronisée avec le serveur distant. La première synchronisation peut nécessiter quelques minutes, parfois même une demi-heure.
  • Pour guetter la première synchronisation, on peut invoquer watch ntpq -p.

Synchronisation des postes clients avec le serveur local

Au lieu de synchroniser chaque poste avec un serveur NTP sur Internet, on va procéder de façon plus économique et préférer la synchronisation avec le serveur local.

Effectuer l’ajustement initial :

# ntpdate pool.ntp.org

Créer le fichier journal :

# touch /var/log/ntp.log

Configurer le service. Dans l’exemple, le serveur NTP est la machine 192.168.2.1 du réseau local :

# /etc/ntp.conf

driftfile /etc/ntp/drift
logfile /var/log/ntp.log

server 192.168.2.1 

server 127.127.1.0 
fudge 127.127.1.0 stratum 10 

restrict default ignore 
restrict 127.0.0.1 mask 255.0.0.0 
restrict 192.168.2.1 mask 255.255.255.255
  • Les directives restrict signifient ici qu’on bloque tout le trafic NTP, excepté pour la machine elle-même et le serveur.

Activer et lancer le service :

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

Vérifier si l’on est bien synchronisé avec le serveur local :

# ntpq -p
     remote           refid      st t when poll reach  delay  offset
====================================================================
*nestor.microlin 109.69.184.210   3 u  105  128  377   0.331  ...
 LOCAL(0)        .LOCL.          10 l 107m   64    0   0.000  ...
  • Là aussi, il faudra attendre quelques minutes avant la première synchronisation.
Publié dans Documentation Microlinux, Slackware | Marqué avec , | Laisser un commentaire

Configurer un serveur DNS avec BIND sous Slackware

Cet article décrit la mise en place d’un serveur DNS avec BIND sur un serveur dédié tournant sous Slackware Linux. 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é

Serveur cache DNS

La configuration par défaut de BIND alloue un serveur de cache. Outre le fichier de configuration principal /etc/named.conf, on trouvera donc une série de fichiers dans /var/named/caching-example. On va remonter ces quatre fichiers d’un cran, dans le répertoire canonique /var/named :

# cd /var/named
# mv -v caching-example/* .
« caching-example/localhost.zone » -> « ./localhost.zone »
« caching-example/named.ca » -> « ./named.ca »
« caching-example/named.local » -> « ./named.local »
« caching-example/named.root » -> « ./named.root »
# rmdir caching-example

Ce changement devra se refléter dans les trois stances respectives de /etc/named.conf, où il faudra rectifier le chemin vers les fichiers de configuration en supprimant le répertoire caching-example. Notez que dans la syntaxe de BIND, les commentaires sont indiqués par une double barre oblique // en début de ligne :

// /etc/named.conf 
options {
  directory "/var/named";
};

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

zone "localhost" IN {
  type master;
  file "localhost.zone";
  allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
  type master;
  file "named.local";
  allow-update { none; };
};

À partir de là, il suffit d’ajouter les DNS externes. En passant, on pourra également spécifier l’utilisation du port 53 en décommentant l’option query-source, pour éviter les ennuis de pare-feu. Gare aux erreurs de syntaxe provenant des accolades et des points-virgule oubliés :

// /etc/named.conf

options {
  directory "/var/named";
  query-source address * port 53;
  forwarders {
    62.210.16.6;
    62.210.16.7;
  };
};
...

Activer le script de démarrage de BIND :

# chmod +x /etc/rc.d/rc.bind

Gérer le démarrage de BIND :

# /etc/rc.d/rc.bind start|stop|reload|restart|status

Indiquer au serveur qu’il doit désormais utiliser son propre DNS :

# /etc/resolv.conf
nameserver 127.0.0.1

Vérifier que le serveur écoute bien sur le port 53 en utilisant dig sur l’interface loopback :

# dig -x 127.0.0.1

On doit obtenir quelque chose comme ceci :

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

Exécuter dig sur un domaine extérieur pour vérifier le temps de requête :

# dig slackware.com

Noter le temps de réponse en fin de résultat :

;; Query time: 61 msec

Ce temps devrait être nettement plus court après une deuxième invocation de dig :

;; Query time: 2 msec

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 ajouter une stance dans /etc/named.conf :

// /etc/named.conf 
...
zone "slackbox.fr" {
  type master;
  file "zone.slackbox.fr";
};

Le fichier 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. (
   2016011601   ; 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.

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.
  • 2016011601 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 2016011601
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 :

# /etc/rc.d/rc.bind restart

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 et autoriser le transfert de la zone vers le DNS secondaire d’Online. Là encore, attention à la syntaxe quelque peu biscornue de BIND :

// /etc/named.conf 
...
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.

Quelques vérifications

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

Configuration du DNS :

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

Configuration du reverse DNS :

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

Nom d’hôte du serveur mail :

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

Adresse IP du serveur mail :

# host mail.slackbox.fr
mail.slackbox.fr has address 195.154.65.130
Publié dans Documentation Microlinux, Slackware | Marqué avec , , , | Laisser un commentaire