Remarque :
- Ce tutoriel est disponible dans un environnement de laboratoire gratuit fourni par Oracle.
- Il utilise des exemples de valeur pour les informations d'identification, la location et les compartiments Oracle Cloud Infrastructure. A la fin de l'exercice, remplacez ces valeurs par celles propres à votre environnement cloud.
Utilisation de systemd sur Oracle Linux
Introduction
Dans ce tutoriel, vous allez apprendre à utiliser l'utilitaire de ligne de commande systemctl pour gérer et afficher les unités systemd contrôlées par systemd. Ce tutoriel s'adresse aux utilisateurs d'Oracle Linux 8 ou version ultérieure.
systemd est le premier processus qui démarre à l'initialisation et est le dernier processus à s'arrêter à l'arrêt du système. systemd est principalement utilisé pour gérer les services ou les processus système et l'initialisation du système à l'initialisation. Toutefois, systemd est également capable de gérer de nombreuses autres tâches et fonctions, notamment la journalisation des événements, la gestion des périphériques, la connexion utilisateur, la planification des tâches, la synchronisation de l'heure et l'initialisation du système. De nombreuses fonctionnalités dans systemd ne sont pas entièrement utilisées car les utilisateurs peuvent être plus à l'aise avec les autres logiciels à ces fins ou des distributions Linux différentes peuvent avoir des approches préférées pour la configuration du système.
Différents types de comportement ou fonctions au sein de systemd sont gérés en unités systemd. Par exemple, les processus du démon ou les services système sont exécutés en tant qu'unités de service, tandis que les états du système sont généralement définis en tant qu'unités cible. Vous pouvez définir des unités d'horloge pour planifier des tâches de la même manière que vous pouvez utiliser le service cron système et utiliser une unité de montage pour configurer un point de montage de la même manière que vous pouvez configurer un point de montage dans le fstab système.
systemd est utilisé pour gérer les processus et les fonctions au niveau du système, mais il est également capable de gérer les processus s'exécutant dans l'espace utilisateur. Les utilisateurs d'un système peuvent configurer et gérer leurs propres services et systemd peut même être configuré pour permettre à ces services de continuer à s'exécuter une fois que l'utilisateur a interrompu sa session.
Objectifs
- Repérer différents types d'unité systemd
- Utiliser les unités cible systemd
- Apprendre la syntaxe de commande systemctl courante
- Créer votre propre unité de minuteur systemd dans l'espace utilisateur
- Configuration de systemd pour permettre l'exécution des processus d'espace utilisateur après la déconnexion
De quoi avez-vous besoin ?
- Système sur lequel Oracle Linux 8 est installé.
Remarque : lorsque vous utilisez l'environnement d'exercices gratuits, reportez-vous à Notions de base d'Oracle Linux Lab pour obtenir des instructions de connexion et d'utilisation.
Explorer les fichiers d'unité systemd
Une fois connecté à l'instance Oracle Linux 8, vous pouvez commencer à expérimenter la commande systemctl pour connaître les différentes unités disponibles.
-
Exécutez la commande systemctl pour répertorier toutes les unités systemd actuellement chargées par systemd :
systemctl
Utilisez l'espace ou les touches PgDn du clavier pour parcourir la sortie.
Cette commande équivaut à exécuter :
systemctl list-units
La sortie affiche toutes les unités de configuration actuellement actives gérées par systemd. Dans la sortie, vous devez remarquer qu'il existe des unités nommées avec différents suffixes, y compris des unités nommées avec les suffixes '.device', '.mount','.service', '.target' et '.timer'.
Les unités sont actives dans le sens où elles sont démarrées, en cours d'exécution, montées ou connectées, selon leur fonction. Les unités peuvent être inactives au sens où elles sont arrêtées, démontées ou déconnectées. Si vous souhaitez voir toutes les unités, qu'elles soient actives ou non, vous pouvez exécuter :
systemctl list-units --all
La sortie de ces commandes montre une sélection des différents types d'unités systemd :
automount
: fournit des fonctionnalités de montage automatique pour le montage à la demande des systèmes de fichiers et le démarrage en parallèle.mount
: contrôle les points de montage dans les affichages de date et d'heure actuels du système de fichiers.path
: permet d'activer les services lorsque les informations de chemin du système de fichiers sont modifiées.scope
: similaire aux unités de service, mais gère les processus étrangers au lieu de les démarrer.service
: démarre et contrôle les démons et les processus qu'ils composent.slice
: permet de regrouper les unités qui gèrent les processus système, telles que les unités de service et les unités de portée, dans l'arborescence Cgroup hiérarchique à des fins de gestion des ressources.socket
: encapsule dans le système des sockets de réseau ou de communication interprocessus locale, utiles pour l'activation basée sur le socket.target
: permet de regrouper des unités ou de fournir des points de synchronisation bien connus lors de l'initialisation.timer
: permet de déclencher l'activation d'autres unités à l'aide d'horloges. Elles constituent une alternative aux tâches qui ont pu être précédemment gérées à l'aide du service cron.device
: présente les périphériques de noyau dans systemd et peut également être utilisé pour implémenter l'activation basée sur les périphériques.swap
: encapsule des partitions de swap de mémoire ou des fichiers de swap.
-
Limitez la liste des unités à un type d'unité particulier à l'aide de l'option
--type
.-
Utilisez la commande
systemctl list-units --type services
pour répertorier les unités de service actuellement actives sur votre système.systemctl list-units --type service
-
Exécutez à nouveau la même commande, mais incluez l'option
--all
pour afficher toutes les unités chargées, y compris celles qui sont inactives, le cas échéant.systemctl list-units --type service --all
-
Vous pouvez répéter ces commandes pour chacun des types de service disponibles, afin de limiter les informations au type qui vous intéresse à tout moment.
Utiliser les unités cible systemd
Les unités cible sont utilisées pour regrouper différentes unités afin de placer le système dans un état particulier afin qu'il soit prêt à fonctionner dans un but particulier.
-
Répertoriez les unités
target
disponibles.systemctl list-units --type target
Les unités peuvent nécessiter le chargement d'autres unités ou être configurées pour entrer en conflit avec des unités particulières. Par exemple,
multi-user.target
requiert quebasic.target
fonctionne et qu'il soit également en conflit avec les unitésrescue.service
etrescue.target
. Les unités indiquent également les autres unités qu'elles souhaitent charger pour pouvoir fonctionner.De cette façon, les cibles peuvent être enchaînées pour configurer un état particulier, mais elles sont également suffisamment modulaires pour être réutilisées pour déclencher un autre état.
-
Affichez l'unité cible par défaut.
L'unité cible par défaut définit l'état du système par défaut après l'initialisation.
-
Utilisez la commande
systemctl get-default
pour visualiser l'unité cible utilisée par défaut. L'unité cible par défaut est représentée par le fichier/etc/systemd/system/default.target
.systemctl get-default
-
Utilisez la commande
ls -l
pour répertorier les informations sur le fichier/etc/systemd/system/default.target
.ls -l /etc/systemd/system/default.target
Remarque : le fichier
default.target
est un lien symbolique vers le fichier d'unité cible par défaut actuel.
-
-
Modifiez l'unité cible par défaut.
-
Utilisez la commande
systemctl set-default
pour remplacer l'unité cible par défaut par l'unitégraphical.target
.systemctl set-default graphical.target
-
Utilisez la commande
ls –l
pour confirmer que le fichierdefault.target
est désormais un lien symbolique vers le fichiergraphical.target
.ls -l /etc/systemd/system/default.target
Remarque : la modification de l'unité cible par défaut enlève le lien symbolique
default.target
existant et recrée le lien symbolique, qui pointe vers la nouvelle unité cible par défaut.
-
-
Pour plus d'informations, explorez une cible.
-
Utilisez la commande
systemctl show
pour obtenir plus d'informations sur une cible spécifique.systemctl show multi-user.target
La sortie affiche tous les paramètres de la cible que vous indiquez. Notez que vous pouvez identifier les unités requises, souhaitées et en conflit avec la cible, ainsi que les unités devant être exécutées avant et après cette cible.
-
Utilisez la commande
systemctl list-dependencies
pour afficher l'arborescence des dépendances requises ou souhaitées pour qu'une cible particulière atteigne son état :systemctl list-dependencies default.target
Cette commande affiche toutes les unités démarrées lorsque vous démarrez la cible par défaut. La chaîne d'unités est présentée de manière récursive dans un arbre qui permet d'évaluer pleinement ce que la cible atteint au démarrage. Si vous avez défini
graphical.target
comme cible par défaut, vous pouvez constater que le système souhaite exécuterdisplay-manager.service
pour charger l'affichage graphique, mais il exécute égalementmulti-user.target
pour effectuer toutes les opérations requises avant d'exécuter l'affichage graphique.
-
Utilisation de systemctl pour activer, désactiver et masquer des unités
Les unités peuvent être désactivées ou activées et peuvent également être masquées pour qu'elles ne s'exécutent jamais dans aucune circonstance. Certaines unités sont statiques dans la mesure où elles sont toujours disponibles, généralement parce qu'il s'agit de dépendances pour que d'autres unités fonctionnent. La commande systemctl list-units
peut uniquement être utilisée pour afficher les unités actives ou inactives sur le système.
-
Répertoriez toutes les unités disponibles sur le système, ainsi que leur état :
systemctl list-unit-files
La plupart des unités disponibles sont statiques. Les unités activées démarrent à l'initialisation. Les unités désactivées sont des unités disponibles sur le système mais qui ne sont pas configurées pour démarrer à l'initialisation. Les unités masquées sont disponibles sur le système mais ont été activement définies sur un état dans lequel elles ne peuvent pas être démarrées.
-
Utilisez la commande
systemctl status
pour afficher des informations détaillées sur l'uniténfs-server.service
.systemctl status nfs-server.service
La commande
systemctl
permet de supprimer l'extension.service
lorsque vous faites référence à des unités de service.La commande status indique si une unité est activée, active, inactive, désactivée ou masquée.
Pour les solutions scriptées,
systemctl
fournit de courtes commandes permettant de générer le statut sur une seule ligne :-
Utilisez la commande
systemctl is-active
pour vérifier si le servicenfs-server
est en cours d'exécution (actif) ou non (inactif).systemctl is-active nfs-server
-
Utilisez la commande
systemctl is-enabled
pour vérifier si le servicenfs-server
est activé ou désactivé. Lorsque le service est activé, il démarre à la réinitialisation du système.systemctl is-enabled nfs-server
-
-
Activez le démarrage d'un service à l'initialisation.
La commande
systemctl enable
permet d'activer le servicenfs-server
.sudo systemctl enable --now nfs-server
Vous devez exécuter la commande
systemctl
avec des privilèges d'administrateur si la commande change d'état ou de configuration du système. Vous pouvez utiliser l'option--now
pour démarrer le service en même temps que vous l'activez.Remarque : la commande active le service en créant un lien symbolique pour la cible système-état de niveau inférieur à laquelle le service démarre. Dans la sortie, la commande a créé le lien symbolique
nfs-server.service
pour la ciblemulti-user
.Utilisez
systemctl status command
pour vérifier que le servicenfs-server
est maintenant activé et en cours d'exécution.systemctl status nfs-server
-
Désactivez et arrêtez un service.
La commande
systemctl disable
permet de désactiver le servicenfs-server
. Notez également que la commandesystemctl disable
supprime le lien systemctl pour le service.sudo systemctl disable nfs-server
Utilisez la commande
systemctl stop
pour arrêter le servicenfs-server
.sudo systemctl stop nfs-server
Vous pouvez combiner ces étapes à l'aide de l'option
--now
lorsque vous désactivez le service. -
Masquer et démasquer une unité.
Dans certains cas, vous pouvez désactiver le démarrage des unités. En règle générale, vous pouvez effectuer cette opération si une unité particulière est en conflit avec d'autres fonctionnalités du système ou pour une raison de stratégie.
Utilisez la commande
systemctl mask
pour masquer le servicenfs-server
:sudo systemctl mask nfs-server
Un lien symbolique est créé pour garantir que la configuration d'unité systemd pointe vers /dev/null. Cela empêche l'activation ou le démarrage du service.
Vérifiez que vous ne pouvez pas démarrer l'unité de serveur NFS lorsqu'elle est masquée :
sudo systemctl start nfs-server
Le service ne peut pas démarrer et une erreur est renvoyée pour indiquer que le service est masqué.
Ne masquez pas l'unité pour la remettre à son état d'origine et permettre aux utilisateurs de démarrer ou d'activer le service.
sudo systemctl unmask nfs-server
Configurer systemd pour les unités d'espace utilisateur
En général, systemd est utilisé pour gérer les unités au niveau système. Les utilisateurs ont besoin d'un accès de niveau administrateur au système pour gérer les unités systemd ainsi configurées. Dans certains environnements et pour certains types d'unités, les utilisateurs peuvent souhaiter utiliser la capacité du système à exécuter des unités dans l'espace utilisateur. Par exemple, les utilisateurs souhaiteront peut-être planifier des tâches à l'aide des fonctionnalités d'unité de minuteur de systemd ou exécuter des applications ou des services spécifiques en tant qu'unités de service ne nécessitant pas d'autorisation d'exécution au niveau racine.
systemd démarre un processus systemd-user pour un utilisateur à la connexion. Les unités situées dans les répertoires suivants sont traitées dans l'ordre suivant pour l'utilisateur :
/usr/lib/systemd/user/
: unités d'espace utilisateur fournies par les packages installés.$HOME/.local/share/systemd/user/
: unités d'espace utilisateur provenant de packages installés dans le répertoire de base./etc/systemd/user/
: unités utilisateur globales à l'échelle du système qui doivent s'exécuter dans l'espace utilisateur pour tous les utilisateurs.$HOME/.config/systemd/user/
: unités créées par l'utilisateur
Vous pouvez indiquer systemd que vous travaillez dans l'espace utilisateur à l'aide de l'option --user
pour n'importe quelle commande systemd.
-
Répertoriez les fichiers d'unités actuellement disponibles pour votre utilisateur.
systemctl --user list-unit-files
La liste des unités disponibles est beaucoup plus courte que lorsque vous exécutez la même commande sans l'option
--user
.La majorité de ces fichiers d'unité, sur un nouveau système, se trouve dans
/usr/lib/systemd/user
. Répertoriez les fichiers de ce répertoire pour visualiser les unités situées ici :ls -la /usr/lib/systemd/user/
-
Créez un répertoire pour héberger vos propres fichiers d'unités systemd.
mkdir -p $HOME/.config/systemd/user
-
Créez votre propre unité de service systemd.
cat << EOF > $HOME/.config/systemd/user/uptime.service [Unit] Description="Logs system uptime and load average" Wants=uptime.timer [Service] ExecStart=/usr/bin/uptime [Install] WantedBy=default.target EOF
Cette unité de service fournit trois sections de configuration.
La section
Unit
fournit une description de l'unité et de toutes les conditions requises. Dans ce cas, une entréeWants
définit un besoin faible pour une unité d'horloge qui n'existe pas encore. Les unités répertoriées en tant qu'entréesWants
sont exécutées si elles sont disponibles mais n'empêchent pas l'exécution de l'unité parent si elles sont introuvables ou échouent.La section
Service
définit le comportement de cette unité de service spécifique lors de son exécution. Nous utilisons de nombreuses valeurs par défaut pour les options disponibles ici et indiquons uniquement la ligneExecStart
, qui spécifie la commande exécutée au démarrage du service. Dans ce cas, la commandeuptime
est exécutée pour consigner les valeurs de temps d'activité et de charge du système.La section
Install
définit la façon dont le service doit être installé sur le système lorsqu'il est activé. Notamment, le service est ajouté en tant que serviceWantedBy
sur "default.target". Cela signifie que le service est activé dans le cadre de la cible par défaut pour cet utilisateur. -
Exécutez l'unité systemd et vérifiez sa sortie.
Etant donné que vous avez ajouté une nouvelle unité, il est généralement recommandé de recharger la configuration systemd avant de tenter d'exécuter le service :
systemctl --user daemon-reload
Démarrez maintenant la nouvelle unité.
systemctl --user start uptime
Vérifiez que la commande a été exécutée comme prévu. Vous pouvez vérifier que le service a été exécuté en vérifiant son statut :
systemctl --user status uptime
Remarque : ces commandes utilisent l'option
--user
pour s'exécuter dans l'espace utilisateur.Pour vérifier la sortie de la commande
uptime
exécutée, utilisez la commandejournalctl
afin d'afficher le journal et de spécifier l'option de balise afin d'afficher les journaux propres à la commande :journalctl -t uptime
Vous pouvez activer ce service pour qu'il démarre lorsque votre utilisateur se connecte pour la première fois au système.
systemctl --user enable uptime
Notez que le service s'exécute lorsque l'utilisateur se connecte pour la première fois au système. Il ne démarre pas automatiquement à l'initialisation du système. En général, les services exécutés dans l'espace utilisateur prennent fin une fois que l'utilisateur se déconnecte ou que toutes les sessions utilisateur sont interrompues. L'activation de la persistance pour les services utilisateur est traitée plus loin dans ce tutoriel.
Utiliser les unités de temps systemd
Dans cet exercice, vous allez vous appuyer sur l'exercice précédent pour créer et permettre à une unité de minuterie d'exécuter régulièrement une autre unité systemd à un moment ou un intervalle donné. Les unités d'horloge peuvent être définies au niveau du système et au niveau de l'utilisateur et peuvent être utilisées pour définir quand systemd doit exécuter une autre unité. Les unités d'horloge fournissent un contrôle granulaire sur les événements planifiés et peuvent servir d'alternative à l'utilisation du démon cron pour gérer des configurations plus subtiles.
De nombreux services système incluent des unités d'horloge pour contrôler leur exécution. Un bon exemple d'unité d'horloge est inclus dans le package dnf-automatic
qui peut être utilisé pour maintenir votre système à jour lorsqu'il effectue automatiquement des mises à jour dnf régulières. Pour le voir en action au niveau du système, installez le package et activez l'unité de minuteur :
sudo dnf install -y dnf-automatic
sudo systemctl enable dnf-automatic.timer
Vous pouvez afficher le fichier d'unités pour voir comment cette unité est configurée :
cat /usr/lib/systemd/system/dnf-automatic.timer
Contenu notable dans cette unité, incluez une ligne Wants
qui attend que network-online.target
soit atteint. L'entrée OnCalendar
dans la section Timer
de la configuration suggère que cette action est exécutée quotidiennement sur 06h00. L'entrée RandomizedDelaySec
est également intéressante, ce qui peut aider à empêcher les unités d'horloge de se déclencher exactement en même temps et à pousser soudain la charge du système.
L'exemple fourni ici fait partie d'un ensemble d'unités beaucoup plus complexe. Pour mieux comprendre le fonctionnement des unités de minuteur, ajoutez une unité de minuteur dans l'espace utilisateur afin de programmer l'élément uptime.service
que vous avez créé dans l'exercice précédent afin qu'il s'exécute à intervalles réguliers.
-
Créez un fichier d'unité de minuteur.
cat <<EOF > $HOME/.config/systemd/user/uptime.timer [Unit] Description=Timer for the uptime service that logs uptime Requires=uptime.service [Timer] Unit=uptime.service OnCalendar=*-*-* *:*:00 [Install] WantedBy=timers.target
Ce fichier indique que
uptime.service
est requis pour l'exécution de cette unité d'horloge. Cette exigence est beaucoup plus forte que tout ce qui est défini dans une définitionWants
et l'unité ne s'exécute pas si la condition n'est pas satisfaite.La section
Timer
définit qu'elle charge l'unitéuptime.service
à l'aide d'une entréeOnCalendar
. L'entréeOnCalendar
fonctionne de la même manière que les options d'une définition crontab, mais offre une plus grande granularité. Dans ce cas, l'unité est définie pour s'exécuter toutes les minutes à 00 secondes. -
Etant donné que vous avez modifié la configuration systemd, rechargez les démons systemd et redémarrez le service de temps de disponibilité afin qu'il puisse récupérer la nouvelle unité d'horloge :
systemctl --user daemon-reload systemctl --user restart uptime
-
Répertoriez les unités pour vérifier que les unités
uptime.service
etuptime.timer
sont en cours d'exécution.systemctl --user list-units
-
Surveillez la sortie de journal dans le journal pour voir la sortie de temps d'activité déclenchée par l'exécution du service de temps d'activité toutes les minutes.
journalctl -f -t uptime
Au bout de quelques minutes, plusieurs lignes de sortie auraient dû s'afficher. Si vous accordez une attention particulière, vous remarquerez peut-être que la commande uptime ne se déclenche pas toujours exactement à la minute. Cette fonction est intentionnelle dans la fonctionnalité d'horloge systemd. Les travaux d'horloge sont déclenchés avec un randomiseur qui peut permettre le déclenchement d'une tâche avec un délai d'attente pouvant aller jusqu'à une minute. Cela permet d'empêcher les horloges de se déclencher exactement en même temps. Vous pouvez forcer une horloge à être incroyablement précise en définissant la précision sur une nanoseconde de l'événement planifié, en ajoutant l'entrée de configuration suivante à la section de l'unité d'horloge
Timer
:AccuracySec=1us
Toutefois, pour la plupart des tâches, il est judicieux d'autoriser un certain degré d'inexactitude afin d'éviter une exécution trop synchrone des tâches.
Vous pouvez utiliser la combinaison de touches Ctrl-C pour quitter le journal lorsque vous avez terminé la surveillance.
Configurer les processus d'espace utilisateur pour continuer après la déconnexion
Par défaut, les services et les processus démarrés et détenus par un utilisateur sont arrêtés lorsque l'utilisateur se déconnecte ou lorsque toutes les sessions de l'utilisateur sont terminées. Vous pouvez utiliser plusieurs méthodes pour modifier ce comportement par défaut dans systemd. Deux options sont explorées ici.
Utilisez la commande loginctl pour activer les utilisateurs systemd linger
La commande loginctl permet de modifier le comportement par défaut d'un utilisateur spécifique et d'activer les processus de cet utilisateur sur "linger" une fois la session de l'utilisateur terminée.
-
Utilisez l'utilitaire loginctl pour activer linger pour un utilisateur spécifique. Dans cette instance, activez le comportement systemd linger pour l'utilisateur 'oracle' :
sudo loginctl enable-linger oracle
-
Pour vérifier que le paramètre est appliqué, recherchez un fichier portant le même nom que l'utilisateur dans le répertoire
/var/lib/systemd/linger
.ls /var/lib/systemd/linger/oracle
La commande doit vérifier que le fichier existe.
Modifier le fichier systemd logind.conf
Systemd gère les événements de connexion utilisateur et fournit un fichier de configuration qui peut être modifié pour définir le comportement par défaut des différents événements liés à la session de l'utilisateur. Ce fichier de configuration se trouve dans /etc/systemd/logind.conf
.
-
Videz le contenu de la configuration existante à l'adresse
/etc/systemd/logind.conf
à l'écran pour vérifier :cat /etc/systemd/logind.conf
La plupart des options sont commentées mais affichent les valeurs par défaut de la compilation. Il existe trois options dans ce fichier qui permettent de contrôler la façon dont systemd gère les processus en cours d'exécution dans l'espace utilisateur lorsque la session de l'utilisateur se termine.
KillUserProcesses
: cette option peut contrôler si les processus utilisateur sont arrêtés par défaut à la fin de la session. La définition de cette option sur 'no' permet à systemd d'exécuter des processus utilisateur après la déconnexion d'un utilisateur du système.KillExcludeUsers
: si l'optionKillUserProcesses
est activée, cette option vous permet d'indiquer une liste d'utilisateurs séparés par des espaces pour lesquels systemd permet aux processus de continuer à s'exécuter une fois la session terminée. L'ajout d'un nom d'utilisateur à cette liste se comporte de la même manière que l'ajout d'un utilisateur au groupe Linger systemd à l'aide de la commande loginctl.KillOnlyUsers
: si l'optionKillUserProcesses
est désactivée, ce paramètre peut être utilisé pour indiquer une liste d'utilisateurs séparés par des espaces pour lesquels les processus doivent être arrêtés après la déconnexion.
Démonstration vidéo
Les démonstrations vidéo sur systemd sont disponibles à l'adresse https://www.youtube.com/watch?v=9uDvnZKhU8A et https://www.youtube.com/watch?v=Tkxs-wfZrnw si vous avez besoin de plus d'informations sur l'utilisation de systemd sur Oracle Linux 8.
Système systemd et gestionnaire des services sur Oracle Linux 8
Unités cible systemd sur Oracle Linux 8
Plus d'informations
- Documentation systemd : https://systemd.io/
- Page manuelle
systemd(1)
- Page manuelle
systemctl(1)
- Page manuelle
journalctl(1)
- Page manuelle
systemd.unit(5)
- Page manuelle
logind.conf(5)
- Oracle Linux 8 : Gestion de la configuration système principale
- Documentation Oracle Linux
Ressources de formation supplémentaires
Explorez d'autres exercices sur docs.oracle.com/learn ou accédez à davantage de contenu d'apprentissage gratuit sur le canal Oracle Learning YouTube. De plus, visitez le site education.oracle.com/learning-explorer pour devenir Oracle Learning Explorer.
Pour consulter la documentation du produit, consultez le centre d'aide Oracle.