Configurer une imprimante HP PageWide Pro 477 sous CentOS

HPUn de mes clients, un lycée privé dans les Cévennes, a acquis une nouvelle imprimante professionnelle, une HP PageWide Pro 477 fournie par la société JustPrint, pour faire face aux besoins accrus en impression des enseignants. J’ai une préférence marquée pour les imprimantes de la marque HP, étant donné qu’elles sont toutes très bien gérées par HPLIP. Or, avec les modèles récents, il est parfois nécessaire d’utiliser une version plus récente de HPLIP que celle fournie par le distributeur. C’est le cas notamment pour la famille Red Hat Enterprise Linux et CentOS. L’installation d’une version plus récente de HPLIP n’est pas une opération triviale lorsqu’on utilise ces distributions. C’est la raison pour laquelle j’ai rédigé cette petite documentation.

HP PageWide Pro 477

Tous les postes clients de l’école – secrétariat, salle des profs, salle informatique – tournent sous CentOS 7 avec un bureau Xfce. La configuration par défaut est plutôt minimale et ne fournit pas de serveur d’impression, on va donc commencer par installer ce composant.

# yum group install "Print Server"

Activer et démarrer le serveur CUPS.

# systemctl enable cups
# systemctl start cups

Dans un premier temps, on va installer la version de HPLIP fournie par CentOS.

# yum install hplip-gui

L’intérêt de cette démarche, c’est de disposer de toutes les dépendances nécessaires au bon fonctionnement de HPLIP. Les mainteneurs du paquet récent fourni par HP n’ont pas renseigné correctement les dépendances du paquet.

La prochaine étape consiste à récupérer le paquet récent de HPLIP sur le site officiel. On note au passage que l’ancien site https://hplipopensource.com est redirigé vers cette nouvelle plateforme. Cette fois-ci, c’est clair qu’on ne s’adresse pas à Madame Michu.

Dans le menu principal du site, suivre les liens Install and Setup > Download et télécharger le paquet pour Red Hat Enterprise Linux 7. Choisir la version Full Package.

HPLIP

Ranger le paquet hplip-3.18.3_rhel-7.0.x86_64.rpm dans un endroit approprié, par exemple /root/hplip.

Comme il faut s’y attendre, une première tentative d’installation du paquet se solde par un échec.

# yum localinstall hplip-3.18.3_rhel-7.0.x86_64.rpm

En effet, le gestionnaire de paquets affiche une série de conflits avec les paquets HPLIP existants du système. Ici, je procède par itération, en supprimant à chaque fois le paquet incriminé, et je relance yum localinstall. Voici au final la liste des paquets qui posent problème.

  • hplip-gui
  • libsane-hpaio
  • hplip
  • hpijs
  • hplip-libs
  • hplip-common

Une fois que je les ai tous supprimés, je peux installer mon paquet hplip en provenance de chez HP.

# yum localinstall hplip-3.18.3_rhel-7.0.x86_64.rpm

Je note au passage que ce paquet hplip fournit hplipfull.

# rpm -qa | grep hplip
hplipfull-3.18.3-0.x86_64

Pour éviter les conflits et faire les choses proprement, j’édite /etc/yum.conf pour blacklister les paquets officiels.

# /etc/yum.conf
...
exclude=hplip* hpijs libsane-hpaio

Je lance l’assistant graphique de configuration des imprimantes HP depuis le menu Applications et je clique sur Setup Device.

HPLIP

Les deux imprimantes de l’école sont des imprimantes réseau.

HPLIP

Je sélectionne l’imprimante que je souhaite configurer.

HPLIP

Je renseigne la description et l’emplacement de l’imprimante et j’active l’envoi de la page de test.

HPLIP

HPLIP me demande de fournir le mot de passe root.

HPLIP

À ce stade, je vérifie si ma page de test s’est imprimée correctement. Une fois que tout est bon, je définis mon imprimante comme imprimante par défaut.

HPLIP

Pour finir, je lance Simple Scan pour vérifier le bon fonctionnement du scanner de l’imprimante.

HPLIP

 

 

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

Créer un dépôt de paquets Yum

Dépôt de paquets YumDans mon précédent article, nous avons vu la construction de paquets RPM sous CentOS. À partir du moment où l’on souhaite distribuer ces paquets à un grand nombre de machines et en gérer la maintenance, il devient indispensable de créer son propre dépôt de paquets pour Yum.

En temps normal, je me sers des dépôts de paquets tiers existants comme EPEL, Nux-Dextop ou Webtatic. Cependant, il peut arriver qu’un paquet un peu exotique ne soit disponible dans aucun de ces dépôts. Dans d’autres cas, il m’arrive aussi de devoir modifier un paquet pour l’adapter à mes besoins. Pour tous ces cas de figure, il est bien plus pratique de disposer de son propre dépôt de paquets.

Dans un premier temps, récupérer l’utilitaire de création d’archive.

# yum install createrepo

Créer une arborescence d’archive vide.

$ mkdir -p ~/repos/centos/7/x86_64/RPMS

Il nous faudra également un emplacement pour les paquets source.

$ mkdir repos/centos/7/SRPMS

Une fois qu’on a rangé les paquets RPMS et SRPMS à l’endroit approprié, on va construire les métadonnées.

$ cd repos/centos/7/x86_64
$ createrepo .

Si tout se passe comme prévu, on obtient un répertoire repodata au même niveau que le répertoire RPMS.

$ tree -d ~/repos
/home/kikinovak/repos
└── centos
    └── 7
        ├── SRPMS
        └── x86_64
            ├── repodata
            └── RPMS

Je copie l’arborescence ~/repos/centos vers l’hébergement web /var/www/microlinux-centos/html/ visible à l’adresse https://centos.microlinux.fr. Lors de la construction des paquets, j’ai également exporté la clé GPG publique pour signer mes paquets vers un fichier RPM-GPG-KEY-microlinux. Je copie ce fichier à la racine de mon hébergement, plus exactement vers /var/www/microlinux-centos/html/centos/. En passant, je personnalise le fichier .htaccess pour peaufiner l’affichage des fichiers du dépôt.

Dépôt de paquets Yum

Sur un poste client, j’importe tout d’abord la clé GPG du dépôt.

# rpm --import \
https://centos.microlinux.fr/centos/RPM-GPG-KEY-microlinux

Ensuite, j’édite un fichier /etc/yum.repos.d/microlinux.repo comme ceci.

[microlinux]
enabled=1
priority=1
name=Microlinux Enterprise Packages $releasever - $basearch
baseurl=https://centos.microlinux.fr/centos/$releasever/$basearch
gpgcheck=1

À partir de là, je peux accéder aux paquets de mon dépôt avec le gestionnaire de paquets yum.

