Administrer vos serveurs avec Rex

Magazine
Marque
Linux Pratique
Numéro
131
Mois de parution
mai 2022
Spécialité(s)


Résumé

Si vous êtes administrateur système, vous êtes probablement familier avec les outils permettant l’automatisation et le déploiement de configuration. Ansible, Puppet, Chef sont les plus communs aujourd’hui. Plus méconnu, (R)?ex a pourtant des arguments à faire valoir auprès de la concurrence. Partons à sa découverte.


Body

Lorsque l’on administre des serveurs à distance, automatiser l’exécution de commandes, la modification de fichiers de configuration ou l’installation de paquets est primordiale. Cela permet un gain de temps, garantit une meilleure productivité et l’assurance que vos tâches soient, malgré leur répétitivité et leur redondance, faites sans erreurs. (R)?ex combiné à la richesse de l'écosystème Perl vous permettront cela.

1. Déploiement et gestion de configuration

(R)?ex ou simplement Rex est un outil open source sous licence Apache 2.0. Il permet la gestion de configuration et le déploiement de logiciels à distance. Il est utilisable soit par simple commande, soit par l’intermédiaire d’un simple DSL (Domain-Specific Language) entièrement compatible avec du code Perl classique associé aux richesses du MetaCPAN [1].

v-rexify

Fig. 1 : Le site officiel de (R)?ex.

1.1 (R)?ex

Rex, qui est l'acronyme de « Remote Execution », est un framework d'automatisation qui repose uniquement sur Perl et Secure Shell (SSH) [2]. Il est donc « AgentLess ». En ce sens, n'importe quel ordinateur peut agir en tant que client Rex, sans avoir besoin de logiciel supplémentaire.

v-diagram

Fig. 2 : Architecture de déploiement.

L’architecture est donc très simple, un hôte de contrôle disposant de Perl 5 [3] et d’un client SSH exécutant Rex. Il n’utilise que les modules Perl de base. Vos configurations sont déployées à partir d’un Rexfile contenant vos tâches d’administration, ainsi que vos inventaires, vos environnements ou informations d'authentification.

Sur les hôtes que l’on souhaite gérer, nous aurons également besoin d’un interpréteur Perl 5 et d’un compte valide pour le serveur SSH qui s'y exécute. Bien évidemment, si les tâches administratives à réaliser nécessitent des privilèges spécifiques, un accès root ou tout au moins des droits sudo seront nécessaires.

La puissance de Rex réside dans le fait qu’il est parfaitement intégré à Perl. En utilisant les modules ou bibliothèques du langage, vous aurez la liberté de créer l'outil d’automatisation le plus adapté à votre situation, sans multiplier les technologies et en évitant la complexité.

1.2 Bac à sable et installation

Afin de faciliter la découverte de Rex et sa mise en œuvre, une plate-forme de test faisant office de bac à sable est disponible dans le dépôt associé à cet article. Nous disposerons donc d’un hôte de contrôle (rexMaster) et de deux hôtes à gérer (rexSlave1 et 2), tous les trois sous Debian 11 Bullseye.

