Aller au contenu
Réussir mon BTS SIO

Tape une notion, une commande ou le nom d'une épreuve.

Par exemple

Chapitre 920 minIntermédiaire

Les tâches types de la phase 2

Par Josselyn C., prof de BTS SIO. Mis à jour le .

À la fin de ce chapitre, tu sauras

  • ajouter un VLAN, une règle de pare-feu ou un partage ;
  • modifier le DHCP et le DNS ;
  • sauvegarder, restaurer et superviser un élément ;
  • écrire un script et rendre compte d'un incident.

Les tâches types de la phase 2 de l'E6 SISR sont les évolutions qu'une commission peut demander en une heure sur une infrastructure : un VLAN, un changement DHCP ou DNS, une règle de pare-feu, un partage, de la répartition de charge, une sauvegarde, une supervision, un script, un incident à résoudre. Pour chacune, ce chapitre donne la méthode, un exemple complet sur l'infrastructure de Ravelle Conseil, les tests et les pièges.

L'exemple utilise l'infrastructure décrite au chapitre 4 : pare-feu pfSense PF-SIEGE, passerelle .254 de chaque VLAN ; commutateur Cisco SW-CORE ; VLAN 10 utilisateurs (10.10.10.0/24), VLAN 20 serveurs (10.10.20.0/24), VLAN 30 administration (10.10.30.0/24) ; contrôleurs de domaine SRV-AD1 (.10) et SRV-AD2 (.11) pour AD DS, DNS et DHCP en basculement ; domaine ravelle.lan. Adapte les noms à ton infrastructure : la méthode reste la même.

Ajouter un VLAN et le router

La demande type. Créer un nouveau périmètre : visiteurs, téléphonie, caméras, un nouveau service.