Publié dans CentOS, Documentation Microlinux | Marqué avec , , | Un commentaire

Construire des paquets RPM pour CentOS

Paquets RPMCet article décrit de façon succincte la mise en place d’un environnement de construction et la compilation de paquets pour CentOS. La construction de paquets RPM est un vaste chapitre. Ce petit tutoriel me sert avant tout de pense-bête pour les spécificités de la construction d’un paquet sous RHEL/CentOS. Il ne pourra pas remplacer une documentation détaillée.

Dans l’exemple qui suit, je vais construire le paquet Plank pour CentOS 7 depuis le paquet source de Fedora 22. Je vais partir d’un système minimal et installer pas à pas les outils et autres dépendances nécessaires.

Mettre en place l’environnement de construction

L’outil de construction rpmbuild est fourni par le paquet rpm-build. L’outil rpmsign fourni par le paquet rpm-sign nous servira à signer nos paquets.

# yum install rpm-build rpm-sign

On prendra soin de construire les paquets en tant que simple utilisateur. Les droits root seront uniquement nécessaires pour l’installation des paquets.

Créer l’arborescence de construction des paquets.

$ mkdir -pv ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
mkdir: création du répertoire « /home/kikinovak/rpmbuild »
mkdir: création du répertoire « /home/kikinovak/rpmbuild/BUILD »
mkdir: création du répertoire « /home/kikinovak/rpmbuild/RPMS »
mkdir: création du répertoire « /home/kikinovak/rpmbuild/SOURCES »
mkdir: création du répertoire « /home/kikinovak/rpmbuild/SPECS »
mkdir: création du répertoire « /home/kikinovak/rpmbuild/SRPMS »

Vérifier la clé GPG.

$ gpg --list-keys
...
pub 4096R/C56945AE 2018-04-09
uid                Nicolas Kovacs <info@microlinux.fr>
uid                [jpeg image of size 15912]
sub 4096R/D8190FE0 2018-04-09

Exporter la clé publique vers un fichier texte.

$ gpg --export -a 'info@microlinux.fr' > RPM-GPG-KEY-microlinux

Importer la clé publique vers la base de données RPM.

$ sudo rpm --import RPM-GPG-KEY-microlinux

Vérifier la liste des clés GPG publiques dans la base de données RPM.

$ rpm -q gpg-pubkey
gpg-pubkey-f4a80eb5-53a7ff4b
gpg-pubkey-352c64e5-52ae6884
gpg-pubkey-baadae52-49beffa4
gpg-pubkey-c56945ae-5acb6997 <== empreinte de ma clé publique

Ensuite, éditer un fichier ~/.rpmmacros comme ceci.

%_topdir /home/kikinovak/rpmbuild
%packager Nicolas Kovacs <info@microlinux.fr>
%dist .el7.microlinux
%_signature gpg
%_gpg_path /home/kikinovak/.gnupg
%_gpg_name Nicolas Kovacs
%_gpgbin /usr/bin/gpg

Construction d’un paquet RPM

Dans l’exemple, je pars d’un paquet SRPM (Source RPM) récupéré sur le portail http://rpm.pbone.net. , en l’occurrence plank-0.10.1-1.fc22.src.rpm. Dans la pratique quotidienne, on partira souvent d’un SRPM de Fedora que l’on recompilera pour l’intégrer à CentOS.

rpm.pbone.net

Créer un répertoire ~/SRPMS pour y ranger les paquets source téléchargés.

$ mkdir -v ~/SRPMS
mkdir: création du répertoire « /home/kikinovak/SRPMS »

Si l’on part d’un paquet source SRPM, on peut utiliser rpm en tant que simple utilisateur, et la commande rpm -ivh installera les fichiers au bon endroit.

$ rpm -ivh plank-0.10.1-1.fc22.src.rpm
attention : plank-0.10.1-1.fc22.src.rpm: Entête V3 
RSA/SHA256 Signature, clé ID 8e1431d5: NOKEY
Mise à jour / installation...
1:plank-0.10.1-1.fc22 ################################# [100%]

Voici comment se présentent les fichiers installés.

$ tree ~/rpmbuild/
/home/kikinovak/rpmbuild/
├── BUILD
├── RPMS
├── SOURCES
│   ├── 000_patentpatch.patch
│   └── plank-0.10.1.tar.xz
├── SPECS
│   └── plank.spec
└── SRPMS
  • le code source “vanillaplank-0.10.1.tar.xz
  • les instructions de compilation plank.spec
  • un patch 000_patentpatch.patch

Alternativement – si l’on ne trouve pas de paquet SRPM – on peut récupérer le fichier .spec pour le placer dans ~/rpmbuild/SPECS. Puis on récupère les sources correspondantes, et on les range manuellement dans le répertoire ~/rpmbuild/SOURCES.

Avant de tenter un premier essai, je vais quand-même installer un minimum d’outils de compilation.

# yum install gcc make

À cette étape, on peut éventuellement éditer le fichier .spec pour y apporter des modifications. En l’occurrence, j’annule l’application d’un patch qui désactive une fonctionnalité soumise à un brevet.

%prep
%setup -q
# %patch0 (commenter)

Je lance une première tentative de compilation.

$ cd ~/rpmbuild/SPECS/
$ rpmbuild -ba --clean plank.spec

Quelques remarques sur les options utilisées.

  • L’option -ba construit les paquets binaires et les sources (RPM et SRPM).
  • L’option --clean nettoie l’arborescence de construction.

Cette première tentative se solde par une erreur, étant donné qu’il manque un certain nombre de dépendances.

rpmbuild-deps

J’installe les dépendances de construction, qui sont fournies par les dépôts [base], [epel] et [nux-dextop].

Je relance rpmbuild, et au terme de la compilation, j’obtiens ceci.

$ tree ~/rpmbuild/
/home/kikinovak/rpmbuild/
├── BUILD
├── BUILDROOT
├── RPMS
│   └── x86_64
│       ├── plank-0.10.1-1.el7.microlinux.x86_64.rpm
│       ├── plank-debuginfo-0.10.1-1.el7.microlinux.x86_64.rpm
│       └── plank-devel-0.10.1-1.el7.microlinux.x86_64.rpm
├── SOURCES
│   ├── 000_patentpatch.patch
│   └── plank-0.10.1.tar.xz
├── SPECS
│   └── plank.spec
└── SRPMS
    └── plank-0.10.1-1.el7.microlinux.src.rpm

Il ne me reste plus qu’à installer les paquets RPM résultants avec rpm -ivh ou yum localinstall.

Signer un paquet

Une fois que j’ai construit mes paquets, je peux les signer comme ceci.