Comme prérequis, vous devez disposer de Vagrant [4] et de VirtualBox [5] sur votre machine. Une fois le dépôt cloné (git clone https://codeberg.org/foiche/rexInfra.git), placez-vous à la racine du répertoire du projet et jouez ces commandes pour mettre sur pied notre bac à sable :

vagrant up
vagrant ssh rexMaster

Si vous déployez vos propres machines, assurez-vous d’avoir un serveur SSH à l’écoute sur l’hôte à gérer et que la commande perl -v vous renvoie une version égale ou supérieure à la 5.0.

Votre environnement est-il prêt ? Passons dans ce cas à l’installation de Rex. Deux choix s’offrent à vous. Via le gestionnaire de paquets et les dépôts officiels de votre distribution, ce qui donne sous Debian :

apt update
apt install rex

Soit en utilisant la commande cpan ou son alternative cpanminus [6] :

rex@rexMaster:~$ cpanm rex

Vérifions la version installée :

rex@rexMaster:~$ rex -v
(R)?ex 1.13.3

Ici, nous disposons donc de la version 1.13.3, fournie avec notre distribution de test Debian. Un petit tour également du côté de l’aide pour découvrir la syntaxe de base de Rex :

rex@rexMaster:~$ rex -h
usage:
  rex [<options>] [-H <host>] [-G <group>] <task> [<task-options>]
  rex -T[m|y|v] [<string>]

Le fichier Rexfile, présent dans le répertoire courant est lu à l’exécution de la commande rex. Celle-ci accepte un certain nombre d’options et exécute la tâche passée en argument. L’option -T permet de lister les tâches disponibles dans un Rexfile sans l’exécuter.

1.3 Premiers pas

Un des atouts de Rex, c’est qu’il est directement utilisable en ligne de commande, sans passer par les fameux Rexfiles que nous découvrirons ensuite. Ceci peut s’avérer fort utile en cas de corrections mineures ou de maintenance rapide sur une flotte de serveurs.

Pour cela, deux informations sont nécessaires. Premièrement, le ou les hôtes cibles définis par l’option -H et séparés par un espace. Ceux-ci peuvent être définis soit par une adresse IP, soit par un nom DNS si vous disposez d’une résolution de nom. Ensuite, les credentials du compte utilisé sur la machine distante, -u pour l’utilisateur et -p pour le mot de passe. Dans cet exemple, nous utiliserons le compte root de manière à pouvoir exécuter des tâches avec un haut niveau de permissions.

Enfin, l’option -e permet d’évaluer l’action à exécuter sur l’environnement cible. Un petit exemple :

rex@rexMaster:~$ rex -H '10.0.0.11 10.0.0.12' -u root -p rex -e 'say run q(hostname)'
[2022-02-12 02:07:28] INFO - Running task eval-line on 10.0.0.11
rexSlave1
[2022-02-12 02:07:29] INFO - Running task eval-line on 10.0.0.12
rexSlave2
[2022-02-12 02:07:30] INFO - All tasks successful on all hosts

Ici, nous lançons simplement la commande système hostname via la directive run. L’instruction say, équivalent à print dans la version 5 de Perl, nous retourne la sortie standard correspondante.

Afin de sécuriser davantage la communication avec nos hôtes à gérer, mettons en place les clés SSH :

rex@rexMaster:~$ ssh-keygen
rex@rexMaster:~$ ssh-copy-id root@rexSlave1

Nous pouvons maintenant nous passer du mot de passe en clair et ici afficher les derniers journaux système de notre cible. Au passage, affranchissons-nous de l’adresse IP en utilisant par exemple le fichier host de notre système :

v-9rex cmd syslog

Fig. 3 : Exemple de CLI Rex.

Notez l’utilisation du module Perl Data::Dumper pour présenter sous forme de tableau notre sortie. Rex, c’est du Perl, pourquoi s’en priver !

2. Boîte à outils

L’utilisation de Rex en ligne de commande s’avère très pratique pour récupérer des informations ou effectuer un correctif rapide sur les machines que l’on administre. Mais dans le cadre d’un projet de déploiement sur une grappe de serveurs, l’utilisation d’un fichier structuré est plus appropriée. Plongeons maintenant dans l’écriture des Rexfiles.

2.1 Rexfile et tâches

Le Rexfile, sorte de Makefile pour une exécution à distance, va permettre au travers d’un DSL de définir un ensemble de tâches (Task) ordonnées, le tout au cœur même d’un script Perl.

Créons tout d’abord le répertoire contenant notre projet Rex et plaçons-y notre premier Rexfile :

rex@rexMaster:~$ mkdir rexproject
rex@rexMaster:~$ cd rexproject
rex@rexMaster:~$ vim Rexfile

La première chose remarquable qui constitue ce fichier, c’est l’utilisation du flag -feature. Non sans rappeler les features guard propres au langage Perl, ce flag permet d’activer les fonctionnalités d’une version précise en garantissant une rétrocompatibilité de vos Rexfiles.

Nous avons ensuite une série d’instructions composant le mini DSL de Rex. Nous retrouvons les éléments qui composaient notre ligne de commande :

  • user, définissant l’utilisateur exécutant les tâches sur l’hôte distant ;
  • desc, permettant d’afficher une brève description de la finalité de notre tâche.

Et enfin, caractérisée par le mot-clé task suivi de son nom, une tâche est composée d’une cible (le groupe myservers fixé précédemment) et d’une sub, qui est la définition d’une fonction en Perl. À l’intérieur, nous pourrons y placer n’importe quelle commande issue des différents modules Rex ou tout simplement du code Perl arbitraire.

Ici, nous affectons à la variable $os le résultat de la commande système cat, et on l’affiche :

use Rex -feature => ['1.3'];
 
user 'root';
group myservers => '10.0.0.11';
 
desc 'Get the OS version of my server';
task 'os_version',
  group => 'myservers',
  sub {
    my $os = run 'cat /etc/debian_version';
    say $os;
  };

Enregistrons et listons les tâches disponibles avec l’option -T :

rex@rexMaster:~/rexproject$ rex -T
Tasks
os_version Get the OS version of my server
Server Groups
myservers 10.0.0.11

Nous pouvons enfin exécuter notre première tâche comme ceci :

rex@rexMaster:~/rexproject$ rex os_version
[2022-02-13 15:35:10] INFO - Running task os_version on 10.0.0.11
11.2
[2022-02-13 15:35:11] INFO - All tasks successful on all hosts

La sortie nous indique les différents timecodes ainsi que le succès ou l’échec de l'exécution.

2.2 Utiliser les commandes

Pour l’instant, nous nous sommes cantonnés à la commande run destinée à l’appel de commandes système. Toutefois, Rex propose un ensemble de commandes de base couvrant un large périmètre. Ces modules sont répertoriés et documentés dans le MetaCPAN sous le préfixe Rex::Commands [7]. Je vous propose d’en découvrir quelques-uns en déployant et en configurant un serveur HTTP Apache2 [8].

2.2.1 Package

La gestion de paquets est ici simplifiée par le module Rex::Commands::Pkg. Rex détermine le gestionnaire de paquets à l'œuvre sur la plate-forme distante et vous propose de nombreuses fonctionnalités.

De la simple installation :

use Rex -feature => ['1.3'];
 
user 'root';
group myservers => '10.0.0.11';
 
desc 'Installation d’Apache';
task 'install_apache',
  group => 'myservers',
  sub {
    update_package_db
    pkg 'apache2', ensure => 'present';
  };

La valeur present signifie que l’on installera la dernière version disponible pour cette distribution. Il est néanmoins possible de préciser une version spécifique comme ceci :

pkg 'apache2', ensure => 2.4.52;

Pour supprimer un paquet, il suffit de passer la valeur de la clé ensure à absent.

Si vous avez le besoin éventuellement de gérer des dépôts spécifiques, utilisez les instructions repository add et repository remove en spécifiant l’URL, pour respectivement ajouter ou supprimer un dépôt. Il vous faudra peut-être fournir les clés de chiffrement de celui-ci.

Pour notre hôte cible, notre fournisseur de paquets est apt, mais Rex supporte d’autres gestionnaires de paquets issus des distributions GNU/Linux les plus courantes, tels que yum (RedHat/CentOS), zypper (openSuSE), pkg (FreeBSD, NetBSD…), emerge (Gentoo)…

2.2.2 Service

Notre serveur HTTP installé, il nous faut maintenant démarrer son service associé. La commande Rex::Commands::Service accepte deux paramètres. Le premier est le nom du service. Le second, l’action à effectuer pour contrôler le gestionnaire de service systemd, qui peut prendre les valeurs « start », « stop », « restart », « status », « reload » ou « stopped » :

  service 'apache2', ensure => 'started';

Notre service est opérationnel, occupons-nous de sa configuration.

2.2.3 File

Fournie par le module Rex::Commands::Pkg, la commande file apporte toutes les manipulations souhaitables sur un système de fichiers d’un environnement UNIX. Il en va de la simple création, modification, suppression ou copie de fichiers et répertoires, en passant par la gestion avancée des droits utilisateurs. Il permet également la lecture et l’écriture de fichiers sur un hôte distant (fonction file_read et file_write), mais aussi le remplacement ou la suppression de ligne à base d’expression régulière. Enfin, le module file embarque un moteur de templating facilitant le déploiement de fichiers de configuration en tous genres.

Revenons à notre exemple. Notre serveur HTTP étant sur pied, intéressons-nous au répertoire racine de notre site web et notre première page HTML.

Pour ceci, nous allons donc créer un répertoire ayant pour chemin /var/www/monsite appartenant à l’utilisateur et au groupe système www-data. Cet utilisateur aura des droits de lecture, d’écriture et d’exécution. Les autres n’auront que des droits de lecture et d'exécution (droit de listage pour notre répertoire) :

desc 'Configuration d’Apache';
task 'configure_apache',
    group => 'myservers',
  sub {
    file "/var/www/monsite",
      ensure => "directory",
      owner  => "www-data",
      group  => "www-data",
      mode   => "755";

Pour mettre en place la page d’index de notre site, nous avons la possibilité de copier un fichier local à notre machine rexMaster sur notre hôte distant. Éditons ce fichier que nous placerons au préalable dans un répertoire files à la racine du répertoire de notre projet :

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <title>Mon site web</title>
    <p>Bienvenue sur mon site</p>
  </head>
</html>

Une fois enregistré, déployons-le en précisant en paramètre la source, mais aussi le propriétaire ou les droits qui lui sont associés :

    file "/var/www/monsite/index.html",
      source => "files/index.html",
      owner  => "www-data",
      group  => "www-data",
      mode   => "644";

Il ne nous reste maintenant qu’à configurer le virtualhost qui héberge notre site web. Faisons un peu de ménage en supprimant au passage le fichier d’hôte virtuel par défaut :

    file "/etc/apache2/sites-available/000-default.conf",
      ensure => "absent";

Rex embarque son propre moteur de templating Rex::template::NG [9] depuis la version 1.3. Nous allons donc pouvoir élaborer dynamiquement des fichiers de configuration en y insérant des variables que l’on pourra définir dans un ensemble clé/valeur au sein de notre Rexfile. Ajoutons un répertoire templates toujours dans le répertoire de notre projet Rex et plaçons-y le fichier monsite.conf.tpl contenant ceci :

<VirtualHost *:80>
    ServerAdmin <%= $conf->{"admin"} %>
    DocumentRoot <%= $conf->{"document_root"} %>
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Côté Rexfile, nous ajoutons aux paramètres déjà vus précédemment le paramètre content faisant appel au moteur de templating. Il n’y a plus qu’à fournir le chemin menant à notre template et la table de hachage conf nous permettant de passer, via les clés document_root et admin, la racine de notre site et le mail de l’administrateur :

    file "/etc/apache2/sites-available/monsite.conf",
      owner   => "root",
      group   => "root",
      mode    => "644",
      content => template(
        "templates/monsite.conf.tpl",
        conf => {
          document_root => '/var/www/monsite',
          admin     => 'webmaster@localhost',
        }
      );

Et enfin, activons et rechargeons notre nouvelle configuration :

  run 'a2ensite monsite.conf';
  service 'apache2', ensure => 'reload';
  };

Il ne nous reste plus qu’à jouer nos tâches après une vérification via la commande rex -T :

rex@rexMaster:~/rexproject$ rex install_apache configure_apache
[2022-02-26 15:00:07] INFO - Running task install_apache on 10.0.0.11
[2022-02-26 15:00:09] INFO - Running task configure_apache on 10.0.0.11
[2022-02-26 15:00:11] INFO - Service apache2 is reloaded.
[2022-02-26 15:00:11] INFO - All tasks successful on all hosts

Nous pouvons, avec un seul appel, jouer un ensemble de tâches en les séparant par un simple espace. Remarquons également que l’information liée au rechargement de notre service est spécifiquement précisée dans la sortie.

2.2.4 Cron

Pour automatiser des commandes ou le lancement de scripts sur nos hôtes distants, le module Rex::Commands::Cron autorise le paramétrage d’une crontab de manière efficace :

desc 'Ajout d’une cronbtab';
task "add_cron",
  group => 'myservers',
  sub {
    cron add => "root", {
      minute => '5',
      hour => '*',
      day_of_month   => '*',
      month => '*',
      day_of_week => '*',
      command => '/usr/local/bin/apache_access_log.sh',
     };
  };

On y retrouve les options classiques de journalisation. La clé command définit la commande système ou le script à exécuter selon la périodicité souhaitée.

2.3 Hooks

Il est également intéressant de mentionner la prise en charge de hooks qui permettent de conditionner ou d’agencer chronologiquement les tâches composant un Rexfile :

  • before exécute une action avant que quoi que ce soit ne soit fait. Tous les paramètres d'origine lui sont transmis, y compris les valeurs par défaut appliquées ;
  • after s'exécute juste avant le retour de la fonction du module. Tous les paramètres d'origine sont également transmis ;
  • before_change, after_change et on_change permettent quant à eux de surveiller les changements au niveau d’un fichier et d’y conditionner une action.

Nous pouvons par exemple surveiller la modification du fichier de configuration de notre vhost et y conditionner le rechargement du service apache2 :

on_change => sub { service apache2 => 'reload'; };

3. Utilisation avancée

Si vous êtes arrivés jusqu’ici, vous maîtrisez déjà l’écriture de base des Rexfiles et l’utilisation des modules essentiels qui constitueront 75 % de vos besoins en déploiement de configuration. Néanmoins, une utilisation plus avancée de Rex vous permettra de mieux structurer vos Rexfiles. Quand ceux-ci prennent de l’ampleur, que vous ayez besoin de gérer une plus grande complexité d'environnement ou de développer votre propre outil en y incorporant vos scripts Perl, créer des modules peut s’avérer être un atout.

3.1 Moduler votre contenu

Votre répertoire contient un fichier nommé Rexfile où il est possible d’énumérer toutes vos tâches. Ceci est viable dans le cadre de petits projets ou d’opérations de maintenance. Cela ressemblera vite à un casse-tête à mesure qu'il grandit avec une multitude d’opérations et de configurations à déployer. Créer des modules contenant chaque tâche ou chaque groupe de tâches autour d’une thématique permet d’organiser plus efficacement un projet. Par exemple, nous pourrions avoir un module dans un répertoire Webserver::Apache pour contenir les tâches liées à la gestion de notre serveur HTTP.

Placez-vous à la racine du projet et saisissez cette commande :

rex@rexMaster:~/rexproject$ rexify Webserver::Apache --create-module

Nous y générons l’arborescence de ce nouveau module :

module tree

Fig. 4 : Organisation d’un projet Rex en module.

Nous constatons l’apparition d’un répertoire lib, qui accueillera tous nos nouveaux modules. À l’intérieur du répertoire Apache, deux nouveaux fichiers, meta.yml, contenant les méta-informations de notre module ainsi que d’éventuelles dépendances à d’autres sous-modules et le fichier lib/Webserver/Apache/__module__.pm contenant l’ensemble des tâches relatives au serveur HTTP rédigées plus haut dans cet article.

Dans notre Rexfile principal, l’appel à notre module fraîchement créé se fait comme suit :

require Webserver::Apache

Un rex -T nous montre notre première tâche suivie de nos tâches issues du module :

rex@rexMaster:~/rexproject$ rex -T
Tasks
os_version                         Get the OS version of my server
 
Webserver:Apache:add_cron          add_crontab
Webserver:Apache:configure_apache  Configuration d’Apache
Webserver:Apache:install_apache    Installation d’Apache
Server Groups
myservers 10.0.0.11

On peut désormais les lancer de manière classique en préfixant celles-ci selon le module utilisé :

rex@rexMaster:~/rexproject$ rex Webserver:Apache:add_cron

3.2 Environnement et CMDB

Avec l’usage des environnements, il est facile de regrouper vos serveurs en fonction de l’avancement de la qualification de votre code ou de votre application. De ce fait, il peut être nécessaire de créer des environnements différents pour les machines de développement, de test ou de production. Plusieurs solutions sont alors envisageables. La première est de déclarer directement ces environnements dans le Rexfile :

environment test => sub {
    user "root";
    password "pwd_test";
 
    group webserver   => "10.0.0.11";
    group database    => "10.0.0.12";
};
environment prod => sub {
    user "root";
    password "pwd_prod";
 
    group webserver   => "10.0.0.13";
    group database    => "10.0.0.14";
};

Pour exécuter votre Rexfile, et donc vos tâches en fonction d'un environnement donné, il faut désormais le spécifier en passant l’option -E :

rex@rexMaster:~/rexproject$ rex -E test Webserver:Apache:install_apache

Une autre solution est d’utiliser une CMDB [10] pour séparer les données du Rexfile. Il est nécessaire de créer des fichiers YAML pour chaque environnement. L’arborescence est donc la suivante :

rex@rexMaster:~/rexproject$ mkdir -p cmdb/test
rex@rexMaster:~/rexproject$ mkdir -p cmdb/prod
rex@rexMaster:~/rexproject$ vim cmdb/test/default.yml
rex@rexMaster:~/rexproject$ vim cmdb/prod/default.yml

La commande tree nous permet de visualiser cela plus facilement :

cmdb tree

Fig. 5 : Utilisation d’une CMDB.

Nous allons pouvoir exploiter cette CMDB dans notre Rexfile. Nous chargeons ici le module Rex::CMDB et définissons son emplacement et son format :

use Rex::CMDB;
set cmdb => {
    type => "YAML",
    path => "./cmdb",
};

Nous avons maintenant la possibilité de récupérer ces valeurs issues de la CMDB avec l’instruction get et la tâche sera lancée comme précédemment en utilisant l’option -E test :

user get cmdb('user');
group server => get cmdb ('webserver');
 
desc 'Utiliser la CMDB';
task 'read_hostname',
  group => "server",
  sub {
    my $name = run 'hostname';
    say $name;
  };

La ressource peut-être directement utilisée comme ici, mais rien ne nous empêche d’effectuer un traitement préalable avant de l’affecter à notre group server.

3.3 Un peu de Perl…

Une des forces de Rex, c’est sa totale intégration avec le langage Perl. Son écosystème, composé notamment de son dépôt d’applications et de modules nommé CPAN, permet d’étendre les fonctionnalités intégrées à Rex. Utilisons notre deuxième machine cible pour y déployer une base de données (Rexfile disponible dans le dépôt de cet article). Nous y hébergerons une table contenant nos hôtes et leurs identifiants afin d’externaliser les données de notre précédente CMDB.

Pour exploiter notre base, installons, sur notre nœud maître, les modules nécessaires à la prise en charge du système de gestion de base de données MariaDB [11].

Nous aurons besoin, au préalable, du métapaquet build-essential, nécessaire à la compilation du module DBI (interface Perl pour la gestion de base de données), sur notre machine rexMaster :

rex@rexMaster:~/rexproject$ apt install build-essential

Ensuite, il nous reste à installer le driver MariaDB pour le module DBI (celui-ci sera installé automatiquement avec le driver), soit via le gestionnaire de paquets :

rex@rexMaster:~/rexproject$ apt install libdbd-mariadb-perl

Soit via la commande cpanminus :

rex@rexMaster:~/rexproject$ cpanm DBD::MariaDB

Nous pouvons maintenant simplement interroger notre base afin de provisionner les variables user et group.

Les requêtes à la base de données sont exécutées avant le lancement de la tâche récupérant la version du système d’exploitation de la cible :

v-rexfile mariadb

Fig. 6 : Exploitation d’un SGBD au sein d’un Rexfile.

Ceci est un exemple parmi tant d’autres. Vous imaginez bien ici tous les pré- ou post-traitements possibles afin d’agrémenter et d’optimiser vos tâches. Le CPAN contient bon nombre de modules utiles à un administrateur système, tels que la gestion des annuaires (Net::LDAP), le traitement et la manipulation de tous types de fichiers (YAML, XML, JSON...), ou encore la communication avec des API.

Conclusion

Rex est une alternative solide aux acteurs majeurs de l’automatisation et de la gestion de configuration. Simple d’utilisation, il est directement utilisable sur la plupart des systèmes GNU/Linux, sur lesquels il propose pléthore de commandes. C’est un outil flexible, évolutif et personnalisable. Il laisse à l’utilisateur une grande liberté en ce qui concerne la structure et l’organisation de son code. En nous inspirant de la célèbre devise de Perl, nous pouvons affirmer que « There Is More Than One Way To Manage It ».

Références

[1] MetaCPAN : https://metacpan.org/

[2] Secure Shell : https://fr.wikipedia.org/wiki/Secure_Shell

[3] Perl : https://www.perl.org/

[4] Vagrant : https://www.vagrantup.com/

[5] Virtualbox : https://www.virtualbox.org/

[6] Cpanminus : https://www.virtualbox.org/

[7] Rex::Commands : https://metacpan.org/pod/Rex::Commands

[8] Apache2 : https://httpd.apache.org/

[9] Rex::template::NG : https://metacpan.org/pod/Rex::Template::NG

[10] CMDB : https://fr.wikipedia.org/wiki/Configuration_management_database

[11] MariaDB : https://mariadb.org/

Pour aller plus loin



Article rédigé par

Par le(s) même(s) auteur(s)

Les derniers articles Premiums

Les derniers articles Premium

Les nouvelles menaces liées à l’intelligence artificielle

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Sommes-nous proches de la singularité technologique ? Peu probable. Même si l’intelligence artificielle a fait un bond ces dernières années (elle est étudiée depuis des dizaines d’années), nous sommes loin d’en perdre le contrôle. Et pourtant, une partie de l’utilisation de l’intelligence artificielle échappe aux analystes. Eh oui ! Comme tout système, elle est utilisée par des acteurs malveillants essayant d’en tirer profit pécuniairement. Cet article met en exergue quelques-unes des applications de l’intelligence artificielle par des acteurs malveillants et décrit succinctement comment parer à leurs attaques.

Migration d’une collection Ansible à l’aide de fqcn_migration

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Distribuer du contenu Ansible réutilisable (rôle, playbooks) par l’intermédiaire d’une collection est devenu le standard dans l’écosystème de l’outil d’automatisation. Pour éviter tout conflit de noms, ces collections sont caractérisées par un nom unique, formé d’une espace de nom, qui peut-être employé par plusieurs collections (tel qu'ansible ou community) et d’un nom plus spécifique à la fonction de la collection en elle-même. Cependant, il arrive parfois qu’il faille migrer une collection d’un espace de noms à un autre, par exemple une collection personnelle ou communautaire qui passe à un espace de noms plus connus ou certifiés. De même, le nom même de la collection peut être amené à changer, si elle dépasse son périmètre d’origine ou que le produit qu’elle concerne est lui-même renommé.

Mise en place d'Overleaf Community pour l’écriture collaborative au sein de votre équipe

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Si vous utilisez LaTeX pour vos documents, vous connaissez vraisemblablement Overleaf qui vous permet de rédiger de manière collaborative depuis n’importe quel poste informatique connecté à Internet. Cependant, la version gratuite en ligne souffre de quelques limitations et le stockage de vos projets est externalisé chez l’éditeur du logiciel. Si vous désirez maîtriser vos données et avoir une installation locale de ce bel outil, cet article est fait pour vous.

Les listes de lecture

8 article(s) - ajoutée le 01/07/2020
Découvrez notre sélection d'articles pour faire vos premiers pas avec les conteneurs, apprendre à les configurer et les utiliser au quotidien.
11 article(s) - ajoutée le 02/07/2020
Si vous recherchez quels sont les outils du DevOps et comment les utiliser, cette liste est faite pour vous.
8 article(s) - ajoutée le 02/07/2020
Il est essentiel d'effectuer des sauvegardes régulières de son travail pour éviter de perdre toutes ses données bêtement. De nombreux outils sont disponibles pour nous assister dans cette tâche.
Voir les 58 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous