Intégration d’ownCloud pour servir un partage de fichiers existant

Magazine
Marque
Linux Pratique
Numéro
136
Mois de parution
mars 2023
Spécialité(s)


Résumé

Le logiciel libre ownCloud est une solution de partage et de stockage des fichiers en mode web. Avec la profusion des plateformes commerciales de ce type (Google Drive, iCloud, Dropbox, etc.), l’accès web aux fichiers est devenu le nouveau standard. Dans cet article, nous allons explorer une méthode pour interfacer cette méthode d’accès aux fichiers avec un serveur NFS (Network File System) existant.


Body

Introduction

L’accès aux fichiers par le Web est devenu le nouveau standard. Adossés à de massives plateformes de Cloud, ces services peuvent croître en fonction de l’usage. Il suffit aux utilisateurs de souscrire à l'abonnement correspondant à leurs besoins en termes d’espace de stockage. Ces systèmes s’appuient sur la propriété d’élasticité des environnements Cloud. Certains moteurs de gestion de fichiers en mode Cloud sont disponibles on-premise, c'est-à-dire avec une instance locale. Les deux principaux sont NextCloud et ownCloud. Cet article va se focaliser sur le second. Pour bien placer un logiciel comme ownCloud dans la galaxie des systèmes de fichiers, il convient de dessiner les catégories à gros traits. La première catégorie, la plus simple en termes de compréhension, mais pas forcément d’implémentation, recouvre les systèmes de fichiers strictement locaux. Ces systèmes sont instanciés directement sur les partitions. Chacun de ces systèmes de fichiers a des caractéristiques qui lui sont propres comme la présence ou l’absence de contrôle d’accès, la journalisation ou non, etc. On retrouve VFAT, NTFS, ext[2,3,4], XFS, etc. Au-dessus de ces systèmes de fichiers, on peut trouver des systèmes de distribution chargés de partager les données stockées sur ces systèmes locaux sur le réseau. On retrouve CIFS, DFS, NFSv[3,4], etc. Enfin, il existe des systèmes de fichiers plus complexes gérant nativement la réplication des données sur des volumes distribués, les snapshots et parfois même les écritures en parallèle sur fichiers. Il s’agit de Btrfs, Lustre, ZFS, etc. Dans cet article, le scénario est d’intégrer les répertoires personnels des utilisateurs partagés en NFS dans un partage Cloud ownCloud on-premise. Nous allons commencer en présentant les spécificités de NFS pertinentes pour notre méthode. Ensuite, nous discuterons de l’installation basique d’ownCloud. Dans la section suivante, nous présenterons la passerelle entre ownCloud et le service NFS. Enfin, nous paramétrons ownCloud pour tirer avantage de cette passerelle dans l’objectif de mettre à disposition de l’utilisateur ses fichiers personnels du NFS dans son espace ownCloud.

1. Usage de NFS

Pour bien comprendre la problématique, il est nécessaire de présenter le cadre de l’utilisation du partage NFS. Ce partage est utilisé pour un centre de calcul. Basiquement, un centre de calcul est un ensemble de machines (ou nœuds) sur lesquelles on exécute des codes de calcul parallèles distribués (ou non). Distribué signifie que plusieurs machines peuvent travailler de concert à l'exécution du code. Ce code est situé dans le répertoire de l’utilisateur. En conséquence, ce répertoire doit être partagé entre tous les nœuds du centre de calcul. L’installation d’un serveur NFS est très simple et documentée partout sur Internet. Nous nous focaliserons sur les aspects de configuration qui nous concernent. Tout d’abord, il faut comprendre comment c’est fait côté serveur de fichiers mettant ces répertoires utilisateurs à disposition. Nous avons un serveur nommé « filer » qui fait tourner le serveur NFS nfsd. Cette machine a un volume de stockage. Regardons quelle partition est disponible.

root@filer:~# fdisk -l
[...]
Disque /dev/mapper/vg00-lv--nfs : 180 TiB, 197912080416768 octets, 386547032064 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets

Les données sont situées sur un volume logique LVM (Logical Volume Manager). Pour faire simple, c'est un système de gestion des partitions permettant de les retailler à chaud et de créer des snapshots. Cet article fait un point complet sur la sécurisation des données via le couple LVM / RAID [1]. Nous avons instancié un système de fichier XFS (Extended File System) dessus. Ce volume est monté dans le répertoire /nfsvol du serveur de fichiers :