$ rpm --addsign untex-1.3-3.1.el7.microlinux.x86_64.rpm
Entrez la phrase de passe : 
Phrase de passe bonne.
untex-1.3-3.1.el7.microlinux.x86_64.rpm:

L’option --checksig me permet de vérifier la signature d’un paquet.

$ rpm --checksig untex-1.3-3.1.el7.microlinux.x86_64.rpm
untex-1.3-3.1.el7.microlinux.x86_64.rpm: rsa sha1 (md5) pgp md5 OK

Il est tout à fait possible de signer plusieurs paquets “à la louche”.

$ rpm --addsign recoll-*
Entrez la phrase de passe :
Phrase de passe bonne.
recoll-1.23.1-2.el7.microlinux.x86_64.rpm:
recoll-debuginfo-1.23.1-2.el7.microlinux.x86_64.rpm:
recoll-kio-1.23.1-2.el7.microlinux.x86_64.rpm:
Publié dans CentOS, Documentation Microlinux | Marqué avec , | 5 commentaires

Virtualisation avec KVM sous CentOS

Virtualisation KVMJ’ai parfois besoin de construire des paquets pour différentes distributions Linux, avec des versions et des architectures qui peuvent également varier. Les solutions multiboot ne sont pas ce qu’il y a de plus simple à mettre en oeuvre, sans oublier le manque de flexibilité. J’ai également testé la virtualisation avec VirtualBox, qui pose d’autres contraintes. La meilleure solution consiste ici à mettre en place une série de machines virtuelles avec Qemu/KVM et LibVirt.

Dans cet article, je décris la mise en place d’un hôte KVM (également appelé hyperviseur) dans mon réseau local et d’une série de machines virtuelles installées sur cet hôte. Nous allons éviter de nous compliquer la vie avec les myriades d’options en ligne de commande de Qemu. Au lieu de cela, nous allons profiter des fonctionnalités de LibVirt et de Virt-Manager, qui nous faciliteront considérablement la tâche.

Il serait aisé d’écrire un ou même plusieurs gros livres sur le sujet de la virtualisation avec KVM, ce qui a d’ailleurs été fait. Ce tutoriel est conçu avant tout pour une prise en main de KVM par la pratique.

Prérequis

La virtualisation doit être activée dans le BIOS. Sur mon serveur HP, l’option correspondante est bien cachée dans le sous-menu Security > System Security > Virtualization Technology du BIOS. Dans certains cas, l’option peut même se trouver dans le sous-menu Power. Dans un cas comme dans l’autre, il faudra choisir Enable.

Pour que Qemu/KVM ait des performances acceptables, il faut vérifier que notre processeur soit compatible avec les extensions de virtualisation. Sous Linux, il est facile de vérifier cela avec la commande suivante.

$ egrep '^flags.*(vmx|svm)' /proc/cpuinfo >/dev/null && echo OK
OK

Le serveur peut donc supporter la virtualisation hardware.

Attention tout de même, ça ne marche pas sur une Dedibox SC de chez Online. Le processeur VIA affiche des capacités KVM sans en être capable dans la pratique. Cette anomalie fâcheuse m’a coûté un après-midi entier à m’arracher les cheveux face à une série de plantages inexplicables.

Pour éviter d’avoir à saisir des mots de passe à répétition, il est fortement recommandé de configurer l’authentification par clé SSH depuis le poste client vers le serveur KVM.

$ ssh-copy-id -i .ssh/id_rsa.pub root@nestor.microlinux.lan

Installation côté serveur

CentOS fournit certes un groupe de paquets Virtualization, mais je préfère voyager léger, et je n’installe que le minimum syndical sur le serveur.

# yum install qemu-kvm libvirt

Un redémarrage n’est pas vraiment nécessaire, mais je le fais quand-même pour voir si le module kvm est chargé automatiquement.

# lsmod | grep kvm
kvm_amd                64937  0 
kvm                   554609  1 kvm_amd
irqbypass              13503  1 kvm

Bien évidemment, rien n’empêche de charger le module manuellement.

# modprobe kvm

Lancement initial

Activer et démarrer libvirtd et afficher l’état du démon.

# systemctl enable libvirtd
# systemctl start libvirtd
# systemctl status libvirtd

Le journal affiche une erreur quant à l’interface réseau utilisée. Sans trop rentrer dans les détails, nous devons remédier à cela en créant un pont.

Création d’un bridge

Dans la configuration par défaut, mon serveur dispose de deux interfaces réseau.

  • enp2s0 côté Internet
  • enp3s0 côté réseau local

Pour créer un pont (ou bridge), je vais d’abord éditer /etc/sysconfig/network-scripts/ifcfg-enp3s0.

DEVICE=enp3s0
TYPE=Ethernet
ONBOOT=yes
BRIDGE=virbr0

Ce bridge recevra la configuration de l’ancienne interface enp3s0. Pour ce faire, il faudra créer un fichier /etc/sysconfig/network-scripts/ifcfg-virbr0 et l’éditer comme ceci.

DEVICE=virbr0
TYPE=Bridge
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.2.1
NETMASK=255.255.255.0

Étant donné que l’interface réseau côté LAN s’appelle désormais virbr0 et non plus enp3s0, il faudra modifier la configuration du serveur en conséquence, en l’occurrence le pare-feu et la configuration de Dnsmasq.

J’ai supprimé le pare-feu à la sauce Red Hat firewalld, que j’ai remplacé par un simple script iptables. Ce script sera donc modifié comme ceci.

#!/bin/sh
#
# firewall.sh

# Commandes
IPT=/usr/sbin/iptables
MOD=/usr/sbin/modprobe
SYS=/usr/sbin/sysctl
SERVICE=/usr/sbin/service

# Internet
IFACE_INET=enp2s0

# Réseau local
IFACE_LAN=virbr0
IFACE_LAN_IP=192.168.2.0/24

Je procède de même avec Dnsmasq et je renomme l’interface côté réseau local.

# /etc/dnsmasq.conf
domain-needed
bogus-priv
interface=virbr0
dhcp-range=192.168.2.100,192.168.2.200,24h

À partir de là, je peux redémarrer le serveur.

Régler un problème avec rpcbind

Le redémarrage se solde par l’erreur suivante.

# systemctl --failed
  UNIT           LOAD   ACTIVE SUB    DESCRIPTION
● rpcbind.socket loaded failed failed RPCbind Server Activation 
  Socket

Après une recherche Google, le problème s’avère être lié à la désactivation de l’IPv6 sur mon serveur. La solution consiste ici à forcer la reconstruction du disque mémoire initial.

# dracut -f

Au prochain redémarrage, le problème semble être résolu.

# systemctl status
● nestor
    State: running

