RGPD, je te prends, je te retourne, …

Ces dernières semaines, j’ai fait la même chose qu’à peu près toutes les entreprises de France et de Navarre et même un peu partout en Europe. J’ai laissé tomber à peu près tout travail intelligent et productif pour mon entreprise. Au lieu de cela, je me farcis les menus détails du nouveau Règlement Européen de la Protection des Données.

Les Shadoks

Concrètement, je suis en train de pondre une déclaration de confidentialité pour mon blog. Le genre de bousin qui ressemble vaguement aux mises en garde sur l’utilisation des cookies, sauf que c’est à peu près cinquante fois plus long. Le genre de texte qu’on voit fleurir partout, tout le monde clique dessus, et l’utilisateur de base, ça lui en secoue une sans faire bouger l’autre.

Évidemment, l’idée de base derrière le RGPD est bonne. On a tous droit à la confidentialité des données, à une vie privée et toussa, même sur Internet. Le RGPD nous permettra donc de reprendre la main sur nos données. Enfin, ça c’est la théorie.

Malheureusement, les gens qui ont écrit cette loi sont des têtes d’oeuf qui vivent sur une autre planète. Et comme pour la loi du Data Dock, on retrouve toujours le même écart criant entre la théorie et la pratique.

Tous pareils sauf les multinationales

FacebookLe RGPD vaut de la même manière pour Facebook, Google & Amazon que pour une petite entreprise comme la mienne (dont je suis le gérant, le principal développeur, le support technique, le commercial et le service comptable tout-en-un). Or, Facebook, Google & Amazon ont les moyens d’embaucher le personnel nécessaire pour lire, comprendre et appliquer le RGPD dans toutes ses nuances. Les estimations diverses et variées vont à quelque chose comme 500 (cinq cents) heures de travail pour cette tâche.

Le RGPD s’en contrefiche royalement que vous soyez une micro-entreprise ou une multinationale. Certes, il aurait pu faire dépendre certains prérequis légaux d’une série de paramètres comme le chiffre d’affaires de l’entreprise, le volume des données gérées ou autre chose. Au lieu de cela, c’est tout le monde au même régime, les petits comme les grands. Allez hop, marche ou crève.

Qui en profite ?

  • les grands groupes ;
  • les avocats.

On connaît la chanson.

Implosion de l’usine à gaz RGPD

Rien qu’à voir la longueur du bousin, on comprend que c’est un texte écrit par des juristes pour des juristes. Pour une fois que je vois des gens aussi dingues que nous les informaticiens, je tire une révérence.

Alcool

En revanche, certains points sont techniquement impossibles à mettre en pratique. À titre d’exemple, parlons du droit à la suppression des données personnelles. Selon le contexte, c’est tout à fait envisageable, bien sûr.

Or, la loi stipule que ce droit comprend également les sauvegardes. Et là, l’administrateur système vous regarde comme s’il vous manquait quelques cases. Admettons que vous fassiez des instantanés quotidiens, hebdomadaires et mensuels de vos bases de données, comme on le fait à peu près tous. Dans ce cas, comment faire pour extraire un ou plusieurs jeux de données de ces sauvegardes ? Réponse courte : oubliez. C’est impossible. Revoyez votre copie, les gars.

Arrêtez le délire !

Je dois préciser quelque chose ici. En tant qu’immigré autrichien et fils d’immigré hongrois, je suis avant tout citoyen européen dans l’âme. J’ai assisté à la chute du mur de Berlin et du rideau de fer (en direct), et je suis convaincu de l’idée d’une Europe unie.

Ceci étant dit, les dix commandements de la Bible comptent quelque chose comme deux cent cinquante mots, alors que la Réglementation Européenne pour l’Importation des Caramels Mous en compte 22.568. Sans blague.

Bureaucratie

Soyons clairs, les gars. Je veux bien que les gens qui utilisent Internet bénéficient de la protection de leurs données personnelles. Mais de grâce, vous n’auriez pas pu faire ça de manière intelligente, en formulant une série de lois compréhensibles, compactes et utilisables au quotidien ? À lire vos logorrhées bureaucratiques rédigées en hexagonal, j’ai envie de vous taper dessus avec un Grévisse.

Je jette un oeil dans ma boule de cristal, et je vais vous dire ce qui va se passer dans les jours à venir. Des millions de sites web arboreront des déclarations à la mords-moi-le-noeud sur leur page d’accueil. Tout le monde va royalement s’en battre les couilles, personne ne les lira, et même si l’utilisateur qui n’a rien de mieux à faire s’amusait à les lire, il les comprendrait aussi peu que les gens qui les ont rédigées.

