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

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

Configurer un serveur web Apache sous Slackware

Apache est le principal serveur Web du monde de l’Open Source. D’après les statistiques de Netcraft (http://netcraft.com), 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.

Cet article est basé sur les paquets httpd (Apache), php et mariadb, contenus dans une installation standard de Slackware.

Prérequis

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

Tester Apache

Activer et démarrer Apache :

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

Tester le bon fonctionnement du serveur :

# links http://localhost

On doit voir quelque chose de ce genre :

=======================
      It works!
=======================

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

  • http://192.168.2.1

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

  • http://nestor.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

Configuration de base

Le principal fichier de configuration d’Apache, c’est /etc/httpd/httpd.conf. Avant d’éditer ce fichier, on va en faire une copie :

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

On peut déjà renseigner quelques directives :

# /etc/httpd/httpd.conf
...
ServerAdmin info@microlinux.fr
...
ServerName nestor.microlinux.lan:80
...
  • 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
...

Héberger un site web statique

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

# /etc/httpd/httpd.conf
...
DocumentRoot "/srv/httpd/htdocs"
...

Notons que /srv/httpd est un lien symbolique qui pointe vers /var/www :

# ls -l /srv/httpd
lrwxrwxrwx 1 root root 8 nov.   9 07:53 /srv/httpd -> /var/www

Pour avoir quelque chose à nous mettre sous la dent, on va ranger la page par défaut à un autre endroit pour la remplacer par un « vrai » site web statique. On choisira la documentation de Slackware, qui vient sous forme d’une série de pages HTML statiques.

Sauvegarder les fichiers fournis par défaut comme ceci, par exemple :

# cd /var/www/htdocs/
# ls
htdig  index.html  manual
# mkdir /root/htdocs_backup
htdig  index.html  manual
# mv -v * /root/htdocs_backup/
« htdig » -> « /root/htdocs_backup/htdig »
« index.html » -> « /root/htdocs_backup/index.html »
« manual » -> « /root/htdocs_backup/manual »

Ensuite, récupérer la documentation de Slackware. L’outil wget est utilisé ici comme aspirateur de site :

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

Assainir les permissions :

# find . -type d -exec chmod 0750 \{} \;
# find . -type f -exec chmod 0640 \{} \;

Le serveur Apache tourne avec les droits de l’utilisateur apache et du groupe apache :

# /etc/httpd/httpd.conf
...
User apache
Group apache
...

On va donc attribuer toutes les pages de notre site local à cet utilisateur et à ce groupe :

# chown -R apache:apache /var/www/htdocs

À présent, on peut ouvrir le site dans un navigateur (Firefox, Links, Lynx) et apprécier le résultat. Si le site ne s’affiche pas comme prévu dans Firefox, rafraîchir la page en appuyant sur [F5].

Héberger plusieurs sites sur un même serveur

Le principe des serveurs 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.

Dans un premier temps, on va renommer le répertoire /var/www/htdocs en /var/www/vhosts :

# cd /var/www
# mv htdocs vhosts

Il faudra modifier httpd.conf pour prendre en compte ce changement :

# /etc/httpd/httpd.conf
...
DocumentRoot "/srv/httpd/vhosts"
<Directory "/srv/httpd/vhosts">
...

On va déplacer le site existant dans un nouveau répertoire :

# cd vhosts
# mkdir -pv ../slackware/htdocs
mkdir: création du répertoire « ../slackware »
mkdir: création du répertoire « ../slackware/htdocs »
# mv * ../slackware/htdocs/
# mv ../slackware/ .

Ensuite, on va créer un autre répertoire, dans lequel on va télécharger un autre site, en l’occurrence la documentation de FreeBSD :

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

Enfin, on va rétablir l’ancienne page index.html à un endroit approprié :

# cd /var/www/vhosts
# mkdir -pv default/htdocs
mkdir: création du répertoire « default »
mkdir: création du répertoire « default/htdocs »
# mv -v /root/htdocs_backup/index.html default/htdocs/
« /root/htdocs_backup/index.html » -> « default/htdocs/index.html »

Au total, on a donc :

# ls -l
total 20
drwxr-xr-x  2 root root  4096 févr.  3 10:14 default
drwxr-xr-x  9 root root 12288 févr.  3 10:05 freebsd
drwxr-xr-x 11 root root  4096 févr.  3 09:51 slackware

On va définir les permissions à la louche :

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

Éditer le fichier /etc/httpd/extra/httpd-vhosts.conf. On pourra utiliser une des deux stances fournies en exemple comme modèle. Dans un premier temps, définir 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/extra/httpd-vhosts.conf 

# Page par défaut
ServerAdmin info@microlinux
DocumentRoot "/srv/httpd/vhosts/default/htdocs"
ServerName nestor.microlinux.lan
ServerAlias nestor
ErrorLog "/var/log/httpd/default-error_log"
CustomLog "/var/log/httpd/default-access_log" common

Une erreur à ne pas commettre, c’est d’indiquer le chemin « réel » vers les pages Web pour DocumentRoot, c’est-à-dire /var/www/vhosts/default au lieu de /srv/httpd/vhosts/default. Le chemin doit coïncider avec celui que l’on a défini dans /etc/httpd/httpd.conf pour DocumentRoot.

Pour activer les hôtes virtuels, il faut inclure le module en décommentant la ligne correspondante dans /etc/httpd/httpd.conf :

# /etc/httpd/httpd.conf 
...
# Virtual hosts
Include /etc/httpd/extra/httpd-vhosts.conf
...

Redémarrer Apache pour prendre en compte les modifications :

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

Vérifier si la page par défaut du serveur s’affiche bien :

  • http://nestor

Là encore, si l’on utilise Firefox, penser à rafraîchir la page avec la touche [F5].

À présent, nous pouvons ajouter les deux autres sites :

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

# Page par défaut du serveur
ServerAdmin info@microlinux
DocumentRoot "/srv/httpd/vhosts/default/htdocs"
ServerName nestor.microlinux.lan
ServerAlias nestor
ErrorLog "/var/log/httpd/default-error_log"
CustomLog "/var/log/httpd/default-access_log" common

# Documentation de Slackware
ServerAdmin info@microlinux
DocumentRoot "/srv/httpd/vhosts/slackware/htdocs"
ServerName slackware.nestor.microlinux.lan
ServerAlias slackware.nestor
ErrorLog "/var/log/httpd/slackware-error_log"
CustomLog "/var/log/httpd/slackware-access_log" common

# Documentation de FreeBSD
ServerAdmin info@microlinux
DocumentRoot "/srv/httpd/vhosts/freebsd/htdocs"
ServerName freebsd.nestor.microlinux.lan
ServerAlias freebsd.nestor
ErrorLog "/var/log/httpd/freebsd-error_log"
CustomLog "/var/log/httpd/freebsd-access_log" common

Pour l’instant, les noms d’hôtes slackware.nestor et freebsd.nestor ne correspondent à rien dans notre réseau local. Nous devons donc les ajouter au fichier /etc/hosts de la machine sur laquelle tourne Dnsmasq :

# /etc/hosts 
192.168.2.1 nestor.microlinux.lan nestor
192.168.2.1 slackware.nestor.microlinux.lan slackware.nestor
192.168.2.1 freebsd.nestor.microlinux.lan freebsd.nestor

Redémarrer Dnsmasq pour propager la configuration :

# /etc/rc.d/rc.dnsmasq restart

Redémarrer Apache pour prendre en compte les deux nouveaux hôtes virtuels :

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

Tester l’affichage des trois différents sites :

  • http://slackware.nestor.microlinux.lan
  • http://freebsd.nestor.microlinux.lan
  • http://nestor.microlinux.lan (page par défaut)

Sur un serveur dédié avec un domaine publiquement accessible, la configuration des hôtes virtuels ressemblera à ceci :

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

# Page par défaut du serveur
ServerAdmin info@microlinux.fr
DocumentRoot "/srv/httpd/vhosts/default/htdocs"
ServerName sd-48975.dedibox.fr
ErrorLog "/var/log/httpd/default-error_log"
CustomLog "/var/log/httpd/default-access_log" common

# Documentation de Slackware
ServerAdmin info@microlinux.fr
DocumentRoot "/srv/httpd/vhosts/slackware/htdocs"
ServerName slackware.slackbox.fr
ErrorLog "/var/log/httpd/slackware-error_log"
CustomLog "/var/log/httpd/slackware-access_log" common

# Documentation de FreeBSD
ServerAdmin info@microlinux.fr
DocumentRoot "/srv/httpd/vhosts/freebsd/htdocs"
ServerName freebsd.slackbox.fr
ErrorLog "/var/log/httpd/freebsd-error_log"
CustomLog "/var/log/httpd/freebsd-access_log" common

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 :

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

Tester l’affichage des trois différentes sites :

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

Héberger des sites dynamiques avec PHP

Activer le module PHP dans /etc/httpd/httpd.conf :

# /etc/httpd/httpd.conf
...
# Uncomment the following line to enable PHP:
#
Include /etc/httpd/mod_php.conf
...

La directive DirectoryIndex définit le fichier qui sera affiché lorsqu’un répertoire est requis. On ajoutera les fichiers index.php, et on pourra également compléter par index.htm, une extension que l’on rencontre rarement, mais qui existe :

# /etc/httpd/httpd.conf 
...
DirectoryIndex index.html index.htm index.php
...

Redémarrer Apache pour prendre en compte les modifications.

Ajouter une section pour afficher les infos PHP :

# cd /var/www/vhosts
# mkdir phpinfo/htdocs

Dans ce répertoire, éditer un fichier index.php comme ceci :

<?php
echo phpinfo();
?>

Régler les droits d’accès :

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

Créer un hôte virtuel phpinfo.nestor ou phpinfo.slackbox.fr et afficher la page index.php dans un navigateur.

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 :

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

Avant Slackware 14.2, le fichier php.ini était rangé dans le répertoire /etc/httpd.

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

Utiliser MySQL à partir de PHP

Voir l’article sur MySQL pour le serveur de bases de données. Si MySQL est installé sur la machine, il est utilisable à partir de PHP sans autre configuration.

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

Mettre en place un serveur Dnsmasq sous Slackware

dnsmasq-logoCet article décrit la configuration d’un serveur Dnsmasq sous Slackware Linux. Dnsmasq est un serveur léger qui fournit les services DHCP et DNS pour des réseaux locaux, même de taille importante. Il est extrêmement facile à configurer, et l’on pourra l’utiliser pour remplacer DHCPD et Bind. Ce dernier n’est pas très adapté pour les DNS de réseaux locaux, notamment à cause de sa syntaxe farfelue.

Prérequis

Ouvrir les ports suivants dans le pare-feu :

  • 53 en TCP et UDP (requêtes DNS)
  • 67 et 68 en UDP (requêtes DHCP)

Le fichier /etc/hosts du serveur local doit comporter au moins les deux lignes suivantes :

# /etc/hosts
127.0.0.1     localhost.localdomain localhost
192.168.3.1   amandine.sandbox.lan  amandine

C’est surtout la deuxième ligne qui est d’une importance capitale. Elle fait correspondre le nom de la machine locale avec l’adresse IP dans le réseau local.

Configuration de base

La configuration de Dnsmasq s’effectue par le biais du fichier de configuration /etc/dnsmasq.conf. Le fichier fourni par défaut comporte près de 500 lignes de commentaires et sert également de documentation. On pourrait très bien activer l’une ou l’autre option en la décommentant. Dans le cas présent, il vaut mieux effectuer une copie de sauvegarde et commencer par un fichier vide :

# cd /etc
# mv dnsmasq.conf dnsmasq.conf.orig
# touch dnsmasq.conf

Éditer une configuration minimale, par exemple :

# /etc/dnsmasq.conf
domain-needed
bogus-priv
interface=eth1                            
dhcp-range=192.168.3.100,192.168.3.200,24h
local=/sandbox.lan/
domain=sandbox.lan
expand-hosts
server=192.168.3.1
  • Les deux premières options domain-needed et bogus-priv évitent que Dnsmasq ne relaie les noms d’hôtes locaux à un ou plusieurs serveurs DNS en amont.
  • L’option interface spécifie l’interface réseau que l’on souhaite utiliser.
  • L’option dhcp-range définit la plage d’adresses dynamiques utilisée parle serveur DHCP. Dans le cas présent, les adresses attribuées auront une durée de validité de 24 heures. Passé ce délai, elles devront être renouvelées par les clients.
  • L’option local indique que les réponses aux requêtes pour le domaine spécifié doivent être fournies directement par Dnsmasq, et non pas par un serveur DNS en amont.
  • L’option domain attribue le nom de domaine spécifié aux clients. Pour des raisons évidentes, il doit coïncider avec le domaine défini dans l’option local.
  • L’option expand-hosts concerne les requêtes DNS sans le domaine et se charge d’ajouter celui-ci automatiquement. Concrètement, lorsqu’on essaie d’envoyer un ping sur bernadette, Dnsmasq retournera automatiquement l’adresse IP de bernadette.sandbox.lan.
  • L’option server spécifie l’adresse IP d’un ou plusieurs serveurs DNS en amont.

Démarrage et utilisation

Activer Dnsmasq :

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

Gérer le lancement et l’arrêt :

# /etc/rc.d/rc.dnsmasq start|stop|restart

Attribuer des adresses statiques

On pourra attribuer une adresse IP et un nom d’hôte fixe en fonction de l’adresse MAC des interfaces réseau respectives, en ajoutant une série d’entrées comme ceci :

# /etc/dnsmasq.conf
...
dhcp-host=00:1E:C9:43:A7:BF,bernadette,192.168.3.2
dhcp-host=00:1D:09:15:4A:D8,raymonde,192.168.3.3
...

On choisira les adresses IP en-dehors de la plage d’adresses dynamiques.

Si l’on souhaite attribuer une adresse IP et un nom d’hôte fixe à un portable que l’on connecte aussi bien par le wifi que par une connexion filaire, on peut utiliser la syntaxe suivante :

# /etc/dnsmasq.conf
...
dhcp-host=44:1E:A1:E6:FA:93,E4:D5:3D:BD:EA:05,buzz,192.168.3.6
dhcp-host=00:27:19:F1:BC:3A,00:19:E0:83:3A:C1,bebette,192.168.3.7
...

Ajouter des hôtes statiques

L’ajout d’hôtes statiques est extrêmement simple avec Dnsmasq. Il suffit d’ajouter l’entrée correspondante dans le fichier /etc/hosts du serveur, et celui-ci se chargera de relayer l’info :

# /etc/hosts 
...
192.168.3.254   wifi
...

Relancer Dnsmasq pour prendre en compte les modifications :

# /etc/rc.d/rc.dnsmasq restart

On peut également ajouter un raccourci pour une adresse IP externe :

# /etc/hosts
...
88.191.189.120  dedibox
...

Si le serveur héberge une série de sites web sous formes d’hôtes virtuels, on peut ajouter les entrées correspondantes comme ceci :

# /etc/hosts 
...
192.168.3.1   mirror.amandine.sandbox.lan mirror.amandine
192.168.3.1   cmsms.amandine.sandbox.lan cmsms.amandine
...

Résolution des noms d’hôtes

Les postes clients sur le réseau utilisent les informations sur les noms d’hôtes fournies par Dnsmasq. Pour que le serveur lui-même puisse les prendre en compte aussi, il faudra éditer /etc/resolv.conf comme ceci :

# /etc/resolv.conf
nameserver 127.0.0.1

Vérifions :

[root@amandine:~] # host bernadette
bernadette has address 192.168.3.2
[root@amandine:~] # host raymonde
raymonde has address 192.168.3.3

Afficher en direct l’attribution des baux DHCP

Sur le serveur, on peut suivre en direct l’attribution des baux DHCP en affichant en continu le journal /var/log/messages :

# tail -f /var/log/messages
... DHCPREQUEST(eth1) 192.168.3.2 00:1e:c9:43:a7:bf
... DHCPACK(eth1) 192.168.3.2 00:1e:c9:43:a7:bf bernadette
... DHCPREQUEST(eth1) 192.168.3.3 00:1d:09:15:4a:d8
... DHCPACK(eth1) 192.168.3.3 00:1d:09:15:4a:d8 raymonde
Publié dans Documentation Microlinux, Slackware | Marqué avec , , | Laisser un commentaire

Configurer un serveur de bases de données MySQL/MariaDB sous Slackware

Cet article décrit la mise en place d’un serveur de bases de donnéesMySQL/MariaDB sous Slackware. MySQL est le système de bases de données le plus populaire du monde de l’Open Source. Un grand nombre d’applications web utilisent MySQL comme moteur de bases de données : wikis, moteurs de blogs et de forums, systèmes de gestion de contenu, etc.

On entend parfois dire que MySQL n’est pas un « vrai » système de bases de données en comparaison à des systèmes comme Oracle ou DB/2. Contentons-nous de savoir que MySQL est utilisé, entre autres, par Facebook, Google et Yahoo!

Slackware 14.1 a remplacé MySQL par le fork communautaire MariaDB, suite au rachat de MySQL par Sun Microsystems et Oracle. La gouvernance du projet MariaDB est assurée par la fondation MariaDB. Elle confère au logiciel l’assurance de rester libre.

Choisir un fichier de configuration pour MySQL

Cette section ne concerne pas MariaDB. Elle est uniquement valable pour MySQL, inclus dans Slackware jusqu’à la version 14.0.

Sélectionner un fichier de configuration dans la panoplie de modèles disponibles selon les besoins dans le répertoire /etc/mysql :

  • my-small.cnf pour une base de données taille S
  • my-medium.cnf pour une base de données taille M
  • my-large.cnf pour une base de données taille L
  • my-huge.cnf pour une base de données taille XL
  • my-innodb-heavy-4G.cnf pour une base de données taille XXL

Exemple :

# cd /etc/mysql
# cp my-small.cnf my.cnf

Initialiser le serveur MySQL/MariaDB

Initialiser le répertoire de données MySQL/MariaDB :

# mysql_install_db
Installing MySQL system tables...
OK
Filling help tables...
OK
...

Régler les permissions :

# chown -R mysql:mysql /var/lib/mysql

Activer le démon MySQL :

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

Lancer le démon MySQL :

# /etc/rc.d/rc.mysqld start
mysqld_safe Logging to '/var/lib/mysql/alphamule.err'.
mysqld_safe Starting mysqld daemon with databases from 
  /var/lib/mysql

Il faut éventuellement appuyer une deuxième fois sur [Entrée] pour récupérer l’invite de commandes.

Sécuriser le serveur MySQL/MariaDB

MySQL/MariaDB dispose de l’utilitaire mysql_secure_installation pour assurer la sécurité d’une installation fraîche sur une machine de production. Ce programme permet d’effectuer quelques démarches de sécurisation essentielles :

  1. Définir un mot de passe root MySQL (ne pas confondre avec le compte root Linux).
  2. Supprimer les comptes root MySQL accessibles de l’extérieur.
  3. Supprimer les connexions anonymes.
  4. Supprimer la base de données de test.

Lancer la sécurisation :

# mysql_secure_installation
...
Set root password? [Y/n] --> Y
New password:
Re-enter new password:
Password updated successfully!
Reloading privilege tables..
... Success!
Remove anonymous users? [Y/n] --> Y
... Success!
Disallow root login remotely? [Y/n] --> Y
... Success!
Remove test database and access to it? [Y/n] --> Y
- Dropping test database...
... Success!
- Removing privileges on test database...
... Success!
Reload privilege tables now? [Y/n] --> Y
... Success!
Cleaning up...

Lancer une connexion à la console MySQL :

# mysql -u root -p
Enter password:
Welcome to the MySQL monitor.

Afficher les bases de données :

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
+--------------------+
3 rows in set (0.00 sec)

Utiliser la base de données mysql :

mysql> use mysql;
Database changed

Afficher les utilisateurs :

mysql> select user, host, password from user;
+------+-----------+-------------------------------------------+
| user | host      | password                                  |
+------+-----------+-------------------------------------------+
| root | localhost | *6883418C147A759B04D78A2D1E4E0C5BB0CDD1B4 |
| root | 127.0.0.1 | *6883418C147A759B04D78A2D1E4E0C5BB0CDD1B4 |
| root | ::1       | *6883418C147A759B04D78A2D1E4E0C5BB0CDD1B4 |
+------+-----------+-------------------------------------------+
3 rows in set (0.00 sec)

Si l’on n’utilise pas l’IPv6, on peut désactiver root@::1 comme ceci :

mysql> delete from user where host = '::1';
Query OK, 1 row affected (0.00 sec)

Vérifier le résultat de l’opération :

mysql> select user, host, password from user;
+------+-----------+-------------------------------------------+
| user | host      | password                                  |
+------+-----------+-------------------------------------------+
| root | localhost | *6883418C147A759B04D78A2D1E4E0C5BB0CDD1B4 |
| root | 127.0.0.1 | *6883418C147A759B04D78A2D1E4E0C5BB0CDD1B4 |
+------+-----------+-------------------------------------------+
2 rows in set (0.00 sec)

Quitter la console MySQL :

mysql> quit;
Bye

Exemple de base de données

Se connecter au moniteur MySQL :

# mysql -u root -p
mysql>

Créer une base de données webapp :

mysql> create database webapp;

Afficher les bases de données :

mysql> show databases;

Créer un utilisateur webappuser qui aura tous les droits sur webapp :

mysql> grant all on webapp.* to webappuser@localhost
   - > identified by 'motdepasse';

Attention, le mot de passe apparaît en clair dans le moniteur MySQL !

mysql> quit;

Si l’on souhaite supprimer cette base de données :

mysql> drop database webapp;

Sauvegarde

La commande mysqldump permet de sauvegarder une base de données MySQL sous forme d’une série d’instructions SQL.

L’exemple suivant effectue une sauvegarde complète de la base de données cmsms :

$ mysqldump -u root -p cmsms > sauvegarde_cmsms.sql

L’option --all-databases permet de sauvegarder l’ensemble des bases de données d’un serveur :

$ mysqldump -u root -p --all-databases > sauvegarde.sql

Les fichiers SQL résultants sont parfois très volumineux, étant donné qu’il s’agit d’un format texte simple. Dans ce cas, on peut les compresser durant la sauvegarde même. Voici ce que cela donne pour les deux exemples précédents :

$ mysqldump -u root -p cmsms | gzip -c > sauvegarde_cmsms.sql.gz
$ mysqldump -u root -p --all-databases | gzip -c > sauvegarde.sql.gz

Restauration

Dans l’exemple suivant, on va restaurer la base de données cmsms depuis le fichier de sauvegarde créé ci-dessus :

$ mysqladmin -u root -p create cmsms
$ mysql -u root -p cmsms < sauvegarde_cmsms.sql

Pour restaurer « à la louche » une sauvegarde globale, il suffit d’invoquer la commande suivante qui gère également la création des bases de données :

$ mysql -u root -p < sauvegarde.sql

La restauration à partir d’une sauvegarde compressée peut s’effectuer comme ceci :

$ mysqladmin -u root -p create cmsms
$ gunzip -c sauvegarde_cmsms.sql.gz | mysql -u root -p cmsms

Et pour une sauvegarde globale :

$ gunzip -c sauvegarde.sql.gz | mysql -u root -p

Si l’on obtient des erreurs de connexion aux bases restaurées, il faudra se connecter au moniteur MySQL, puis :

mysql> flush privileges;

Sauvegardes automatiques

Mon dépôt Github fournit un script Bash sqldump.sh dans le répertoire template/backup. Ce script permet d’effectuer des sauvegardes automatiques de l’ensemble des bases MySQL d’un serveur, individuellement et « à la louche ». Les sauvegardes se présentent sous forme d’une série de fichiers compressés *.sql.gz rangés dans le répertoire /sqldump. Par la suite, ces fichiers pourront être récupérés par un serveur de sauvegardes.

# cd
# git clone https://github.com/kikinovak/microlinux
# cd microlinux/template/backup/
# cp sqldump.sh /usr/local/sbin/
# chmod 0700 /usr/local/sbin/sqldump.sh
# vim /usr/local/sbin/sqldump.sh
Publié dans Documentation Microlinux, Slackware | Marqué avec , , | Laisser un commentaire

Configurer l’authentification par clé SSH

Cet article décrit la mise en place d’une connexion SSH sans mot de passe, à l’aide d’une paire de clés. Si l’on se connecte quotidiennement à une machine distante, la connexion SSH sans mot de passe évite d’avoir à saisir le mot de passe à chaque fois. Dans l’exemple ci-dessous, l’utilisateur kikinovak souhaite se connecter depuis la machine buildbox.microlinux.lan à la machine nestor.microlinux.lan sans avoir à saisir son mot de passe à chaque connexion.

Générer la paire de clés

Sur la machine buildbox.microlinux.lan, créer une clé d’identification SSH. Accepter l’emplacement par défaut pour la sauvegarde de la clé en appuyant sur [Entrée]. De même, laisser la zone du mot de passe vide en appuyant deux fois de suite sur [Entrée] :

[kikinovak@buildbox:~] $ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/kikinovak/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/kikinovak/.ssh/id_rsa.
Your public key has been saved in /home/kikinovak/.ssh/id_rsa.pub.

On vient de créer une clé privée ~/.ssh/id_rsa et une clé publique ~/.ssh/id_rsa.pub :

[kikinovak@buildbox:~] $ tree -a .ssh/
.ssh/
|-- id_rsa
|-- id_rsa.pub
`-- known_hosts

Transférer la clé publique

Maintenant, il faut transférer la clé publique (et non PAS la clé privée) sur la machine distante, en l’occurrence nestor.microlinux.lan :

$ ssh-copy-id -i ~/.ssh/id_rsa.pub kikinovak@nestor
The authenticity of host 'nestor (192.168.2.1)' 
can't be established.
ECDSA key fingerprint is 
08:16:b0:b0:81:c3:73:96:99:ea:8c:b6:e7:38:b7:d3.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the 
new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- 
if you are prompted now it is to install the new keys
kikinovak@nestor's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'kikinovak@nestor'"
and check to make sure that only the key(s) you wanted were added.

Contrôler les clés installées

À présent, on peut se connecter à la machine distante :

[kikinovak@buildbox:~] $ ssh kikinovak@nestor
Linux 3.10.17.

Il ne reste plus qu’à contrôler le fichier ~/.ssh/authorized_keys pour vérifier qu’on n’a pas ajouté des clés supplémentaires indésirables :

[kikinovak@nestor:~] $ cat ~/.ssh/authorized_keys ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQC2QQSfCGvvt7T9Fx/iSUIe1c/7c6wfQ0sdpF
t6tmhvPWRgwjfxhB4XZLZnEduUAfEcxgjsZ/fw4kIYWKlcndnOdeiUxCz1ebSg1+4H
KBMBLtWEjg1koKZEoX6hnB6Lg6qxoF9aye3bft7hMiY2v66MdsjLOHnom0g2s2l0op
8Q4o6QBJOn3L4VgeEZbPYw8fs/IXmSscoCGkUmMlmUo0Mka/Gv96ccSAsSywANaKlD
2n0X2dRyWHhTMHc7J047xyCxa0c6A1NeoX6sn8oI3pECIJEoZ4ml1OQfj3VPGFCNoL
+WciQRf kikinovak@buildbox.microlinux.lan

Se connecter sans mot de passe

Dorénavant, la connexion SSH ne requiert pas la saisie du mot de passe :

[kikinovak@buildbox:~] $ ssh nestor
Last login: Wed Dec  9 08:15:32 2015 from buildbox.microlinux.lan
Linux 3.10.17.
[kikinovak@nestor:~] $ 
Publié dans Documentation Microlinux | Marqué avec | Laisser un commentaire