Préparer les images ISO

Sur le serveur, on utilisera principalement des fichiers ISO pour installer les machines virtuelles. Dans la configuration par défaut, ces images sont censées être rangées dans le répertoire /var/lib/libvirt/images. On pourra les attribuer à l’utilisateur système qemu et au groupe système du même nom.

# ls -lh /var/lib/libvirt/images/
total 18G
-rw-r--r--. 1 qemu qemu 2,3G 11 mai 11:32 slackware-14.0.iso
-rw-r--r--. 1 qemu qemu 3,6G 11 mai 11:34 slackware-14.1.iso
-rw-r--r--. 1 qemu qemu 2,7G 11 mai 11:34 slackware-14.2.iso
-rw-r--r--. 1 qemu qemu 2,3G 11 mai 11:35 slackware64-14.0.iso
-rw-r--r--. 1 qemu qemu 3,7G 11 mai 11:36 slackware64-14.1.iso
-rw-r--r--. 1 qemu qemu 2,6G 11 mai 11:37 slackware64-14.2.iso

Installation côté client

Le serveur ne dispose pas d’interface graphique, et nous allons éviter de nous compliquer la vie en gérant les machines virtuelles en ligne de commande. Au lieu de cela, nous allons confortablement piloter Qemu/KVM en mode graphique depuis un poste client tournant sous CentOS 7 et muni de l’environnement de bureau KDE. Virt-Manager constitue sans doute l’interface la plus confortable.

# yum install virt-manager

Créer une machine virtuelle

Démarrer le gestionnaire de machines virtuelles.

Configurer une connexion à l’hyperviseur via Fichier > Ajouter une connexion. Dans mon réseau, la connexion s’établit depuis ma station de travail.

La connexion à l’hyperviseur est établie.

Un clic droit sur l’hôte permet de créer une nouvelle machine virtuelle.

Pour installer notre machine virtuelle, nous utiliserons un fichier ISO rangé sur le serveur.

Nous choisissons l’image ISO dans la liste des fichiers disponibles.

Slackware Linux ne figure pas dans la liste des systèmes d’exploitation. Je garde donc la dénomination Generic.

Je définis la quantité de RAM et le nombre de processeurs pour ma machine virtuelle.

Je procède de même pour l’espace disque disponible.

La fenêtre subséquente me permet de choisir un nom pour ma machine virtuelle. Je prends soin de cocher Personnaliser la configuration avant l’installation pour peaufiner quelques détails importants. Le pont virbr0 constituera l’interface réseau partagée entre l’hôte et la machine virtuelle.

La vue d’ensemble sur la configuration de la machine virtuelle s’affiche.

Je spécifie le périphérique virtio pour la carte réseau. J’ai également la possibilité de personnaliser l’adresse MAC de la carte réseau.

Je remplace la carte vidéo QXL définie par défaut par un modèle VGA.

Une astuce consiste ici à ajouter une tablette graphique à la machine virtuelle, ce qui évite les mouvements de souris saccadés et aléatoires si jamais on utilise une interface graphique.

Il ne reste plus qu’à cliquer sur Commencer l’installation en haut à gauche de la fenêtre.

Si l’on utilise KVM en mode plein écran, la combinaison de touches [Ctrl]+[Alt] permet de récupérer le focus de la souris.

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

Personnaliser GDM sous CentOS

X11GDM (GNOME Display Manager) est le gestionnaire de connexion par défaut de Red Hat Enterprise Linux et CentOS pour les environnements de bureau officiellement supportés. Il s’affiche donc non seulement pour le bureau GNOME, il se substitue également à KDM ou SDDM lorsqu’on opte pour un bureau KDE.

Il m’arrive d’avoir à personnaliser ce composant du système, pour remplacer le logo du distributeur par celui de mon entreprise, ou pour désactiver l’affichage de la liste des utilisateurs lorsque ceux-ci sont trop nombreux. Étant donné que la personnalisation de certains composants de GNOME est un peu particulière, j’en ai fait un petit article pour documenter la configuration.

Afficher un logo personnalisé

Dans la configuration par défaut, GDM affiche le logo de CentOS.

GNOME Display Manager

Si l’on souhaite remplacer le logo du distributeur par un logo personnalisé, il faut d’abord créer un fichier /etc/dconf/profile/gdm en l’éditant comme ceci.

user-db:user
system-db:gdm
file-db:/usr/share/gdm/greeter-dconf-defaults

Ensuite, je vais créer un deuxième fichier /etc/dconf/db/gdm.d/01-logo que je vais éditer comme ceci.

[org/gnome/login-screen]
logo='/usr/share/pixmaps/microlinux-logo.png'

Pour le format du logo, on a le choix entre tous les formats image courants et moins courants comme le PNG, le JPG, le SVG et beaucoup d’autres encore. En ce qui concerne la taille, l’image est automatiquement redimensionnée proportionnellement pour une hauteur de 48 pixels.

Il ne me reste plus qu’à mettre à jour la base de données système pour prendre en compte les modifications.

# dconf update

Et voilà comment ça se présente dorénavant.

GNOME Display Manager

Désactiver la liste des utilisateurs

Sur une installation dans une école ou une entreprise, avec une authentification centralisée et un nombre important d’utilisateurs, il est conseillé de désactiver l’affichage de la liste des utilisateurs.

GNOME Display Manager

Là encore, il faut d’abord passer par le fichier /etc/dconf/profile/gdm qu’on a vu tout à l’heure. Si vous ne l’avez pas créé pour la personnalisation du logo, il va falloir le faire maintenant.

user-db:user
system-db:gdm
file-db:/usr/share/gdm/greeter-dconf-defaults

Ensuite, créer un fichier /etc/dconf/db/gdm.d/00-login-screen en l’éditant comme ceci.

[org/gnome/login-screen]
# Ne pas afficher la liste des utilisateurs
disable-user-list=true

Là aussi, il faut mettre à jour la base de données du système pour prendre en compte les modifications.

# dconf update

À la prochaine déconnexion, GDM demandera à l’utilisateur de fournir son identifiant.

GNOME Display Manager

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

Configurer un client NIS sous CentOS

NISVoici le quatrième volet dans notre série d’articles sur l’authentification centralisée. Dans les deux premiers articles sur NFS, nous avons décrit le partage (ou l’exportation) des répertoires utilisateur du serveur vers le ou les postes clients. Ensuite, nous avons abordé la mise en place d’un serveur NIS pour stocker les données d’authentification des utilisateurs. À présent, nous allons décrire la configuration d’un poste client de manière à ce que l’authentification ne se fasse pas localement, mais sur le serveur NIS.

Installation

Le paquet ypbind est fourni par les dépôts officiels de Red Hat et CentOS.