Et maintenant, de grâce, arrêtez de nous mettre des bâtons dans les roues et laissez-nous bosser.

 

Publié dans Divers | Marqué avec , | 12 commentaires

Comment j’ai choisi mon système d’exploitation

OSLe Moyen Âge et la Renaissance avaient leurs guerres de religion, où l’on avait tout loisir de partir en croisade pour fracasser allègrement le crâne de tous les incroyants et, plus généralement, de tous ceux qui avaient le malheur de ne pas souscrire à la même religion. De nos jours, les guerres saintes et autres contrariétés ne s’organisent plus que de façon épisodique et sporadique. Le phénomène semble plutôt s’être déplacé vers les forums d’utilisateurs de systèmes d’exploitation, à en juger par le ton qui règne parfois entre individus de croyances différentes ou, pire encore, entre individus de chapelles voisines, mais dont les obédiences divergent un tant soit peu.

TrollTentez l’expérience. Inscrivez-vous à un forum d’utilisateurs Linux ou BSD (le Web en regorge) et posez la question anodine : “Quel est le meilleur système ? Ubuntu ? Debian ? Fedora ? OpenSUSE ? Arch ? Gentoo ? Red Hat Enterprise Linux ? FreeBSD ? CentOS ? Slackware ? OpenBSD ? Alpine ? Mageia ? Mint ? Que pouvez-vous me conseiller ?” Laissez macérer quelques heures, voire quelques jours, et appréciez le résultat.

BestAu vu des articles de blog divers et variés qui fleurissent régulièrement sur la toile en postulant catégoriquement que tel ou tel système est la “meilleure distribution Linux” ou le “meilleur système BSD”, j’ai envie d’ajouter mon grain de sel, en adoptant une attitude plutôt descriptive que prescriptive.

Logo CommodoreJ’utilise des ordinateurs depuis mon tout premier processeur 8080 monoplatine, que je programmais en Assembler sur un clavier hexadécimal. Oui, je suis un vieux de la vieille. Ma première “vraie” machine, c’était un Commodore VC-20, acheté en 1983 avec l’argent que j’avais gagné avec mon premier boulot d’été à seize ans, deux mois de plonge dans un hôtel à Vienne en Autriche. J’éprouve une certaine fierté complètement irrationnelle à avoir commencé à coder sur la même machine que Linus Torvalds dans le temps.

FloppyPar la suite, j’ai remplacé la fameuse “boîte à pains” de Commodore par un IBM PC-XT, qui tournait sous DOS. Après DOS, c’était les années Windows, avec Windows 3.1 et Windows 95 sur un IBM PC 386, et Windows 98 sur un Pentium-II 233. En 2001, j’étais tellement frustré de la piètre qualité des systèmes Microsoft que j’ai définitivement quitté l’univers Microsoft juste avant la sortie de Windows XP pour ne plus jamais y retoucher.

Read The Fucking ManualMa première expérience avec un autre système que Microsoft Windows, ça a été un CD-Rom d’installation de Slackware Linux 7.1 acheté à la librairie Sauramps à Montpellier. Pour me familiariser avec ce système, je me suis inscrit à la liste de diffusion du site BasicLinux.net, une série de cours en ligne gratuits prodigués par des administrateurs Unix/Linux chevronnés. En rétrospective, c’était un peu comme si j’avais voulu faire un peu de sport pour me mettre en forme et que je m’étais inscrit à un stage commando de la Légion Étrangère. Le projet BasicLinux.net n’existe malheureusement plus.

GentooDepuis mes débuts sous Linux, j’ai lu pas mal de bouquins techniques sur ce système, et j’en ai même écrit quelques uns. J’ai eu l’occasion de me familiariser avec toutes les distributions courantes et moins courantes, soit dans le cadre de mon travail, ou alors par simple curiosité. J’ai utilisé Gentoo quand il fallait encore partir d’une installation stage1 et que la compilation d’un bureau KDE complet durait près d’une semaine sur mon vieux coucou. J’ai fait tourner Arch en production dans notre réseau de médiathèques en 2006, jusqu’à ce qu’une mise à jour calamiteuse rende tous nos postes clients inutilisables. J’ai même réussi à faire booter une LFS minimale, et j’étais convaincu que c’était là le système idéal pour les gens qui adorent construire des cathédrales avec des allumettes ou qui mettent en bouteille des maquettes de grands voiliers pour se changer les idées.