root@filer:~# mount | grep vg00-lv--nfs
/dev/mapper/vg00-lv--nfs on /nfsvol type xfs (rw,relatime,attr2,inode64,noquota)

Vérifions le système de fichiers instancié sur ce volume :

root@filer:~# file -sL /dev/mapper/vg00-lv--nfs
/dev/mapper/vg00-lv--nfs: SGI XFS filesystem data (blksz 4096, inosz 512, v2 dirs)

Il s’agit de XFS. Entre toutes les propriétés de ce système de fichiers, celle qui va nous intéresser pour l’explication est que ce système de fichiers supporte le contrôle d’accès discrétionnaire ou DAC (Discretionary Access Control). Ce contrôle d’accès est simple, il se base essentiellement sur l’UID (User IDentifier) de l’utilisateur qui est l’identifiant numérique qu’il acquiert suite à son authentification. C’est cet identifiant qui est utilisé par le noyau au moment du contrôle d’accès à un fichier. C’est important pour la suite de l’article. Le point de montage /nfsvol de ce volume est partagé sur le réseau via NFS. Ça se passe dans le fichier /etc/exports :

root@filer:~# cat /etc/exports
/nfsvol         172.16.0.0/19(rw,sync,fsid=0,no_subtree_check)
/nfsvol/homes   172.16.0.0/19(rw,sync,no_subtree_check)

On définit un répertoire parent de partage /nfsvol et un sous-répertoire homes correspondant aux répertoires utilisateurs. Ce partage NFS est accessible sur le réseau 172.16.0.0/19 qui est privé, dédié au calcul et coupé du réseau interne de l’université (l’accès aux nœuds se fait via un frontal). L’authentification des machines clientes habilitées à monter le partage NFS se fait donc sur leur IP. C’est valide pour un réseau fermé, mais il faut le tenir loin d’un réseau ouvert tel qu’Internet. De plus, une fois le partage monté sur le client, le contrôle d’accès au partage se fait par l’UID. Le problème est que NFS fait confiance à un UID positionné par le client. Si un client est compromis et que le pirate arrive à obtenir les droits administrateur suite à une élévation de privilèges, alors il a accès à tous les fichiers. En effet, il peut créer des utilisateurs bidons recouvrant les UID des propriétaires des fichiers partagés. Ce risque est d'autant plus élevé si l’option no_root_squash est activée. Par défaut, si cette option est absente, NFS convertit l’UID 0 (root) en 65534 (nobody). Si l’option est activée, root conserve son UID 0 lors de l’accès au partage. L’idée est de créer une passerelle pour pouvoir mettre à disposition les fichiers du partage NFS à la machine ownCloud. Nous allons maintenant passer à la configuration de la passerelle.

2. Configuration d’une passerelle

Cette passerelle va se positionner entre mon serveur ownCloud, frontal d’accès pour les utilisateurs au service de partage de fichiers sur Internet, et le partage NFS. Cette passerelle va d’une part monter le partage NFS des répertoires utilisateurs et d’autre part les repartager en SFTP (SSH File Transfer Protocol). SFTP est une extension du protocole SSH gérant l’accès aux fichiers. On profite donc des nombreux mécanismes de sécurité concernant l'authentification et l’autorisation proposés par SSH. Nous utiliserons l’implémentation OpenSSH du protocole SFTP.

2.1 Montage NFS

Commençons par le plus simple, monter le partage NFS sur la passerelle (que nous avons nommée sftp). Nous allons installer les outils clients NFS :

root@sftp:~# apt-get install nfs-client

Puis nous allons créer deux scripts de démarrage. Le premier n’est pas obligatoire selon votre installation, mais peut s’avérer utile dans certaines configurations de démarrage. En effet, selon les services démarrés par votre machine, il peut arriver que le montage NFS se lance avant que la résolution de nom soit valide (true story). Ce premier script va donc attendre que le serveur NFS soit solvable en DNS :

root@sftp:~# cat /etc/systemd/system/wait-for-nfs-server.service
[Unit]
Description=Wait for DNS
Wants=network-online.target
After=network-online.target
 
[Service]
Type=oneshot
ExecStart=/bin/sh -c 'while ! host filer.calcul.univ-paris13.fr; do sleep 2; done'
 
[Install]
WantedBy=multi-user.target