# yum install ypbind

Configuration

Le nom de domaine NIS sera défini comme sur le serveur.

# ypdomainname microlinux.lan

Là aussi, on le renseignera également dans /etc/sysconfig/network.

# /etc/sysconfig/network
NISDOMAIN="microlinux.lan"

L’outil authconfig permet d’indiquer au système l’endroit où il devra chercher les informations pour authentifier les utilisateurs.

# authconfig --enablenis --nisdomain=microlinux.lan \
  --nisserver=amandine.microlinux.lan --disablemkhomedir --update

Comme son nom le suggère, l’option --disablemkhomedir désactive la création à la volée des répertoires utilisateur. Effectivement, nous créons les utilisateurs sur le serveur, et les répertoires utilisateur respectifs sont ensuite partagés (ou exportés) via NFS.

Mise en service

Il ne reste plus qu’à activer et démarrer le client NIS.

# systemctl enable ypbind
# systemctl start ypbind

Authentification

À partir de là, je peux me connecter au poste client. Sur le serveur amandine.microlinux.lan, j’ai créé un utilisateur centos que j’ai ajouté à la base de données NIS (cd /var/yp && make).

J’essaie maintenant de me connecter en tant qu’utilisateur centos sur le client NIS raymonde.microlinux.lan.

$ ssh centos@raymonde
centos@raymonde's password:
Last login: Sat Mar 31 08:54:05 2018

J’affiche le nom du serveur NIS.

$ ypwhich
amandine.microlinux.lan

Pour modifier mon mot de passe, je pourrai utiliser la commande yppasswd.

$ yppasswd
Changing NIS account information for centos on 
amandine.microlinux.lan.
Please enter old password:
Changing NIS password for centos on amandine.microlinux.lan.
Please enter new password:
Please retype new password:

The NIS password has been changed on amandine.microlinux.lan.
Publié dans CentOS, Documentation Microlinux | Marqué avec , | Laisser un commentaire

Installer un serveur NIS sous CentOS

NISSur les systèmes Red Hat Enterprise Linux et dérivés, il existe une série de solutions pour mettre en place une authentification centralisée. Les grands classiques comme FreeIPA ou 389 Directory Server sont de véritables usines à gaz, dont la configuration et le débogage peuvent s’avérer assez complexes. Avant d’attaquer ces bestiaux, nous allons faire un petit voyage dans le temps et nous intéresser à une technologie considérée comme obsolète, mais qu’il est utile de connaître.

Présentation

NIS (Network Information Service) est l’ancêtre des systèmes d’authentification centralisée sur les systèmes unixoïdes. À l’origine, NIS est sorti sous le nom de Yellow Pages (YP, c’est-à-dire les Pages Jaunes), mais le nom avait déjà été déposé par British Telecom. Sun Microsystems a donc renommé son protocole en conséquence. Cet aperçu historique explique la nomenclature des commandes relatives à NIS, qui commencent toutes par yp. Techniquement, un serveur NIS sert avant tout à stocker les informations administratives du réseau, notamment les comptes utilisateurs et les groupes.

NIS est moins sécurisé que ses successeurs. Si nous l’abordons ici, c’est avant tout dans un but pédagogique. La configuration d’un serveur NIS nous permettra de nous faire la main sur un système d’authentification centralisée relativement simple à mettre en oeuvre.

Prérequis

Cet article constitue le troisième volet dans notre série sur la mise en place de profils itinérants avec une authentification centralisée. Dans le premier article, nous avons décrit la mise en place du serveur NFS. Le deuxième article était consacré à la configuration des postes clients. Pour la suite, nous devons donc disposer d’un partage NFS fonctionnel des répertoires utilisateurs.

Le serveur NIS requiert l’ouverture d’une série de ports dans le pare-feu.

  • le port 111 en TCP et en UDP pour rpcbind
  • le port 944 en TCP et en UDP pour ypserv
  • le port 945 en TCP et en UDP pour ypxfrd
  • le port 946 en udp pour yppasswdd

Installation

Le paquet ypserv est fourni par les dépôts officiels de Red Hat et CentOS.

# yum install ypserv

Configuration

Définir le nom de domaine NIS.

# ypdomainname microlinux.lan

Le domaine NIS devra également être renseigné dans /etc/sysconfig/network.

# /etc/sysconfig/network
GATEWAY=192.168.2.1
NISDOMAIN="microlinux.lan"

Toujours dans /etc/sysconfig/network, on va définir des ports statiques pour ypserv et ypxfrd.

# /etc/sysconfig/network
GATEWAY=192.168.2.1
NISDOMAIN="microlinux.lan"
YPSERV_ARGS="-p 944"
YPXFRD_ARGS="-p 945"

Le port statique pour le service yppasswdd peut être défini dans /etc/sysconfig/yppasswdd.

# /etc/sysconfig/yppasswdd
...
# Additional arguments passed to yppasswd
YPPASSWDD_ARGS="--port 946

Si le fichier /var/yp/securenets est vierge ou n’existe pas, NIS attend des requêtes de tous les réseaux. La première chose à faire pour sécuriser le serveur, c’est donc de spécifier une paire masque de sous-réseau / réseau dans ce fichier. Il s’agit là d’une sécurisation très sommaire, mais c’est déjà mieux que rien.

# /var/yp/securenets
255.0.0.0 127.0.0.0
255.255.255.0 192.168.2.0

Mise en service

À présent, on peut activer et démarrer les services NIS.

# systemctl enable ypserv ypxfrd yppasswdd
# systemctl start ypserv ypxfrd yppasswdd

Ensuite, on va initialiser la base de données NIS.

# /usr/lib64/yp/ypinit -m

At this point, we have to construct a list of the hosts which will 
run NIS servers. amandine.microlinux.lan is in the list of NIS 
server hosts.  Please continue to add the names for the other hosts,
one per line. When you are done with the list, type a <control D>.
        next host to add:  amandine.microlinux.lan
        next host to add:  [Ctrl]+[D]
The current list of NIS servers looks like this:

amandine.microlinux.lan

Is this correct?  [y/n: y]  [Y]
We need a few minutes to build the databases...
Building /var/yp/microlinux.lan/ypservers...
Running /var/yp/Makefile...
gmake[1]: Entering directory `/var/yp/microlinux.lan'
Updating passwd.byname...
Updating passwd.byuid...
Updating group.byname...
Updating group.bygid...
Updating hosts.byname...
Updating hosts.byaddr...
Updating rpc.byname...
Updating rpc.bynumber...
Updating services.byname...
Updating services.byservicename...
Updating netid.byname...
Updating protocols.bynumber...
Updating protocols.byname...
Updating mail.aliases...
gmake[1]: Leaving directory `/var/yp/microlinux.lan'