ChecklistJe me rends compte aujourd’hui que ces quinze dernières années, j’ai surtout procédé par élimination, après une longue série de tentatives et d’échecs. Cet article sert donc avant tout à garder une trace de ces tentatives passées, en essayant de voir exactement pourquoi tel et tel système ne correspondait finalement pas tout à fait à mes besoins.

Slackware Linux est sans doute le système que j’ai utilisé le plus longtemps, et avec lequel je suis le mieux familiarisé. C’est une distribution simple et robuste, brute de décoffrage avec un os dans le nez, et qui JusteMarche(tm) – comme le dit mon pote Jean-Samuel à l’École des Mines d’Alès. J’ai définitivement quitté Slackware en avril 2017, pour une seule raison. C’est que la distribution n’offre qu’une quantité relativement limitée de paquets, et mon propre dépôt de paquets pour les variantes 32-bits et 64-bits de Slackware 14.0, 14.1 et 14.2 pour les serveurs aussi bien que pour les postes de travail comptait pas moins de 1.500 (!) paquets personnalisés. Autant dire que je passais une partie significative de mon temps à compiler des paquets. Il me fallait donc autre chose.

FreeBSDJ’ai longtemps été attiré par les systèmes BSD comme FreeBSD, NetBSD et OpenBSD. Je me suis passablement familiarisé avec le manuel de FreeBSD, j’aime beaucoup la qualité de la documentation, et j’ai toujours été un adepte du principe KISS. Si je n’utilise pas FreeBSD, c’est pour une seule raison, malheureusement prohibitive. C’est que je dois souvent travailler avec du matériel que je n’ai pas choisi, et dès qu’il y a un composant un poil exotique, j’aurai plus de chances à le faire fonctionner sous Linux.

DebianJ’ai également travaillé sous Debian, qui a même été ma principale distribution Linux pendant quelque temps, sur mes serveurs aussi bien que sur les postes de travail. En ce qui me concerne, je range Debian dans la panoplie des distributions très propres. Si je ne l’utilise plus aujourd’hui, c’est pour deux raisons. D’une part, la durée de support de Debian a toujours été insuffisante à mon humble estime. Concrètement, si je déploie un serveur de production trois mois avant la sortie de la nouvelle version stable, je bénéficierai de mises à jour de sécurité pendant un an et trois mois, puisque Debian offre un an de support après la sortie de la version subséquente. Évidemment, il existe des projets comme Debian LTS pour prolonger la durée de support pour les mises à jour à faible risque, mais ce projet – tout louable qu’il soit – reste limité à l’heure actuelle. Je sais qu’on peut faire les mises à jour majeures “à chaud”, mais sur les serveurs de production, ça n’a jamais été mon truc. D’autre part, je me suis rendu compte qu’il y avait comme une incompatibilité d’humeur avec certains membres un peu donneurs de leçons de la communauté Debian, le genre qui me corrige avec un zèle de théologien augustinien quand je dis “Linux” et non pas “GNU/Linux”. Ceci étant dit, si toutes les distributions venaient à disparaître du jour au lendemain, je redeviendrais probablement un Debianiste heureux.

ArchDans mon travail au quotidien, je gère quelques petits parcs de machines pour plusieurs clients. J’ai testé quelques rolling releases comme Arch et Gentoo dans le temps, et j’en suis vite revenu. Lorsqu’un distributeur décide du jour au lendemain de ne plus supporter un certain type de matériel – comme par exemple les cartes vidéo installées dans toutes nos onze médiathèques – vous avez le choix entre le changement de matériel ou le changement de système. Gentoo avait toujours l’air un poil plus propre que Arch, et sa documentation était aussi bien faite. Malheureusement, la moindre installation ou mise à jour servait également à chauffer la médiathèque, sans compter le temps que ça prenait.

FedoraUn certain nombre de distributions grand public comme Fedora ou OpenSUSE souffrent d’un syndrôme que Jean-Louis Servan Schreiber a décrit dans son excellent livre Trop Vite (ne pas confondre avec le bouquin de Nabilla, hein). Notre vie quotidienne connaît une accélération funeste dans des domaines aussi variés que la politique, la finance, la consommation, et l’informatique n’y échappe pas. À peine un logiciel, un environnement de bureau ou une distribution entière a vu le jour que l’éditeur annonce déjà la prochaine version. Les cycles de support deviennent de plus en plus courts, et certains projets en deviennent tout bonnement inutilisables, même s’ils semblent bien assemblés au départ. En tant que professionnel, je n’ai tout simplement pas envie de réinstaller tout mon parc de machines tous les huit mois.

Logo CentOSJe me retrouve donc à travailler avec CentOS au quotidien, qui doit être la distribution Linux la plus ennuyeuse qui existe. Peut-être bien que pour les systèmes d’exploitation, j’ai la même approche que pour les motos. Ma dix-neuvième moto est une BMW K75, le même modèle que celui de la Police Nationale et de la Gendarmerie. Ça distille zéro sensations, mais ça m’emmène à travers les routes des Alpes sans broncher. Chaque version de CentOS est supportée pendant dix ans, ce qui veut dire que tous les systèmes CentOS 7 que j’ai installés depuis 2014, je pourrai les maintenir sans les réinstaller jusqu’en juin 2024. Mes clients – des responsables d’administrations régionales, des directeurs d’école – apprécient beaucoup quand je leur explique ce genre de détail plaisant. J’utilise CentOS depuis la version 4, je suis inscrit sur la mailing list depuis près de douze ans, et j’apprécie le professionnalisme sobre de cette communauté.

Ennuyeux, c’est bien. :o)

BMW K75

Publié dans Divers | Marqué avec , | 19 commentaires

Carte NVidia GeForce 210 et RHEL/CentOS 7.5

NVidiaRed Hat Enterprise Linux 7.5 a été publié récemment, et les paquets CentOS correspondants sont déjà disponibles dans les dépôts CR (Continuous Release). J’ai donc lancé une mise à jour sur ma station de travail, qui m’a récupéré pas moins d’un gigaoctet de paquets.

Au redémarrage, j’ai eu la mauvaise surprise de me retrouver avec un système qui bloque au moment de lancer DKMS. Ce qui signifie très probablement qu’un de mes drivers pose problème avec le nouveau kernel.

J’ouvre une console avec [Ctrl]+[Alt]+[F6], je me connecte et je jette un oeil dans /var/log/Xorg.0.log. Effectivement, j’ai un No screens found, qui m’indique que mon driver nvidia ne fonctionne pas correctement.

Avant toute chose, je m’assure de démarrer en mode console par défaut.

# systemctl set-default multi-user.target

Je supprime les deux paquets kmod-nvidia-340xx et nvidia-x11-drv-340xx en provenance du dépôt ELRepo, et je télécharge manuellement le driver NVIDIA-Linux-x86_64-340.106.run sur le site du constructeur. Je lance la construction du driver, qui se solde par un échec.

Ma prochaine intuition me dit que le driver de chez NVidia fonctionnera peut-être avec un kernel plus récent. Dans un premier temps, j’installe donc le dernier noyau LTS de chez ELRepo.

# yum --enablerepo=elrepo-kernel install kernel-lt

Une fois ce kernel installé, je redémarre dessus. Attention, les noyaux en provenance de chez ELRepo ne sont jamais prioritaires dans GRUB, il faut donc les sélectionner explicitement au démarrage du système.

Une fois que je tourne sur mon nouveau noyau, je fais d’abord l’inventaire de tous les paquets relatifs au kernel dont je dispose sur mon système.

# rpm -qa | grep kernel

Je désinstalle soigneusement tous les paquets relatifs au noyau 3.10.0, notamment kernel-devel, kernel-headers, kernel-tools et kernel-tools-libs, sans oublier kernel tout court.

Le driver nvidia entre potentiellement en conflit avec le driver libre nouveau, je prends donc soin de le blacklister dans /etc/modprobe.d/blacklist.conf. Il est également utile d’ajouter une option comme nomodeset dans /etc/default/grub.

Notons qu’à partir de là, je redémarre automatiquement sur le bon kernel , étant donné que c’est le seul qui est installé sur ma machine.

La prochaine étape consiste à récupérer tous les paquets qui vont bien avec mon nouveau kernel.

# yum --enablerepo=elrepo-kernel install kernel-lt-devel \
  kernel-lt-headers gcc dkms

Je retente la construction du driver.

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

À partir du moment où DKMS est présent sur le système, l’installateur NVidia propose d’enregistrer le module auprès du service, ce qui évite d’avoir à le reconstruire lors d’une mise à jour du noyau.