Ce script de démarrage fait des résolutions en boucle du FQDN filer.calcul.univ-paris13.fr. Chaque résolution infructueuse est suivie d’une attente de deux secondes. Une fois la résolution réussie, on sort de la boucle et le script s’arrête. Le second script réalise le montage NFS des répertoires utilisateurs :

root@sftp:~# cat /etc/systemd/system/nfs-homes.mount
[Unit]
Description=Mount homes
Wants=network-online.target wait-for-nfs-server.service
After=network.target network-online.target wait-for-nfs-server.service
 
[Mount]
What=filer.calcul.univ-paris13.fr:/homes
Where=/nfs/homes
Type=nfs4
Options=defaults
 
[Install]
WantedBy=multi-user.target

Ce script démarre après le précédent (Wants, After wait-for-nfs-server.service) et monte le partage homes de filer.calcul.univ-paris13.fr dans le répertoire /nfs/homes. Les utilisateurs sont définis dans un annuaire LDAP [2]. Leur répertoire utilisateur est /nfs/homes/<identifiant>. Nous prendrons comme postulat que la partie LDAP est configurée et donc que les utilisateurs sont connus sur la passerelle. Nous allons activer ces deux scripts au démarrage et les lancer :

root@sftp:~# systemctl enable wait-for-nfs-server.service nfs-homes.mount
root@sftp:~# systemctl start wait-for-nfs-server.service nfs-homes.mount

2.2 Accès SFTP

Configurons maintenant l’accès en SFTP aux fichiers. La sécurité de l’accès va s’appuyer sur deux mécanismes : authentification par clés SSH et le confinement de l’utilisateur dans l'emplacement des répertoires personnels pour l’autorisation. L’authentification par clés repose sur la cryptographie asymétrique. L’utilisateur génère une bi-clé privée et publique. La clé privée reste dans la poche de l’utilisateur tandis que la clé publique est amenée à être distribuée au monde entier. Vous trouverez ici [3] un guide complet du client OpenSSH, notamment l’utilisation des clés. Pour faire simple, l’utilisateur installe sa clé publique sur le compte distant qu’il souhaite connecter en SSH. Par la suite, en présentant sa clé privée au serveur, il pourra s’authentifier sur son compte distant localisé sur cette machine. Nous reviendrons ensuite sur l’installation de la clé publique dans le compte utilisateur dans la section dédiée à ownCloud. Passons au confinement de l’utilisateur lors de l’utilisation de son partage.

L’idée est de s’appuyer sur la capacité d’OpenSSH à confiner les connexions des utilisateurs dans un répertoire (ici la racine des répertoires personnels). Le problème de confinement de processus est traité ici [4]. Nous ne rappellerons que les notions clés. Ce confinement s’appuie sur l’utilisation de l’appel système chroot(). Cet appel système change l’attribut de racine (au niveau système de fichiers) du processus invocateur. En conséquence, le processus ne verra pas les répertoires au-dessus de sa nouvelle racine. Pour que ce confinement soit efficace d’un point de vue sécurité, il est essentiel qu’en complément le processus s'exécute avec une identité non privilégiée. Ça tombe bien, c’est exactement ce que fait le serveur OpenSSH. Lorsqu’un utilisateur se connecte, le processus qui l'accueille transite vers son identité. La configuration d’un tel accès se passe dans le fichier /etc/ssh/sshd_config :

root@sftp:~# cat /etc/ssh/sshd_config
[...]
#Subsystem     sftp    /usr/lib/openssh/sftp-server
Subsystem      sftp    internal-sftp
 
Match Group *,!root
    ChrootDirectory /nfs/homes
    X11Forwarding no
    AllowTcpForwarding no
    ForceCommand internal-sftp

Nous pouvons voir qu’une directive Subsystem est commentée au profit d’une autre. Nous faisons donc le choix d’utiliser le serveur SFTP interne de OpenSSH plutôt que le programme externe sftp-server. La différence entre les deux est que le serveur interne est intégré à l'exécutable sshd. En conséquence, il n’a aucune dépendance ce qui rend son confinement très simple, car il n’y a pas de problématique de librairies ou fichiers externes à gérer. A contrario, le serveur externe propose plus d’options, mais c’est un programme indépendant invoqué par sshd lorsque l’utilisateur se connecte en SFTP. La gestion de ses dépendances pour le confinement est plus compliquée.

La section « Match » qui suit s’applique à tous les utilisateurs qui se connectent excepté root (*,!root). Pour ces utilisateurs, nous excluons la redirection X11 permettant d'exécuter des programmes distants avec un rendu graphique local (X11Forwarding no). Nous excluons également les possibilités de tunnel (AllowTcpForwarding no). Enfin, on confine la connexion à la racine des répertoires personnels (ChrootDirectory /nfs/homes) en forçant l'exécution du serveur SFTP interne à l’ouverture de session (ForceCommand internal-sftp). Le lecteur attentif pourra se demander pourquoi on confine dans la racine des répertoires utilisateurs et pas dans le répertoire utilisateur lui-même. La raison est que sshd refuse de confiner une session dans un répertoire offrant un droit d’écriture à un utilisateur non privilégié ce qui est la raison d’être d’un répertoire utilisateur. C’est un compromis avec l’usage, ce qui est l’essence de la sécurité informatique.

3. Notes sur l’installation d’ownCloud

Nous n’allons pas entrer dans les détails de la configuration d’ownCloud. Nous n’avons fait que suivre la documentation officielle. La seule difficulté est de séquencer correctement les actions. Tout d’abord, il va vous falloir un serveur MariaDB opérationnel. Vous pourrez l’installer avec les prérequis d’ownCloud en suivant cette documentation [5]. Ensuite, il faut un serveur web. Idem, la documentation officielle donne tous les éléments [6]. Cependant, les directives à mettre dans le fichier sont un peu éparses dans la documentation. Pour faciliter le travail du lecteur, nous donnons le fichier du site in-extenso (évidemment à adapter à votre configuration).

root@owncloud:~# cat /etc/apache2/sites-available/owncloud.conf
Servername drive.cloud.univ-paris13.fr
 
<IfModule mod_ssl.c>
        <VirtualHost _default_:443>
                ServerAdmin nobody@nowhere.com
                DocumentRoot /var/www/owncloud
                ErrorLog ${APACHE_LOG_DIR}/error.log
                CustomLog ${APACHE_LOG_DIR}/access.log combined
 
                SSLEngine on
                SSLCertificateFile     /etc/apache2/ssl/owncloud-cert.pem
                SSLCertificateKeyFile /etc/apache2/ssl/owncloud-key.pem
                SSLCertificateChainFile /etc/apache2/ssl/owncloud-ca.pem
                <Directory /var/www/owncloud>
                             Options FollowSymlinks
                             AllowOverride All
                             Require all granted
                </Directory>
        </VirtualHost>
</IfModule>

Notamment la partie SSL n’est pas très bien détaillée dans la documentation. Si vous souhaitez plus de détails sur les directives SSL du fichier, vous pouvez vous référer à cette documentation [6]. Une fois la base de données et le serveur web déployés, il ne reste plus que l’archive d’ownCloud à décompresser [7]. Le seul complément à cette documentation est que lorsque le répertoire owncloud a été déplacé dans /var/www, il faut bien penser à donner les droits à l’utilisateur du serveur web :

root@owncloud:~# chown -R www-data:www-data /var/www/owncloud

Normalement, une fois ces actions effectuées, lorsque vous allez avec votre navigateur sur l’URL de votre instance d’ownCloud vous devriez tomber sur l’interface de configuration initiale [8]. Cette étape consiste essentiellement à renseigner les détails de connexion à la base de données ainsi que le répertoire où seront stockés les fichiers des utilisateurs. Attention, ici on ne parle pas du répertoire utilisateur au sens du répertoire personnel porté par le partage NFS, mais d’un répertoire dédié à l’utilisateur par ownCloud. C’est depuis ce répertoire ownCloud que nous allons faire un lien vers le répertoire utilisateur partagé par NFS. Pour les utilisateurs, nous partons du principe que vous avez un LDAP fonctionnel [2] et que vous allez y connecter votre instance d’ownCloud [9]. Cependant, dans la section suivante, nous allons amender la configuration du LDAP.

4. Gestion des utilisateurs ownCloud

Nous ne souhaitons pas donner un accès ownCloud à tous les utilisateurs du LDAP. Nous allons utiliser l’overlay « memberOf ». Lorsque l’on utilise cet overlay, on crée des objets « groupOfNames » qui possèdent un attribut multi-instancible « member ». Cet attribut prend comme valeur le DN d’un utilisateur. Lorsque l’utilisateur est ajouté, il se voit ajouter dynamiquement un attribut « memberOf ». Commençons par regarder si le module est défini dans la configuration de l’annuaire :

root@ldap:~/ldif# slapcat -n 0 | grep olcModuleLoad
olcModuleLoad: {0}back_mdb

Il ne l’est pas, ajoutons-le via un fichier memberof-enable.ldif :

root@ldap:~/ldif# cat memberof.ldif
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: memberof.la

Modifions la configuration des modules de l’annuaire :

root@ldap:~/ldif# ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f member.ldif
modifying entry "cn=module{0},cn=config"

Vérifions que le module est chargé :

root@ldap:~/ldif# slapcat -n 0 | grep olcModuleLoad
olcModuleLoad: {0}back_mdb
olcModuleLoad: {1}memberof.la

Nous pouvons maintenant ajouter le groupe « drivegroup » dédié à l’utilisation de notre instance d’ownCloud. Créons un fichier LDIF contenant ce nouveau groupe :

root@ldap:~/ldif# cat drive.ldif
dn: cn=drivegroup,ou=groups,dc=calcul,dc=univ-paris13,dc=fr
objectClass: groupOfNames
cn: drivegroup
member: uid=nicolas.greneche,ou=accounts,dc=calcul,dc=univ-paris13,dc=fr

Ajoutons le groupe dans la base de données de l’annuaire :

root@ldap:~/ldif# ldapadd -x -H ldaps://ldap.calcul.univ-paris13.fr -D 'cn=admin,dc=calcul,dc=univ-paris13,dc=fr' -f drive.ldif -W

Vérifions que l’utilisateur est bien dans le groupe :

root@ldap:~/ldif# ldapsearch -x 'memberOf=cn=drivegroup,ou=groups,dc=calcul,dc=univ-paris13,dc=fr'
[...]
# nicolas.greneche, accounts, calcul.univ-paris13.fr
dn: uid=nicolas.greneche,ou=accounts,dc=calcul,dc=univ-paris13,dc=fr
uid: nicolas.greneche
homeDirectory: /nfs/homes/nicolas.greneche
cn: nicolas.greneche
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
loginShell: /bin/bash
uidNumber: 6001
gidNumber: 6001
gecos: nicolas.greneche@univ-paris13.fr
sn:: R3JlbsOoY2hl
mail: nicolas.greneche@univ-paris13.fr

Enfin, nous allons connecter notre ownCloud au partage NFS.

5. Connexion d’ownCloud à la passerelle SFTP

Avant tout, il faut se connecter en administrateur sur la plateforme ownCloud. Pour vérifier que ce module est installé, allez en haut à gauche sur votre identifiant puis Paramètres. Dans la figure 1, on voit à gauche le menu Applications et une fois dans ce menu on active External Storage Support.

add-storage-s

Fig. 1 : Ajout du module de stockage externe.

Une fois cette extension installée, vous pouvez aller dans Stockage sur la gauche de l’interface comme illustré dans la figure 2. Puis activer Autoriser les utilisateurs à monter des espaces de stockage externes et plus spécifiquement SFTP. La dernière option à activer est optionnelle dans notre méthode. Elle permet de faire des partages de fichiers depuis un stockage externe via des liens ou par groupes. Nous l’avons activée, car c’est pratique pour les chercheurs afin de partager leurs expérimentations avec leurs collègues.

conf-storage-s

Fig. 2 : Configuration des paramètres de stockage externe.

Connectons-nous en simple utilisateur pour créer le montage externe connecté au répertoire utilisateur partagé en NFS. Allons en haut à gauche sur votre identifiant puis sur Paramètres. À gauche, un item Stockage est apparu qui ouvre sur le menu en figure 3.

user-storage-s

Fig. 3 : Configuration d’un stockage externe pour l’utilisateur.

La première colonne renseigne le nom du partage externe pointant sur le dossier personnel partagé par NFS et repartagé en SFTP par la passerelle. La colonne suivante renseigne sur le protocole utilisé par le stockage externe. Ici, il s’agit de SFTP. Pour l’authentification, on choisit Clé publique RSA (mais mot de passe fonctionne également, il faudra seulement s’authentifier interactivement à chaque accès) qui est basiquement une authentification SSH par clé. Enfin, on a le quadruplé Configuration avec respectivement le nom de la machine à connecter (sftp.calcul.univ-paris13.fr), le répertoire à monter dans le stockage externe (attention, ce répertoire est relatif au chroot(), donc /nicolas.greneche pour /nfs/homes/nicolas.greneche), l’identifiant (nicolas.greneche) et enfin la partie publique d’une clé SSH générée par ownCloud. Cette clé devra être installée dans le répertoire utilisateur partagé en NFS conformément à la documentation [3].