amandine.microlinux.lan has been set up as a NIS master server.

Now you can run ypinit -s amandine.microlinux.lan on all slave 
servers.

Il ne reste plus qu’à ajouter les utilisateurs du serveur à la base de données NIS.

# cd /var/yp
# make

La configuration des clients NIS fait l’objet d’un article à part.

 

Publié dans CentOS, Documentation Microlinux | Marqué avec , | 3 commentaires

Installer CentOS sur une carte PC Engines APU 2

PC Engines APU 2Un de mes clients m’a demandé récemment de lui installer une solution de monitoring et de filtrage web basée sur un pare-feu Linux tournant sous CentOS avec un proxy Squid transparent. J’ai déjà effectué des installations de ce genre au cours des dernières années. Côté hardware, je choisis le plus souvent du matériel serveur standard comme les HP Proliant ou Dell PowerEdge. Or, cette fois-ci, je me suis retrouvé confronté à une simple contrainte d’encombrement, étant donné qu’il fallait essayer de caser le tout dans un rack déjà passablement rempli de matériel.

Choix du matériel

Après avoir cherché un peu sur le web, je suis tombé sur les cartes mère de la marque PC Engines, commercialisées en France par Calexium. J’ai appelé cette entreprise, et je suis tombé sur Sébastien, un commercial/technicien extrêmement compétent, qui a pris le temps de tout m’expliquer de A à Z. Je tiens ici à le remercier pour sa gentillesse.

J’ai donc commandé une carte APU 2 munie d’un processeur AMD GX quatre coeurs, de 4 Go de RAM, de trois ports Ethernet Gigabit, de deux ports USB, d’un port SATA et d’un port série. Pour avoir quelque chose de fonctionnel, j’ai également commandé un disque dur 2,5″, un boîtier, une alimentation, un câble série et un adaptateur USB/série.

PC Engines APU 2

Je note au passage qu’initialement, j’avais voulu installer deux disques SATA 2,5″ pour les configurer en software RAID 1, et je me suis rendu compte un peu trop tard que la carte mère que j’ai commandée ne disposait que d’un seul port SATA. Si l’on souhaite disposer de deux ports SATA, il faut commander la carte APU 1 et spécifier le nombre de ports dans le menu déroulant au moment de la commande. Ce sera donc pour la prochaine fois.

Montage

Le matériel a été livré sans la moindre notice, ce qui m’a un peu surpris. Du coup j’ai cherché des infos sur le web, et je me suis inspiré de cette vidéo pour le montage.

De mémoire, voici ce que j’ai fait, dans l’ordre.

  1. Coller la pâte thermique sur le processeur.
  2. Coller la plaque de refroidissement sur le boîtier.
  3. Enlever les caches des ports Ethernet de la façade.
  4. Poser la carte mère délicatement à l’emplacement prévu.
  5. Visser la carte mère dans le boîtier (4 vis).
  6. Visser les deux barres de fixation sur le disque SATA 2,5″ (4 vis).
  7. Visser le disque dur dans le boîtier (4 vis).
  8. Relier le disque dur au port SATA et à l’alimentation.

Voilà à quoi ça ressemble une fois que c’est monté.

PC Engines APU 2

Configurer le port série

Port sériePour l’instant, le port série est le seul moyen de communiquer avec la machine. Dans un premier temps, je branche mon convertisseur USB/série à ma station de travail, et je la relie au port série du routeur. Mon convertisseur apparaît en tant que /dev/ttyUSB0.

[root@alphamule:~] # dmesg | grep tty
... console [tty0] enabled
... 00:03: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
... 0000:00:16.3: ttyS1 at I/O 0x2180 (irq = 17) is a 16550A
... usb 2-1.7: ch341-uart converter now attached to ttyUSB0

Pour communiquer avec le port série, j’utiliserai Minicom, un programme de contrôle de modem et d’émulation de terminal pour systèmes Unixoïdes.

[root@alphamule:~] # yum install minicom

Je bascule ma console vers l’anglais pour rendre l’affichage de Minicom plus lisible.

[root@alphamule:~] # LANG=en_US.utf8 && export LANG

Je lance la configuration de Minicom et je me rends dans le menu Serial port setup.

[root@alphamule:~] # minicom -s
  +-----[configuration]------+
  | Filenames and paths      |
  | File transfer protocols  |
  | Serial port setup        |
  | Modem and dialing        |
  | Screen and keyboard      |
  | Save setup as dfl        |
  | Save setup as..          |
  | Exit                     |
  | Exit from Minicom        |
  +--------------------------+

Dans la configuration par défaut, Minicom est censé communiquer avec le périphérique /dev/modem.

+-------------------------------------------------------------+
| A -    Serial Device      : /dev/modem                      |
|                                                             |
| C -   Callin Program      :                                 |
| D -  Callout Program      :                                 |
| E -    Bps/Par/Bits       : 115200 8N1                      |
| F - Hardware Flow Control : Yes                             |
| G - Software Flow Control : No                              |
|                                                             |
|    Change which setting?                                    |
+-------------------------------------------------------------+

Pour changer de périphérique, choisir l’option A - Serial Device et remplacer /dev/modem par /dev/ttyUSB0.

+-------------------------------------------------------------+
| A -    Serial Device      : /dev/ttyUSB0                    |
|                                                             |
| C -   Callin Program      :                                 |
| D -  Callout Program      :                                 |
| E -    Bps/Par/Bits       : 115200 8N1                      |
| F - Hardware Flow Control : Yes                             |
| G - Software Flow Control : No                              |
|                                                             |
|    Change which setting?                                    |
+-------------------------------------------------------------+

Confirmer par Entrée, puis enregistrer la configuration en optant pour Save setup as dfl. Quitter le menu de configuration avec Exit (et non pas Exit from Minicom). On se retrouve alors dans la console de Minicom.

Welcome to minicom 2.6.2

OPTIONS: I18n
Compiled on Jun 10 2014, 03:20:53.
Port /dev/ttyUSB0, 10:21:53

Press CTRL-A Z for help on special keys

Pour naviguer dans Minicom, il suffit d’appuyer sur [Ctrl]+[A], puis [Z] pour afficher le menu principal. La touche [X] permet alors de quitter Minicom, la commande minicom invoquée sans arguments permet de relancer l’application.

Lancer l’installation de CentOS

Logo CentOSJe ne détaille pas ici la confection d’une clé USB d’installation de CentOS, qui est une tâche triviale. Voici ce qu’il faut faire tout en gardant l’affichage de Minicom dans le terminal du PC.

  1. S’assurer que le port série est bien relié au convertisseur USB/série du PC.
  2. Brancher un câble Ethernet relié au switch local à la prise juste à côté du port série.
  3. Insérer la clé USB d’installation de CentOS.
  4. Brancher l’alimentation à côté des prises USB du routeur.