Je vérifie mon fichier /etc/X11/xorg.conf, qui doit ressembler à ceci.

Section "Device"
        Identifier  "Videocard0"
        Driver      "nvidia"
EndSection

Je redémarre et je croise les doigts.

# systemctl isolate graphical.target

Le logo de NVidia s’affiche sur mes deux moniteurs, suivi du gestionnaire de connexion GDM. Tout est donc rentré dans l’ordre.

Qui a dit que Linux n’était pas user-friendly ? :o)

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

Configurer un cache de paquets local avec Yum et NFS

Paquets RPMJe suis en train de migrer le réseau informatique de notre lycée – serveurs et postes clients – vers CentOS. Ici dans les Cévennes, le débit ADSL n’est pas faramineux, et toute opération d’installation ou de mise à jour via le réseau devient vite assez fastidieuse lorsqu’on doit l’effectuer sur une vingtaine de machines.

Les utilisateurs de Debian et Ubuntu disposent d’un outil fort pratique pour ce genre de situation, c’est Apt-Cacher. Je l’ai moi-même utilisé à une époque, et je dois dire que suis un peu surpris de ne pas trouver d’outil équivalent pour les distributions de la famille Red Hat Enterprise Linux. J’ai donc expérimenté un peu avec les machines de notre réseau, et j’ai trouvé une solution “fait maison” qui fonctionne tout aussi bien.

En temps normal, Yum garde les paquets téléchargés dans un cache local /var/cache/yum. Or, ce cache est régulièrement vidé dans la configuration définie par défaut dans /etc/yum.conf.

[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0

Dans un premier temps, j’ai configuré le serveur principal du réseau – celui qui partage les répertoires utilisateurs via NFS – de manière à ce qu’il garde tous les paquets téléchargés dans le cache, en éditant /etc/yum.conf comme ceci.

[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=1

Ensuite, j’ai ajouté le cache de paquets aux partages NFS.

# /etc/exports
/home          192.168.10.0/24(rw,async,no_subtree_check) \
                 *.scholae.lan(rw,async,no_subtree_check)
/var/cache/yum 192.168.10.0/24(... ,no_root_squash) \
                 *.scholae.lan(... ,no_root_squash)

L’option no_root_squash est nécessaire pour permettre à root d’accéder au partage.

Sur les postes clients, il faut tout d’abord définir la persistance du cache dans /etc/yum.conf pour éviter de le purger.

[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=1

Je supprime le contenu du cache local.

# rm -rf /var/cache/yum/x86_64

Le répertoire vide /var/cache/yum servira comme point de montage pour NFS. Voici à quoi cela ressemble dans /etc/fstab.

serveur:/var/cache/yum /var/cache/yum nfs defaults,_netdev 0 0

À partir de là, il suffit d’effectuer une installation ou une mise à jour sur une seule des machines du réseau. Les autres machines se serviront automatiquement dans le cache, ce qui accélère les opérations de manière significative.

Il faudra veiller à bien définir la persistance du cache (keepcache=1) sur tous les clients qui se servent dans le cache partagé, faute de quoi il suffit d’un seul client pour supprimer tous les précieux téléchargements.

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

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

Installer un serveur FTP avec VsFTPd sous CentOS

FTPCet article décrit la mise en place d’un serveur FTP avec VsFTPd (Very Secure FTP Daemon) sur un serveur de réseau local tournant sous CentOS. FTP a été pendant longtemps la manière la plus simple pour échanger des fichiers sur Internet. Même si le protocole reste encore extrêmement populaire – notamment dans le cadre des hébergements web mutualisés – on peut considérer qu’il est obsolète, au vu des considérations de sécurité comme les mots de passe qui transitent en clair.

La raison pour laquelle je le présente quand-même ici, c’est que je m’en sers toujours dans un contexte bien précis, en combinaison avec Ghost4Linux, pour stocker l’image Ghost d’un poste client comme celui d’une salle informatique dans une école. Ghost4Linux requiert un serveur FTP local pour stocker une image ISO, et c’est donc ce que nous allons mettre en place. Sous CentOS, nous avons le choix entre ProFTPd et VsFTPd, et c’est ce dernier que nous allons utiliser.

Prérequis

Le pare-feu nécessite une configuration un peu particulière avec le protocole FTP. Pour permettre l’accès au serveur, nous devons faire deux choses.

  • ouvrir le port 21 en TCP
  • charger le module nf_conntrack_ftp

Voici à quoi cela ressemble concrètement dans mon script de pare-feu.

...
IPT=/usr/sbin/iptables
MOD=/usr/sbin/modprobe
...
# FTP
$MOD nf_conntrack_ftp
$IPT -A INPUT -p tcp -i $IFACE_LAN --dport 21 -j ACCEPT
...

Notons que dans notre configuration spécifique, SELinux ne nécessite aucune intervention de notre part.

Installation

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

# yum install vsftpd

Création d’un utilisateur

Je vais créer un utilisateur install pour mon serveur local d’images Ghost. Cet utilisateur n’est pas censé se connecter directement au système. Les images Ghost seront stockées en-dessous de /srv/ftp/install, le répertoire utilisateur correspondant que je dois créer au préalable.

# mkdir -pv -m 0770 /srv/ftp/install
mkdir: created directory ‘/srv/ftp’
mkdir: created directory ‘/srv/ftp/install’
# useradd -c "G4L User" -d /srv/ftp/install -s /sbin/nologin install
useradd: warning: the home directory already exists.
Not copying any file from skel directory into it.
# chown -R install:install /srv/ftp/install/
# passwd install
Changing password for user install.
New password: **********
Retype new password: **********
passwd: all authentication tokens updated successfully.

Configuration du serveur

La configuration de VsFTPd s’effectue dans le fichier /etc/vsftpd/vsftpd.conf. Avant d’aller plus loin, nous allons sauvegarder la configuration par défaut.

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

À partir de là, nous allons modifier ou ajouter quelques directives. Pour commencer, on va désactiver les connexions anonymes.

anonymous_enable=NO

Ensuite, on va descendre vers la fin du fichier et définir la configuration de notre utilisateur.

chroot_local_user=YES
userlist_enable=YES
userlist_deny=NO
check_shell=NO
userlist_file=/etc/vsftpd/vsftpd.user_list
allow_writeable_chroot=YES

Cette dernière stance mérite quelques explications.

  • La directive chroot_local_user=YES interdit aux utilisateurs de quitter l’arborescence de leur répertoire utilisateur pour se balader un peu partout dans le système.
  • La directive userlist_enable=YES active une liste d’utilisateurs.
  • Dans la configuration par défaut, la liste spécifie les utilisateurs auxquels on interdit l’accès au serveur. Nous allons faire le contraire avec userlist_deny=NO et créer une liste qui contiendra un seul utilisateur autorisé.
  • La directive check_shell=NO est nécessaire lorsqu’un utilisateur doit pouvoir se connecter alors même qu’il ne dispose d’aucun shell de connexion.
  • Le fichier spécifié par la directive userlist_file contiendra la liste avec les utilisateurs autorisés à se connecter.

Les listings récursifs sont autorisés.

ls_recurse_enable=YES

Notre serveur utilise uniquement l’IPv4, ce que nous allons préciser ici.

listen=YES
listen_ipv6=NO

Un peu plus bas, on pourra supprimer le doublon userlist_enable=YES et désactiver l’utilisation des encapsuleurs TCP.

tcp_wrappers=NO

Il ne reste plus qu’à créer le fichier /etc/vsftpd/vsftpd.user_list censé contenir la liste des utilisateurs autorisés à se connecter à VsFTPd.

# echo install > /etc/vsftpd/vsftpd.user_list

Mise en service et premier test

Activer et démarrer le serveur VsFTPd.

# systemctl enable vsftpd
# systemctl start vsftpd

Pour tester le serveur localement, on pourra utiliser un client FTP comme ncftp ou lftp. Avant de le lancer, on va lui fournir un fichier test à se mettre sous la dent.

# echo "Ceci est un test FTP" > /srv/ftp/install/test
# chown install:install /srv/ftp/install/test

À présent, on peut initier une connexion en tant qu’utilisateur install.

# ncftp -u install localhost
NcFTP 3.2.5 (Feb 02, 2011) by Mike Gleason 
(http://www.NcFTP.com/contact/).

Copyright (c) 1992-2011 by Mike Gleason.
All rights reserved.

Connecting to localhost...
(vsFTPd 3.0.2)
Logging in...
Password requested by localhost for user "install".

    Please specify the password.

Password: *********

Login successful.
Logged in to localhost.
ncftp / > ls
test
ncftp / > cat test
Ceci est un test FTP

ncftp / > bye

 

Publié dans CentOS, Documentation Microlinux | Marqué avec , , | 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 , | 3 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 , , | Un commentaire

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