Une fois la configuration terminée, la loupiotte à gauche passe au vert et retournant sur votre écran d'accueil, vous devriez retrouver le dossier correspondant au montage externe comme dans la figure 4.

dir-storage-s

Fig. 4 : Dossier correspondant au stockage externe.

Quand vous cliquez dessus, vous devriez retrouver le contenu de votre répertoire personnel partagé en NFS et profiter pour celui-ci des facilitées offertes par ownCloud.

Conclusion

Dans cet article, nous avons proposé une méthode pour partager un répertoire utilisateur distribué en NFS via le stockage cloud en mode on-premise ownCloud. Nous nous sommes appuyés sur les capacités d’OpenSSH pour renforcer l’authentification en passant d’un accès discriminant sur l’IP à une clé SSH. Au niveau autorisation, l’utilisateur ne peut pas déborder sur le système de base, car sa connexion est confinée dans le répertoire des utilisateurs. Enfin, le préambule à toute manipulation du stockage externe est une authentification sur le portail ownCloud. Au niveau non-répudiation, nous sommes un niveau au-dessus de la discrimination sur l’IP offerte par NFS (sans Kerberos). Un concurrent d’ownCloud est nextCloud. Personnellement, je n’ai pas expérimenté cette solution très loin, car j’avais des déconnexions fréquentes avec l’annuaire LDAP. J’ai donc basculé sur ownCloud, car je n’avais que des besoins fichiers.

Références

[1] https://connect.ed-diamond.com/GNU-Linux-Magazine/glmf-210/securisez-vos-donnees-par-lvm-et-raid

[2] https://connect.ed-diamond.com/Linux-Pratique/lp-115/installation-et-configuration-d-un-annuaire-openldap

[3] https://connect.ed-diamond.com/Linux-Pratique/lp-107/petit-cas-pratique-d-utilisation-du-client-openssh

[4] https://connect.ed-diamond.com/GNU-Linux-Magazine/glmf-118/confinement-de-processus-sous-freebsd-jail-et-linux-openvz

[5] https://doc.owncloud.com/server/next/admin_manual/installation/manual_installation/manual_installation_db.html#mysqlmariadb

[6] https://connect.ed-diamond.com/Linux-Pratique/lp-123/les-certificats-de-l-emission-a-la-revocation

[7] https://doc.owncloud.com/server/next/admin_manual/installation/manual_installation/manual_installation.html#command-line-installation

[8] https://doc.owncloud.com/server/next/admin_manual/installation/installation_wizard.html

[9] https://doc.owncloud.com/server/next/admin_manual/configuration/user/user_auth_ldap.html



Article rédigé par

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

Équilibrage de charge avec IPVS

Magazine
Marque
Linux Pratique
HS n°
Numéro
55
Mois de parution
octobre 2022
Spécialité(s)
Résumé

IP Virtual Server (IPVS) est un équilibreur de charge agissant au niveau 4 du modèle OSI. Il est implémenté sous forme d’un module noyau s’appuyant sur le framework Netfilter, ce qui le rend efficace sur l’équilibrage des services par rapport à leurs ports TCP/UDP, mais totalement agnostique aux protocoles applicatifs transportés (LDAP, HTTP, etc.).

Libre-service de machines virtuelles avec OpenNebula

Magazine
Marque
Linux Pratique
Numéro
130
Mois de parution
mars 2022
Spécialité(s)
Résumé

Dans un article précédent, nous avons mis en place une infrastructure OpenNebula basique [1]. Nous allons maintenant configurer cette plateforme pour proposer aux utilisateurs un guichet de libre-service de machines virtuelles. L’idée est que les utilisateurs puissent créer eux-mêmes leurs machines virtuelles.

Monter sa plateforme Cloud avec OpenNebula

Magazine
Marque
Linux Pratique
Numéro
128
Mois de parution
novembre 2021
Spécialité(s)
Résumé

OpenNebula est un orchestrateur libre de machines virtuelles (KVM, VMWare) et conteneurs lourds (LXC). Son rôle est d’organiser et placer les machines virtuelles sur une infrastructure physique. C’est un peu le chaînon manquant entre le serveur physique et les orchestrateurs de conteneurs applicatifs types Kubernetes.

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