Si tout se passe bien, on apercevra le message suivant dans la console de Minicom.

PCEngines apu2
coreboot build 20170228
4080 MB ECC DRAM

SeaBIOS (version rel-1.10.0.1)

Press F10 key now for boot menu

Et quelques secondes plus tard, c’est le menu de l’installateur de CentOS qui s’affiche en mode texte.

+--------------------------------------------------------------+
|                        CentOS Linux 7                        |
|--------------------------------------------------------------|
|                                                              |
|                                                              |
| Install CentOS Linux 7                                       |
| Test this media & install CentOS Linux 7                     |
|                                                              |
| Troubleshooting                                            > |
|                                                              |
|                                                              |
|                                                              |
|   Press Tab for full configuration options on menu items.    |
|                                                              |
|                                                              |
+---------------Automatic boot in 56 seconds...----------------+
  1. Appuyer sur [Tab] pour accéder aux paramètres de démarrage.
  2. Supprimer les deux dernières options rd.live.check quiet en appuyant sur la touche [Backspace].
  3. Ajouter les options inst.vnc inst.vncpassword=centos edd=off.

Si tout se passe bien, Minicom nous affiche le démarrage de l’installateur comme ceci.

Loading vmlinuz........
Loading initrd.img....................................ready.

Les deux options inst.vnc inst.vncpassword=centos ont lancé un serveur VNC dans le routeur, qui nous permettra de nous connecter à l’installateur graphique depuis la station de travail. Le problème, c’est que l’affichage de l’installateur a disparu depuis le message initial, et nous ne savons plus où le joindre.

Dans ce cas, il suffit de faire une simple recherche avec nmap dans le réseau local.

[root@alphamule:~] # nmap -sP 192.168.2.* | grep scan
Nmap scan report for nestor.microlinux.lan (192.168.2.1)
Nmap scan report for raymonde.microlinux.lan (192.168.2.4)
Nmap scan report for amandine.microlinux.lan (192.168.2.5)
Nmap scan report for 192.168.2.178
Nmap scan report for hp-officejet.microlinux.lan (192.168.2.252)
Nmap scan report for wifi.microlinux.lan (192.168.2.254)
Nmap scan report for alphamule.microlinux.lan (192.168.2.2)
Nmap done: 256 IP addresses (7 hosts up) scanned in 2.03 seconds

Je procède par élimination, et je me dis que l’adresse 192.168.2.178, c’est la seule que je ne connais pas dans le réseau. Il y a donc de fortes chances à ce que ce soit mon routeur. Voyons ça de plus près.