La méthode. Commutateur (VLAN, ports d'accès, trunk), puis pare-feu ou routeur (sous-interface ou interface VLAN, adresse de passerelle), puis adressage (DHCP), puis filtrage, puis tests.

L'exemple. Le VLAN 40 INVITES, 10.10.40.0/24, sur les ports Fa0/13 à Fa0/16.

Sur le commutateur :

text
SW-CORE# configure terminal
SW-CORE(config)# vlan 40
SW-CORE(config-vlan)# name INVITES
SW-CORE(config-vlan)# exit
SW-CORE(config)# interface range fa0/13 - 16
SW-CORE(config-if-range)# switchport mode access
SW-CORE(config-if-range)# switchport access vlan 40
SW-CORE(config-if-range)# spanning-tree portfast
SW-CORE(config-if-range)# exit
SW-CORE(config)# interface gi0/1
SW-CORE(config-if)# switchport trunk allowed vlan add 40
SW-CORE(config-if)# end
SW-CORE# show vlan brief
SW-CORE# show interfaces trunk
SW-CORE# copy running-config startup-config

Sur pfSense :

  1. Interfaces > Assignments > VLANs : ajoute le VLAN 40 sur l'interface parente du trunk (par exemple igb1), description INVITES.
  2. Interfaces > Assignments : ajoute la nouvelle interface igb1.40, active-la, renomme-la INVITES, adresse IPv4 statique 10.10.40.254/24.
  3. L'adressage et le filtrage suivent dans les tâches DHCP et DNS et pare-feu.

Les tests. show interfaces trunk liste 10, 20, 30 et 40 sur Gi0/1 ; un poste branché sur Fa0/13 avec une adresse fixe 10.10.40.10 joint 10.10.40.254 ; un poste du VLAN 10 travaille toujours.

Les pièges. Oublier add sur le trunk et couper tous les autres VLAN. Oublier copy running-config startup-config. Sur pfSense, une nouvelle interface n'a aucune règle : tout y est bloqué par défaut, ce qui est sain mais surprend au premier test.

Modifier le DHCP et le DNS

La demande type. Une nouvelle étendue, une réservation pour une imprimante, un enregistrement DNS pour un nouveau service, un alias.

La méthode. Sur le serveur DHCP : étendue ou réservation, options (passerelle, DNS), réplication vers le partenaire de basculement. Sur le DNS : enregistrement A et, si besoin, PTR ou CNAME. Puis renouvellement du bail et résolution depuis un poste.

L'exemple 1 : l'étendue des invités. pfSense ne peut pas être à la fois serveur et relais DHCP. Comme il relaie déjà le DHCP des autres VLAN vers les serveurs Windows, l'étendue des invités va sur ces serveurs, en PowerShell sur SRV-AD1 :

powershell
Add-DhcpServerv4Scope -Name "Invites" -StartRange 10.10.40.50 -EndRange 10.10.40.200 `
    -SubnetMask 255.255.255.0 -LeaseDuration 0.04:00:00 -State Active
# Passerelle et DNS : le pare-feu. -Force saute la vérification du serveur DNS,
# qui n'est pas un serveur Windows.
Set-DhcpServerv4OptionValue -ScopeId 10.10.40.0 -Router 10.10.40.254 -DnsServer 10.10.40.254 -Force
# L'étendue rejoint la relation de basculement existante entre SRV-AD1 et SRV-AD2
Get-DhcpServerv4Failover | Select-Object Name, PartnerServer, ScopeId
Add-DhcpServerv4FailoverScope -Name "SRV-AD1-SRV-AD2" -ScopeId 10.10.40.0

Puis sur pfSense, Services > DHCP Relay : ajoute l'interface INVITES aux interfaces relayées (les serveurs de destination 10.10.20.10 et 10.10.20.11 y sont déjà).

L'exemple 2 : la nouvelle imprimante de la comptabilité. Une réservation et un nom DNS :

powershell
Add-DhcpServerv4Reservation -ScopeId 10.10.10.0 -IPAddress 10.10.10.20 `
    -ClientId "00-15-5D-0A-14-02" -Name "IMP-COMPTA" -Description "Imprimante comptabilité"
# Le basculement ne réplique pas tout seul les modifications : on réplique l'étendue
Invoke-DhcpServerv4FailoverReplication -ScopeId 10.10.10.0
Add-DnsServerResourceRecordA -ZoneName "ravelle.lan" -Name "imp-compta" -IPv4Address 10.10.10.20 -CreatePtr

Les tests. Sur un poste invité : ipconfig /release puis ipconfig /renew, et ipconfig /all montre une adresse entre .50 et .200, la passerelle et le DNS 10.10.40.254. Sur SRV-AD2 : Get-DhcpServerv4Reservation -ScopeId 10.10.10.0 montre la réservation répliquée. Depuis un poste du VLAN 10 : Resolve-DnsName imp-compta.ravelle.lan renvoie 10.10.10.20, et Resolve-DnsName 10.10.10.20 renvoie le nom (enregistrement PTR).

Les pièges. Oublier la réplication du basculement : le jour où SRV-AD1 tombe, l'imprimante change d'adresse. -CreatePtr échoue si la zone inverse 10.10.10.in-addr.arpa n'existe pas. Avec BIND sous Linux, oublier d'incrémenter le numéro de série de la zone : les serveurs secondaires ne se mettent pas à jour. Vérifie toujours avec named-checkzone avant rndc reload.

Ajouter une règle de pare-feu

La demande type. Autoriser un flux précis, en bloquer un autre, isoler un périmètre.

La méthode. Écris le flux en une ligne (source, destination, protocole, port, sens), choisis l'interface d'entrée, place la règle au bon rang, journalise les blocages, teste le flux autorisé et le flux interdit.

Trois principes de pfSense à connaître par cœur : une règle s'applique sur l'interface par laquelle le trafic entre dans le pare-feu ; les règles sont lues de haut en bas et la première qui correspond s'applique ; sur une interface sans règle de passage, tout est bloqué.

L'exemple 1 : isoler les invités. Règles de l'interface INVITES, dans cet ordre :

RangActionProtocoleSourceDestinationPortRôle
1AutoriserTCP/UDPINVITES netINVITES address53Résolution DNS par le pare-feu
2Bloquer, journaliserToutINVITES netAlias RESEAUX_PRIVES (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)ToutRien d'interne
3Bloquer, journaliserToutINVITES netThis Firewall (self)ToutPas d'accès à l'administration du pare-feu, même par son adresse publique
4AutoriserTCPINVITES netToutAlias WEB (80, 443)Internet en HTTP et HTTPS

La règle 3 couvre un oubli classique : l'adresse WAN du pare-feu n'est pas une adresse privée, la règle 2 ne la bloque pas, et la règle 4 laisserait un invité ouvrir l'interface d'administration en HTTPS.

L'exemple 2 : l'intranet en HTTPS seulement depuis les postes. Sur l'interface du VLAN 10, la règle « autoriser TCP de VLAN10 net vers SRV-LB (10.10.20.30) port 443 » se place avant la règle qui bloque VLAN10 net vers VLAN20 net, et après celle qui autorise les flux vers les contrôleurs de domaine (DNS, Kerberos, LDAP, SMB). Placée après le blocage, elle ne s'appliquerait jamais.

Les tests. Le flux autorisé et le flux interdit, depuis un poste de chaque côté :

powershell
Test-NetConnection -ComputerName srv-lb.ravelle.lan -Port 443   # TcpTestSucceeded : True
Test-NetConnection -ComputerName srv-lb.ravelle.lan -Port 80    # TcpTestSucceeded : False
Test-NetConnection -ComputerName 10.10.20.40 -Port 22           # False : SRV-BAK reste fermé

Puis Status > System Logs > Firewall : le blocage apparaît, avec la règle qui l'a produit.

Les pièges. Une règle sur la mauvaise interface (la règle d'un flux du VLAN 10 vers les serveurs va sur l'interface du VLAN 10, pas sur celle des serveurs). Un ordre qui rend une règle inutile. Les états : une connexion déjà établie peut survivre à une nouvelle règle de blocage, réinitialise les états (Diagnostics > States) avant de tester.

Installer un partage avec des droits par groupe

La demande type. Un nouveau dossier partagé réservé à un service.

La méthode. La règle AGDLP : les comptes (A) dans un groupe global (G) qui représente le métier, ce groupe dans un groupe de domaine local (DL) qui porte la permission (P). Droits NTFS précis, partage, puis mappage du lecteur par GPO.

L'exemple. Le partage Direction sur SRV-FIC :

powershell
New-ADGroup -Name "GG_Direction" -GroupScope Global -Path "OU=Groupes,DC=ravelle,DC=lan"
New-ADGroup -Name "DL_Direction_M" -GroupScope DomainLocal -Path "OU=Groupes,DC=ravelle,DC=lan"
Add-ADGroupMember -Identity "GG_Direction" -Members "h.garnier", "k.morel", "s.benali"
Add-ADGroupMember -Identity "DL_Direction_M" -Members "GG_Direction"

# Sur SRV-FIC
New-Item -Path "D:\Partages\Direction" -ItemType Directory
# Héritage coupé ; SID plutôt que noms de groupes, qui changent avec la langue de Windows :
# *S-1-5-32-544 = Administrateurs, *S-1-5-18 = Système
icacls "D:\Partages\Direction" /inheritance:r `
    /grant "*S-1-5-32-544:(OI)(CI)F" "*S-1-5-18:(OI)(CI)F" "RAVELLE\DL_Direction_M:(OI)(CI)M"
New-SmbShare -Name "Direction" -Path "D:\Partages\Direction" `
    -ChangeAccess "RAVELLE\DL_Direction_M" -FullAccess "RAVELLE\Admins du domaine" `
    -FolderEnumerationMode AccessBased

Le lecteur R: se mappe par une préférence de GPO (Configuration utilisateur > Préférences > Paramètres Windows > Mappages de lecteurs) avec un ciblage sur le groupe GG_Direction.

Les tests. Avec un compte directeur : ouvrir \\SRV-FIC\Direction, créer et supprimer un fichier. Avec un compte de la comptabilité : le partage n'apparaît pas dans \\SRV-FIC (énumération basée sur l'accès), et le chemin direct renvoie « accès refusé ». Sur le serveur : Get-SmbShareAccess Direction et icacls D:\Partages\Direction.

Les pièges. Tester avec une session ouverte avant l'ajout au groupe : le ticket Kerberos ne contient pas encore le nouveau groupe. Déconnecte et reconnecte l'utilisateur, ou lance klist purge. Le nom « Admins du domaine » est celui d'un Windows Server en français : sur un serveur en anglais, c'est « Domain Admins ».

Ajouter un serveur à la répartition de charge

La demande type. Ajouter un serveur, changer l'algorithme, ajouter un contrôle de santé, retirer un serveur pour maintenance sans coupure.

La méthode. Préparer le nouveau serveur à l'identique, l'ajouter au groupe du répartiteur, vérifier la configuration avant de recharger, prouver la répartition et la tolérance de panne.

L'exemple. Le groupe de l'intranet dans /etc/haproxy/haproxy.cfg sur SRV-LB, après ajout de WEB3 (10.10.20.33) :

text
frontend intranet
    bind 10.10.20.30:443 ssl crt /etc/haproxy/certs/intranet.pem
    default_backend web_intranet

backend web_intranet
    balance roundrobin
    option httpchk GET /sante
    server web1 10.10.20.31:80 check
    server web2 10.10.20.32:80 check
    server web3 10.10.20.33:80 check

option httpchk GET /sante interroge régulièrement la page /sante de chaque serveur : un serveur qui ne répond pas 200 est retiré du groupe jusqu'à son retour.

bash
haproxy -c -f /etc/haproxy/haproxy.cfg      # « Configuration file is valid »
systemctl reload haproxy                     # rechargement sans couper les connexions
echo "show servers state" | socat stdio /run/haproxy/admin.sock

Les tests. Ajoute sur chaque serveur web une page de test qui affiche son nom, puis appelle-la six fois de suite : les réponses alternent entre web1, web2 et web3. Arrête Nginx sur WEB3 (systemctl stop nginx) : après quelques secondes, HAProxy le marque hors service et l'intranet répond toujours.

Les pièges. Recharger sans haproxy -c et casser le service pour tout le monde. Oublier d'autoriser le contrôle de santé dans le pare-feu local du nouveau serveur. Et la question qui viendra à la recette : HAProxy est lui-même un point unique de panne (la réponse est au chapitre 10).

Sauvegarder et restaurer

La demande type. Sauvegarder un nouveau dossier ou un nouveau serveur, changer la rétention, prouver une restauration.

La méthode. Quoi sauvegarder, où, à quelle fréquence, combien de temps (rétention), chiffré ou non ; une première sauvegarde manuelle ; la planification ; un test de restauration, sans lequel une sauvegarde n'est qu'une hypothèse. La règle 3-2-1 sert d'argument : 3 copies, sur 2 supports différents, dont 1 hors site.

L'exemple. Le dossier /srv/partages/paie de SRV-FIC, sauvegardé avec BorgBackup sur SRV-BAK :

Une seule fois, sur SRV-FIC, avec un accès SSH par clé vers le compte backup de SRV-BAK :

bash
borg init --encryption=repokey backup@srv-bak:/srv/borg/paie
borg key export backup@srv-bak:/srv/borg/paie /root/cle-depot-paie.txt   # copie à ranger hors du serveur

Le script /usr/local/sbin/sauvegarde-paie.sh :

bash
#!/bin/bash
set -euo pipefail
export BORG_REPO='backup@srv-bak:/srv/borg/paie'
export BORG_PASSCOMMAND='cat /root/.borg-paie'      # fichier lisible par root seul (chmod 600)
borg create --stats --compression zstd ::paie-{now:%Y-%m-%d_%H%M} /srv/partages/paie
borg prune --keep-daily 7 --keep-weekly 4           # la rétention demandée
borg compact                                        # Borg 1.2 et plus : libère l'espace des archives supprimées

La planification par cron, dans /etc/cron.d/sauvegarde-paie :

text
# Chaque nuit à 1 h 30, journal dans syslog
30 1 * * * root /usr/local/sbin/sauvegarde-paie.sh 2>&1 | logger -t sauvegarde-paie

Les tests. borg list backup@srv-bak:/srv/borg/paie montre l'archive. Pour la restauration, supprime un fichier de test, puis :

bash
cd /tmp && borg extract backup@srv-bak:/srv/borg/paie::paie-2026-04-12_0130 srv/partages/paie/bulletins/test.pdf
sha256sum /tmp/srv/partages/paie/bulletins/test.pdf    # compare avec l'empreinte notée avant suppression

Borg enregistre les chemins sans la barre oblique initiale : extract restaure dans le dossier courant, d'où le cd /tmp qui évite d'écraser l'original.

Les pièges. Une sauvegarde jamais restaurée. Le mot de passe ou la clé du dépôt rangés seulement sur le serveur sauvegardé : s'il brûle, la sauvegarde est illisible. rsync --delete présenté comme une sauvegarde : c'est un miroir, une suppression accidentelle se propage à la copie la nuit suivante.

Superviser un nouvel élément

La demande type. Superviser un nouveau serveur ou service, ajouter un seuil, être alerté.

La méthode. Agent sur l'hôte, hôte et modèle dans le serveur de supervision, déclencheur avec un seuil adapté à la criticité, action de notification vers les bonnes personnes, puis un test qui provoque vraiment l'alerte.

L'exemple. Superviser WEB3 avec Zabbix 7.0. Sur WEB3 :

bash
apt install zabbix-agent2     # depuis le dépôt officiel de Zabbix

Dans le fichier /etc/zabbix/zabbix_agent2.conf, règle ces trois paramètres :

ini
Server=10.10.30.20
ServerActive=10.10.30.20
Hostname=WEB3

Puis redémarre l'agent et active-le au démarrage :

bash
systemctl restart zabbix-agent2
systemctl enable zabbix-agent2

Dans l'interface de Zabbix :

  1. Data collection > Hosts > Create host : nom WEB3 (identique au paramètre Hostname de l'agent), groupe Serveurs web, interface agent 10.10.20.33 port 10050, modèle Linux by Zabbix agent.
  2. Le modèle fournit déjà un déclencheur sur l'espace disque. Pour un seuil à 85 % sur /, ajoute sur l'hôte la macro {$VFS.FS.PUSED.MAX.WARN:"/"} avec la valeur 85.
  3. Alerts > Actions > Trigger actions : une action existe déjà pour le groupe Serveurs web si ta réalisation en a une ; sinon, crée-la (condition sur le groupe d'hôtes et la gravité, opération « envoyer un message » au groupe d'utilisateurs du service informatique par courriel).

Les tests. Depuis le serveur Zabbix, zabbix_get -s 10.10.20.33 -k agent.ping renvoie 1. L'icône de disponibilité ZBX de l'hôte passe au vert. Pour l'alerte, remplis le disque au-delà du seuil puis libère-le :

bash
fallocate -l 5G /var/tmp/test-alerte.img    # ajuste la taille pour dépasser 85 %
rm /var/tmp/test-alerte.img                 # après réception de l'alerte

Le problème apparaît dans Monitoring > Problems, le courriel arrive, puis le courriel de résolution.

Les pièges. Le port 10050 bloqué entre le VLAN 30 et le VLAN 20 : ajoute la règle sur l'interface d'administration du pare-feu. Avec ServerActive, l'agent ouvre aussi des connexions TCP 10051 du VLAN 20 vers ZABBIX : règle sur l'interface du VLAN 20, ou retire ServerActive si tu n'utilises que des vérifications passives. Un nom d'hôte différent entre l'agent et l'interface, qui casse les vérifications actives. Une alerte jamais testée. Des alertes trop nombreuses que plus personne ne lit : la grille parle d'alertes « adaptées à la criticité du service ».

Écrire un script d'administration

La demande type. Automatiser une tâche répétitive : créer des comptes, vérifier des services, sauvegarder des configurations, produire un rapport.

La méthode. Lire l'entrée, valider chaque élément, agir, gérer les erreurs sans tout arrêter, journaliser ; tester d'abord à blanc (-WhatIf en PowerShell), puis en vrai sur un jeu réduit.

L'exemple. Créer les comptes des saisonniers à partir de saisonniers.csv (colonnes Prenom;Nom;FinContrat) :

powershell
# creer-saisonniers.ps1
param([string]$Fichier = "C:\Scripts\saisonniers.csv")
$mdp = Read-Host "Mot de passe initial" -AsSecureString
$journal = "C:\Scripts\saisonniers-$(Get-Date -Format yyyyMMdd-HHmm).log"

Import-Csv -Path $Fichier -Delimiter ';' -Encoding UTF8 | ForEach-Object {
    # p.nom, sans accent ni espace
    $login = ($_.Prenom.Substring(0,1) + '.' + $_.Nom).ToLower() -replace '\s', ''
    $login = $login.Normalize([Text.NormalizationForm]::FormD) -replace '\p{Mn}', ''

    if (Get-ADUser -Filter "SamAccountName -eq '$login'") {
        Add-Content $journal "AVERTISSEMENT $login existe déjà, ignoré"
        return    # passe à la ligne suivante du fichier
    }
    try {
        New-ADUser -Name "$($_.Prenom) $($_.Nom)" -GivenName $_.Prenom -Surname $_.Nom `
            -SamAccountName $login -UserPrincipalName "$login@ravelle.lan" `
            -Path "OU=Saisonniers,OU=Utilisateurs,DC=ravelle,DC=lan" `
            -AccountPassword $mdp -ChangePasswordAtLogon $true -Enabled $true `
            -AccountExpirationDate ([datetime]::ParseExact($_.FinContrat, 'dd/MM/yyyy', $null))
        Add-ADGroupMember -Identity "GG_Saisonniers" -Members $login
        Add-Content $journal "OK $login créé"
    } catch {
        Add-Content $journal "ERREUR $login : $($_.Exception.Message)"
    }
}
Get-Content $journal

Les tests. Lance le script sur un fichier de deux lignes, vérifie les comptes (Get-ADUser -Filter * -SearchBase "OU=Saisonniers,OU=Utilisateurs,DC=ravelle,DC=lan" -Properties AccountExpirationDate), puis relance-le : aucun doublon, deux avertissements au journal. Teste un nom avec accent (« Éloïse Février » donne e.fevrier).

Les pièges. Le mot de passe en clair dans le CSV ou dans le script. Un return confondu avec un arrêt du script : dans ForEach-Object, il passe seulement à l'élément suivant. Un fichier enregistré par un tableur dans un autre encodage, qui abîme les accents : vérifie l'encodage de l'export. Un script que tu ne sais pas modifier en direct : la commission te demandera d'ajouter une colonne ou un groupe.

Résoudre un incident et en rendre compte

La demande type. « Depuis ce matin, X ne fonctionne plus » : diagnostiquer, corriger, rédiger le rapport d'incident. La commission a parfois provoqué la panne avant ton passage.

La méthode. Qualifier (qui est touché, depuis quand, quel impact, quelle urgence), reproduire, diagnostiquer par couches, corriger, vérifier, empêcher que ça recommence, rendre compte.

L'exemple. « Les postes du VLAN 10 n'obtiennent plus d'adresse depuis ce matin. »

  1. Qualifier. Tous les postes du VLAN 10 ou un seul ? Ceux qui avaient déjà un bail fonctionnent encore jusqu'à son expiration ; les nouveaux reçoivent une adresse en 169.254.x.x (adressage automatique privé, signe qu'aucun serveur DHCP n'a répondu). Impact : élevé, toute arrivée ou tout redémarrage est bloqué.
  2. Couche 2. show vlan brief : les ports des postes sont bien dans le VLAN 10 ; show interfaces trunk : le VLAN 10 passe vers le pare-feu.
  3. Couche 3. Un poste en adresse fixe temporaire 10.10.10.99 joint 10.10.10.254 : la passerelle fonctionne.
  4. Le relais. Services > DHCP Relay sur pfSense : le service est-il actif, le VLAN 10 est-il dans les interfaces relayées, les serveurs de destination sont-ils les bons ?
  5. Le serveur. Get-DhcpServerv4Scope sur SRV-AD1 et SRV-AD2 : étendue active ? Get-DhcpServerv4ScopeStatistics : étendue pleine ?
  6. La preuve. Une capture Wireshark ou tcpdump -ni igb1.10 port 67 or port 68 sur le pare-feu (Diagnostics > Packet Capture) montre les requêtes DISCOVER sans OFFER en retour.

Suppose que l'étape 4 révèle que le VLAN 10 a été retiré des interfaces relayées. Tu le remets, tu renouvelles le bail d'un poste, tu vérifies trois postes.

Le rapport d'incident.

RubriqueContenu
Détection8 h 40, appel de l'accueil : deux postes redémarrés sans réseau
ImpactTous les postes du VLAN 10 qui demandent un bail, soit les postes redémarrés depuis 7 h 50
DiagnosticPorts et trunk corrects ; passerelle joignable ; capture : requêtes DHCP du VLAN 10 non relayées
CauseL'interface du VLAN 10 ne figurait plus dans la liste des interfaces relayées par pfSense, après une modification de la veille
CorrectionInterface réajoutée au relais à 9 h 05 ; trois postes testés, baux obtenus de SRV-AD1
PréventionToute modification du pare-feu passe par un export de config.xml et une ligne dans le journal des changements de GLPI ; un élément Zabbix surveille le nombre de baux distribués

Les pièges. Corriger sans comprendre (redémarrer le pare-feu « pour voir »). Oublier la prévention : c'est elle qui fait passer de l'incident au problème, et la grille parle de « mesures correctives proposées ou mises en œuvre ».

Chapitre terminé !

Tu as lu ce chapitre jusqu'au bout. Passe au suivant tant que c'est frais.

chapitres
–
de série
–
du cours
–
Chapitre suivant : La recette et l'entretien d'explicitationRevoir le sommaire du cours