[root@alphamule:~] # nmap -sP 192.168.2.178
Starting Nmap 6.40 ( http://nmap.org ) at 2018-03-28 11:10 CEST
Nmap scan report for 192.168.2.178
Host is up (0.00021s latency).
MAC Address: 00:0D:B9:47:7D:48 (PC Engines GmbH)
Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds

Effectivement, il s’agit bien de mon routeur. Voyons si le serveur VNC est accessible.

[root@alphamule:~] # nmap 192.168.2.178
Starting Nmap 6.40 ( http://nmap.org ) at 2018-03-28 11:13 CEST
Nmap scan report for 192.168.2.178
Host is up (0.00015s latency).
Not shown: 998 closed ports
PORT     STATE SERVICE
5901/tcp open  vnc-1
6001/tcp open  X11:1
MAC Address: 00:0D:B9:47:7D:48 (PC Engines GmbH)
Nmap done: 1 IP address (1 host up) scanned in 0.19 seconds

À partir de là, je lance un client VNC sur ma station de travail pour me connecter à l’installateur. Vu que je tourne sous KDE, j’utilise KRDC. Si vous êtes sous GNOME ou Xfce, vous utiliserez sans doute Remmina ou Vinagre ou n’importe quel autre client VNC, peu importe.

Je me connecte au serveur VNC à l’adresse 192.168.2.178:1.

CentOS installation VNC

Étant donné que la machine se situe dans le réseau local, je peux opter pour une connexion de qualité élevée. Ce n’est pas la peine de mémoriser le mot de passe, étant donné que nous y accédons une seule fois.

CentOS installation VNC

Ici, il faut saisir le mot de passe que nous avons défini un peu plus haut, c’est-à-dire centos. Notez au passage que je me suis tapé la tête sur le clavier pendant un bon moment avant de me rendre compte que le mot de passe pour le serveur VNC de l’installateur doit impérativement comprendre entre 6 et 8 caractères. J’ai fini par tomber sur cette limitation dans la documentation Red Hat.

CentOS installation VNC

Si tout s’est bien passé, nous nous retrouvons dans l’installateur graphique de CentOS.

CentOS installation VNC

À partir de là, nous pouvons installer notre routeur comme n’importe quel autre matériel, en utilisant les fonctionnalités de l’installateur graphique. Pour les détails de cette opération, vous pourrez consulter cet article.

Configuration post-installation

À l’issue du redémarrage initial, il ne faut pas oublier d’enlever la clé USB pour démarrer sur le système installé.

Dans la configuration par défaut, notre nouveau système n’offre pas d’accès via le port série. Il faut donc invoquer à nouveau nmap comme nous l’avons fait plus haut.

[root@alphamule:~] # nmap -sP 192.168.2.* | grep scan
Nmap scan report for nestor.microlinux.lan (192.168.2.1)
Nmap scan report for raymonde.microlinux.lan (192.168.2.4)
Nmap scan report for amandine.microlinux.lan (192.168.2.5)
Nmap scan report for 192.168.2.178
Nmap scan report for hp-officejet.microlinux.lan (192.168.2.252)
Nmap scan report for wifi.microlinux.lan (192.168.2.254)
Nmap scan report for alphamule.microlinux.lan (192.168.2.2)
Nmap done: 256 IP addresses (7 hosts up) scanned in 2.03 seconds

L’adresse IP attribuée est toujours la même, et je peux me connecter en SSH.

[root@alphamule:~] # ssh root@192.168.2.178

Pour accéder à la console via le port série, il faut modifier le chargeur de démarrage GRUB en éditant /etc/default/grub. Voici une série d’options qui vont bien.

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=false
GRUB_TERMINAL_OUTPUT="serial console"
GRUB_SERIAL_COMMAND="serial \
                     --unit=0 \
                     --speed=115200 \
                     --word=8 \
                     --parity=no \
                     --stop=1"
GRUB_CMDLINE_LINUX="nomodeset \
                    quiet \
                    edd=off \
                    console=ttyS0,115200n8"
GRUB_DISABLE_RECOVERY="true"

Prendre en compte les modifications.

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

À partir du prochain redémarrage, on pourra se connecter au routeur uniquement via le port série avec Minicom. Voilà à quoi cela ressemble dans la console de ma station de travail.

Console Minicom

Publié dans CentOS, Documentation Microlinux | Marqué avec , , , | 5 commentaires

Configurer un client NFS sous CentOS 7

NFSDans notre précédent article, nous avons décrit la mise en place d’un serveur NFS comme première brique logicielle dans la configuration d’un réseau local avec des profils itinérants et une authentification centralisée. Passons maintenant à la deuxième brique, le montage des partages NFS sur les postes clients.

Prérequis

Le serveur et les postes clients doivent impérativement être synchronisés via NTP, faute de quoi on peut s’attendre à toute une série de dysfonctionnements bizarres.

# ntpq -p
  remote            refid st t when poll reach delay offset jitter
===================================================================
*amandine.microl 95.81.173.155 3 u 24 64 377 0.134 -86.943 144.533
 LOCAL(0)        .LOCL.       10 l 31 64 377 0.000 0.000 0.000

Même si ce n’est pas strictement nécessaire, c’est une bonne idée de démarrer les clients en mode console par défaut, le temps de tout mettre en place.

# systemctl set-default multi-user.target

Installation

Installer la panoplie d’outils NFS et leurs dépendances.

# yum install nfs-utils

Si l’on a désactivé l’IPv6 sur le serveur, il faut impérativement reconstruire le disque mémoire initial, sous peine de se retrouver avec un service RPC (Remote Procedure Call) qui refuse obstinément de démarrer.

# dracut -f -v

Pour plus de détails, consulter les explications sur cette page.

Configuration

Renseigner le domaine local dans /etc/idmapd.conf :

[General]
#Verbosity = 0
# The following should be set to the local NFSv4 domain name
# The default is the host's DNS domain name.
Domain = microlinux.lan

Gestion

Activer et démarrer le service RPC.

# systemctl enable rpcbind
# systemctl start rpcbind

Montage manuel des partages NFS

Vérifier si les points de montage /home et /data sont bien vides.

# ls /home
# ls /data

Monter les partages NFS à la main.

# mount -t nfs4 amandine.microlinux.lan:/home /home
# mount -t nfs4 amandine.microlinux.lan:/data /data
  • L’option -t nfs4 n’est pas strictement nécessaire. La commande mount comprendra qu’il s’agit d’un partage NFS.
  • Le nom d’hôte du serveur (amandine) peut très bien être invoqué sans le nom de domaine (microlinux.lan).

La syntaxe suivante est donc parfaitement valable.

# mount amandine:/home /home
# mount amandine:/data /data

Montage persistant des partages NFS

Vérifier le contenu de /home et de /data. Une fois que tout semble correct, on peut rendre le partage persistant en l’inscrivant dans /etc/fstab comme ceci.

amandine.microlinux.lan:/home /home nfs defaults,_netdev 0 0
amandine.microlinux.lan:/data /data nfs defaults,_netdev 0 0
  • L’option _netdev indique au système qu’il s’agit d’un disque réseau et qu’il doit au moins attendre d’être connecté pour le monter.
Publié dans CentOS, Documentation Microlinux | Marqué avec , | Laisser un commentaire

Installer un serveur NFS sous CentOS 7

NFSNFS (Network File System) est le système de fichiers en réseau “classique” des plateformes Unix, avec un fonctionnement client-serveur. Le serveur met à disposition des ressources pour les clients du réseau ou une partie du réseau. Les fichiers distants sont montés dans un répertoire et apparaissent comme un système de fichiers local. À partir de là, les utilisateurs clients accèdent en toute transparence aux fichiers partagés par le serveur, en parcourant les répertoires comme s’il s’agissait d’une arborescence locale.

Dans cet article, nous allons décrire la mise en place d’un serveur NFS sous CentOS 7. Le but ultime de cette opération sera la création de profils itinérants avec une authentification centralisée dans le réseau local. Notre serveur NFS constituera la première brique logicielle d’une telle configuration.

Prérequis

NFSv4 utilise le port 2049 en TCP. Il faut donc songer à ouvrir ce port dans le pare-feu.

Installation

Installer la panoplie d’outils NFS et leurs dépendances.

# yum install nfs-utils

Si l’on a désactivé l’IPv6 sur le serveur, il faut impérativement reconstruire le disque mémoire initial, sous peine de se retrouver avec un service RPC (Remote Procedure Call) qui refuse obstinément de démarrer.

# dracut -f -v

Pour plus de détails, consulter les explications sur cette page.

Configuration

Renseigner le domaine local dans /etc/idmapd.conf.

[General]
#Verbosity = 0
# The following should be set to the local NFSv4 domain name
# The default is the host's DNS domain name.
Domain = microlinux.lan

Voici les répertoires utilisateurs que je souhaite partager en lecture et en écriture.

# tree -d -L 1 /home/
/home/
|-- adebuf
|-- fbanester
|-- fteyssier
|-- jmortreux
`-- kikinovak

Par ailleurs, je dispose également d’une arborescence /data que je souhaite partager en lecture seule.

# tree -d -L 1 /data/
/data/
|-- audio
|-- iso
`-- video

Nous allons définir ces partages dans le fichier /etc/exports.

# /etc/exports
/data  192.168.2.0/24(ro,async,no_subtree_check) \
         *.microlinux.lan(ro,async,no_subtree_check)
/home  192.168.2.0/24(rw,async,no_subtree_check) \
         *.microlinux.lan(rw,async,no_subtree_check)
  • L’option ro monte le répertoire distant en lecture seule.
  • L’option rw monte le répertoire distant en lecture/écriture.
  • L’option async permet des écriture asynchrones, c’est-à-dire que le serveur n’attend pas l’écriture d’une requête précédente avant de répondre.
  • Sans trop rentrer dans les détails, l’option no_subtree_check neutralise la vérification des sous-répertoires, ce qui a de subtiles implications au niveau de la sécurité, mais peut améliorer la fiabilité dans certains cas.
  • La barre oblique inversée \ permet d’éviter les lignes à rallonge.
  • Attention à ne pas mettre d’espace entre la définition du réseau 192.168.2.0/24 et les options (rw,async).

Gestion

Activer et démarrer les services RPC et NFS.

# systemctl enable rpcbind
# systemctl enable nfs-server
# systemctl start rpcbind
# systemctl start nfs-server

La configuration des clients NFS fait l’objet d’un article à part.

Documentation

Publié dans CentOS, Documentation Microlinux | Marqué avec , , | 5 commentaires