The Linux Craftsman - Contributions [fr]

Ifcfg-ethX

2026-01-25T09:11:42Z

Jc.forton : /* Exemple */

= Principe =

Tout ce passe dans le dossier ''/etc/sysconfig/network-scripts''

Dans ce répertoire il y a plusieurs fichiers et notamment les fichiers de configuration des interfaces réseaux qui commencent tous par ''ifcfg-X''

Remplacez ''X'' par le nom de l'interface réseau et, si le fichier n'existe pas, il suffit de le créer !

= Exemple =

Prenons comme exemple ''eth0''. Son fichier de configuration sera ''ifcfg-eth0''

<source lang=bash>
DEVICE=eth0
HWADDR=DE:B4:49:A5:3A:07
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=yes
BOOTPROTO=dhcp
PEERDNS=no
DOMAIN="tala-informatique.fr labo.tala-informatique.fr"
</source>

* DEVICE → indique le nom de l'interface
* TYPE → précise le type de périphérique, peut prendre les valeurs [Ethernet|Bridge|Vlan]
* ONBOOT → indique si l'interface doit démarrer au démarrage de la machine
* NM_CONTROLLED → précise si le Network Manager doit contrôler cette interface (en général oui)
* BOOTPROTO → indique le type de démarrage de l'interface, peut prendre les valeurs [dhcp|static|none]
** Si la valeur ''static'' est utilisée, il faudra également les paramètres suivants:
*** IPADDR → pour l'adresse IP
*** NETMASK → pour le masque de sous-réseau
*** GATEWAY → pour spécifier, le cas échéant, une passerelle
* DNS1 → permet de spécifier un serveur DNS primaire
* DNS2 → permet de spécifier un serveur DNS secondaire
*PEERDNS → précise si les ''DNS'' fournis en DHCP sur cette interface doivent être ajoutés au fichier ''/etc/resolv.conf''
*MACADDR → permet de spécifier une adresse ''MAC'' à utiliser, particulièrement pratique pour les déplacement de VMs, ou pour les baux ''DHCP'' statiques.
*DOMAIN → permet de spécifier autant de domaine de recherche qui seront ajouté au fichier ''/etc/resolv.conf''
*MTU → permet de modifier la taille du payload (Maximum Transmission Unit) avant fragmentation. Permet d'activer les ''Jumbo Frame'' pour baisser l'utilisation du CPU dans les réseaux supérieurs au ''gigabit''.

= Que faire si ma carte n'a pas le bon numéro ?? =

Lorsque l'on ajoute / enlève une carte réseau, le noyau incrémente le numéro de celle-ci. Par exemple, on avait eth0 et puis on se retrouve avec eth1...

C'est ''UDEV'' qui, à chaque fois que l'on insère une carte réseau avec une adresse MAC différente, change de numéro.

On peut modifier cela dans le fichier ''/etc/udev/rules.d/70-persistent-net.rules''
<source lang=bash>
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x1022:0x2000 (pcnet32)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:f7:cf:de", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x1022:0x2000 (pcnet32)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:e6:c5:aa", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
</source>

Il suffit de supprimer la première ligne qui fait référence à l'ancienne carte et, de décrémenter le numéro de la deuxième ligne pour que ''eth1'' devienne ''eth0'':
<source lang=bash>
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x1022:0x2000 (pcnet32)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:e6:c5:aa", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
</source>

Pour que les modifications soient effectives, il faut redémarrer le système.

{|style="width:90%" align="center"
|
[[Fichier:Warning-icon.png|centré|100px]]
|style="width:5%"|
|valign="top"|
Sur les distributions à base de Debian, vous êtes obligé de mettre à jour ''initramfs'' pour que les modifications soient prises en compte avant de redémarrer le système :
<source lang=bash>
# update-initramfs -u
</source>
|}

Ifcfg-ethX

2026-01-25T09:09:22Z

Jc.forton : /* Que faire si ma carte n'a pas le bon numéro ?? */

= Principe =

Tout ce passe dans le dossier ''/etc/sysconfig/network-scripts''

Dans ce répertoire il y a plusieurs fichiers et notamment les fichiers de configuration des interfaces réseaux qui commencent tous par ''ifcfg-X''

Remplacez ''X'' par le nom de l'interface réseau et, si le fichier n'existe pas, il suffit de le créer !

= Exemple =

Prenons comme exemple ''eth0''. Son fichier de configuration sera ''ifcfg-eth0''

<source lang=bash>
DEVICE=eth0
HWADDR=DE:B4:49:A5:3A:07
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=yes
BOOTPROTO=dhcp
PEERDNS=no
DOMAIN="tala-informatique.fr labo.tala-informatique.fr"
</source>

* DEVICE → indique le nom de l'interface
* TYPE → précise le type de périphérique, peut prendre les valeurs [Ethernet|Bridge|Vlan]
* ONBOOT → indique si l'interface doit démarrer au démarrage de la machine
* NM_CONTROLLED → précise si le Network Manager doit contrôler cette interface (en général oui)
* BOOTPROTO → indique le type de démarrage de l'interface, peut prendre les valeurs [dhcp|static|none]
** Si la valeur ''static'' est utilisée, il faudra également les paramètres suivants:
*** IPADDR → pour l'adresse IP
*** NETMASK → pour le masque de sous-réseau
*** GATEWAY → pour spécifier, le cas échéant, une passerelle
* DNS1 → permet de spécifier un serveur DNS primaire
* DNS2 → permet de spécifier un serveur DNS secondaire
*PEERDNS → précise si les ''DNS'' fournis en DHCP sur cette interface doivent être ajoutés au fichier ''/etc/resolv.conf''
*MACADDR → permet de spécifier une adresse ''MAC'' à utiliser, particulièrement pratique pour les déplacement de VMs, ou pour les baux ''DHCP'' statiques.
*DOMAIN → permet de spécifier autant de domaine de recherche qui seront ajouté au fichier ''/etc/resolv.conf''
*MTU → permet de modifier la taille du payload (Maximum Transmission Unit) avant fragmentation. Permet d'activer les ''Jumbo Frame'' pour baisser l'utilisation du CPU dans les réseaux ''Gigabit''.

= Que faire si ma carte n'a pas le bon numéro ?? =

Lorsque l'on ajoute / enlève une carte réseau, le noyau incrémente le numéro de celle-ci. Par exemple, on avait eth0 et puis on se retrouve avec eth1...

C'est ''UDEV'' qui, à chaque fois que l'on insère une carte réseau avec une adresse MAC différente, change de numéro.

On peut modifier cela dans le fichier ''/etc/udev/rules.d/70-persistent-net.rules''
<source lang=bash>
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x1022:0x2000 (pcnet32)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:f7:cf:de", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x1022:0x2000 (pcnet32)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:e6:c5:aa", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
</source>

Il suffit de supprimer la première ligne qui fait référence à l'ancienne carte et, de décrémenter le numéro de la deuxième ligne pour que ''eth1'' devienne ''eth0'':
<source lang=bash>
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x1022:0x2000 (pcnet32)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:e6:c5:aa", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
</source>

Pour que les modifications soient effectives, il faut redémarrer le système.

{|style="width:90%" align="center"
|
[[Fichier:Warning-icon.png|centré|100px]]
|style="width:5%"|
|valign="top"|
Sur les distributions à base de Debian, vous êtes obligé de mettre à jour ''initramfs'' pour que les modifications soient prises en compte avant de redémarrer le système :
<source lang=bash>
# update-initramfs -u
</source>
|}

Ifcfg-ethX

2026-01-25T09:08:37Z

Jc.forton : /* Exemple */

= Principe =

Tout ce passe dans le dossier ''/etc/sysconfig/network-scripts''

Dans ce répertoire il y a plusieurs fichiers et notamment les fichiers de configuration des interfaces réseaux qui commencent tous par ''ifcfg-X''

Remplacez ''X'' par le nom de l'interface réseau et, si le fichier n'existe pas, il suffit de le créer !

= Exemple =

Prenons comme exemple ''eth0''. Son fichier de configuration sera ''ifcfg-eth0''

<source lang=bash>
DEVICE=eth0
HWADDR=DE:B4:49:A5:3A:07
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=yes
BOOTPROTO=dhcp
PEERDNS=no
DOMAIN="tala-informatique.fr labo.tala-informatique.fr"
</source>

* DEVICE → indique le nom de l'interface
* TYPE → précise le type de périphérique, peut prendre les valeurs [Ethernet|Bridge|Vlan]
* ONBOOT → indique si l'interface doit démarrer au démarrage de la machine
* NM_CONTROLLED → précise si le Network Manager doit contrôler cette interface (en général oui)
* BOOTPROTO → indique le type de démarrage de l'interface, peut prendre les valeurs [dhcp|static|none]
** Si la valeur ''static'' est utilisée, il faudra également les paramètres suivants:
*** IPADDR → pour l'adresse IP
*** NETMASK → pour le masque de sous-réseau
*** GATEWAY → pour spécifier, le cas échéant, une passerelle
* DNS1 → permet de spécifier un serveur DNS primaire
* DNS2 → permet de spécifier un serveur DNS secondaire
*PEERDNS → précise si les ''DNS'' fournis en DHCP sur cette interface doivent être ajoutés au fichier ''/etc/resolv.conf''
*MACADDR → permet de spécifier une adresse ''MAC'' à utiliser, particulièrement pratique pour les déplacement de VMs, ou pour les baux ''DHCP'' statiques.
*DOMAIN → permet de spécifier autant de domaine de recherche qui seront ajouté au fichier ''/etc/resolv.conf''
*MTU → permet de modifier la taille du payload (Maximum Transmission Unit) avant fragmentation. Permet d'activer les ''Jumbo Frame'' pour baisser l'utilisation du CPU dans les réseaux ''Gigabit''.

= Que faire si ma carte n'a pas le bon numéro ?? =

Lorsque l'on ajoute / enlève une carte réseau, le noyau incrémente le numéro de celle-ci. Par exemple, on avait eth0 et puis on se retrouve avec eth1...

C'est ''UDEV'' qui, à chaque fois que l'on insère une carte réseau avec une adresse MAC différente, change de numéro.

On peut modifier cela dans le fichier ''/etc/udev/rules.d/70-persistent-net.rules''
<source lang=bash>
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x1022:0x2000 (pcnet32)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:f7:cf:de", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x1022:0x2000 (pcnet32)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:e6:c5:aa", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
</source>

Il suffit de supprimer la première ligne qui fait référence à l'ancienne carte et, de décrémenter le numéro de la deuxième ligne pour que ''eth1'' devienne ''eth0'':
<source lang=bash>
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x1022:0x2000 (pcnet32)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:e6:c5:aa", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
</source>

Pour que les modifications soient effectives, il faut redémarrer le système.

{|style="width:90%" align="center"
|
[[Fichier:Warning-icon.png|centré|100px]]
|style="width:5%"|
|valign="top"|
Sur les distributions à base de Debian, vous êtes obligé de mettre à jour ''initramfs'' pour que les modifications soient prises en compte :
<source lang=bash>
# update-initramfs -u
</source>
|}

Ifcfg-ethX

2026-01-25T09:08:18Z

Jc.forton : /* Que faire si ma carte n'a pas le bon numéro ?? */

= Principe =

Tout ce passe dans le dossier ''/etc/sysconfig/network-scripts''

Dans ce répertoire il y a plusieurs fichiers et notamment les fichiers de configuration des interfaces réseaux qui commencent tous par ''ifcfg-X''

Remplacez ''X'' par le nom de l'interface réseau et, si le fichier n'existe pas, il suffit de le créer !

= Exemple =

Prenons comme exemple ''eth0''. Son fichier de configuration sera ''ifcfg-eth0''

<pre>
DEVICE=eth0
HWADDR=DE:B4:49:A5:3A:07
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=yes
BOOTPROTO=dhcp
PEERDNS=no
DOMAIN="tala-informatique.fr labo.tala-informatique.fr"
</pre>

* DEVICE → indique le nom de l'interface
* TYPE → précise le type de périphérique, peut prendre les valeurs [Ethernet|Bridge|Vlan]
* ONBOOT → indique si l'interface doit démarrer au démarrage de la machine
* NM_CONTROLLED → précise si le Network Manager doit contrôler cette interface (en général oui)
* BOOTPROTO → indique le type de démarrage de l'interface, peut prendre les valeurs [dhcp|static|none]
** Si la valeur ''static'' est utilisée, il faudra également les paramètres suivants:
*** IPADDR → pour l'adresse IP
*** NETMASK → pour le masque de sous-réseau
*** GATEWAY → pour spécifier, le cas échéant, une passerelle
* DNS1 → permet de spécifier un serveur DNS primaire
* DNS2 → permet de spécifier un serveur DNS secondaire
*PEERDNS → précise si les ''DNS'' fournis en DHCP sur cette interface doivent être ajoutés au fichier ''/etc/resolv.conf''
*MACADDR → permet de spécifier une adresse ''MAC'' à utiliser, particulièrement pratique pour les déplacement de VMs, ou pour les baux ''DHCP'' statiques.
*DOMAIN → permet de spécifier autant de domaine de recherche qui seront ajouté au fichier ''/etc/resolv.conf''
*MTU → permet de modifier la taille du payload (Maximum Transmission Unit) avant fragmentation. Permet d'activer les ''Jumbo Frame'' pour baisser l'utilisation du CPU dans les réseaux ''Gigabit''.

= Que faire si ma carte n'a pas le bon numéro ?? =

Lorsque l'on ajoute / enlève une carte réseau, le noyau incrémente le numéro de celle-ci. Par exemple, on avait eth0 et puis on se retrouve avec eth1...

C'est ''UDEV'' qui, à chaque fois que l'on insère une carte réseau avec une adresse MAC différente, change de numéro.

On peut modifier cela dans le fichier ''/etc/udev/rules.d/70-persistent-net.rules''
<source lang=bash>
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x1022:0x2000 (pcnet32)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:f7:cf:de", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x1022:0x2000 (pcnet32)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:e6:c5:aa", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
</source>

Il suffit de supprimer la première ligne qui fait référence à l'ancienne carte et, de décrémenter le numéro de la deuxième ligne pour que ''eth1'' devienne ''eth0'':
<source lang=bash>
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x1022:0x2000 (pcnet32)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:e6:c5:aa", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
</source>

Pour que les modifications soient effectives, il faut redémarrer le système.

{|style="width:90%" align="center"
|
[[Fichier:Warning-icon.png|centré|100px]]
|style="width:5%"|
|valign="top"|
Sur les distributions à base de Debian, vous êtes obligé de mettre à jour ''initramfs'' pour que les modifications soient prises en compte :
<source lang=bash>
# update-initramfs -u
</source>
|}

The Linux Craftsman

2026-01-25T07:11:21Z

Jc.forton : /* La pratique */

= Ce wiki =
<div align="center">
{|class="wikitable" width="100%"
! Le contenu !! Public visé !! L'auteur
|-valign=top
|width="33%"|
Ce wiki propose des articles, cours, TPs et TDs sur des sujets gravitant autour des technologies du système d'information, notamment sur le système Linux, sur la distribution CentOS et maintenant Rocky Linux.

Vous y trouverez des articles traitant de la mise en place de services réseaux tels que DHCP et DNS mais également des articles sur la mise en place de pare-feu, site Web, etc... Il y a un peu de tout et je vous encourage à utiliser le champ de recherche pour trouver ce dont vous avez besoin.
|width="33%"|

Ce wiki s'adresse principalement à mes élèves mais il peut également servir à des enseignants qui désirent monter leurs cours sans se "prendre la tête".

Tout est disponible sous [http://www.gnu.org/copyleft/fdl.html licence GNU Free Documentation License 1.3] ou ultérieure et vous pouvez récupérer les contenus et en faire ce que vous voulez !
|width="33%"|

Je m'appelle Jean-Christophe FORTON et je suis professeur d'informatique depuis 2011 mais cela n'a pas toujours été mon métier, plus d'info [[jcf|ici]]...

N'hésitez pas à faire un tour sur :
{|
|-valign=middle
|align=center|
[[Image:Logo-YouTube-rouge.png|30px|link=https://www.youtube.com/@tala-informatique]]
|| ma chaîne Youtube pour découvrir mes aventures ou (re)visionner certains cours
|-valign=middle
|align=center|
[[Fichier:Logo-Tipeee.png|27px|link=https://fr.tipeee.com/tala-informatique]]
||mon Tipeee pour me remercier
|}
|}
</div>

= Les cours =
<div align="center">
{|class="wikitable" width="100%"
! Système !! Sécurité !! Réseaux !! Développement !! Général
|-valign=top
||
<hr>
<div align="center">Linux</div>
<hr>
* [[:Media:intro_linux.pdf|Introduction au système Linux]]
* [[:Media:tp_linux_commandes_de_bases.pdf|TP Linux : commandes de bases]]
<hr>
<div align="center">Windows</div>
<hr>
* Architecture des ordinateurs en environnement Windows
** [[:Media:materiel.pdf|Le matériel]]
** [[:Media:system_exploitation.pdf|Le système d'exploitation]]
** [[:Media:gestion_disques.pdf|La gestion des disques]]
** [[:Media:sauvegarde.pdf|La sauvegarde]]
* Active Directory
** [[:Media:ad_intro.pdf|Les principes fondamentaux]]
** [[:Media:ad_gpo.pdf|Gestion des stratégies]]
||
<hr>
<div align="center">Réseaux</div>
<hr>
* [[:Media:Les pare-feux.pdf|Les pare-feux]]
* [[:Media:Les pare-feux_tech.pdf|Les pare-feux (fiche technique)]]
* [[:Media:Les VPN.pdf|Les VPN]]
* [[:Media:Haute_dispo.pdf|Haute disponibilité]]
* [[:Media:sauvegarde_pca.pdf|La sauvegarde]]
<hr>
<div align="center">Sécurité des Systèmes d’Information</div>
<hr>
* [[:Media:principes_SSI.pdf|Les principes fondamentaux]]
* [[:Media:implémentation_concrete_SSI.pdf|Implémentation concrète de la sécurité]]
* [[:Media:cryptographie.pdf|Cryptographie]]
* [[:Media:TD1_SSI.pdf|TD1: Principes Fondamentaux]]
* [[:Media:TP1_SSI.pdf|TP1: Écoute d'une connexion]]
* [[:Media:TP2_SSI.pdf|TP2: Chiffrement asymétrique avec PGP]]
<hr>
<div align="center">Web</div>
<hr>
* [[:Media:apache server.pdf|Le serveur Apache]]
* [[:Media:pilotage web bdd.pdf|Pilotage d'une page web]]
* [[:Media:web app security.pdf|Sécurité des applications Web]]
||
<hr>
<div align="center">Modèle OSI</div>
<hr>
*[[:Media:OSI.pdf|Le modèle OSI en version cours]]
*[[:Media:OSI_Slides.pdf|Le modèle OSI en version slides]]
<hr>
<div align="center">OSI 1 </div>
<hr>
* [[:Media:Normes_cablages.pdf|Les normes de câblage]]
<hr>
<div align="center">OSI 2</div>
<hr>
* [[:Media:Ethernet-802.3.pdf|La norme Ethernet (802.3)]]
* [[:Media:WiFi-802.11.pdf|La norme Wi-Fi (802.11)]]
* [[:Media:Bridge.pdf|Les bridges]]
* [[:Media:STP.pdf|Spanning Tree Protocol]]
* [[:Media:VLAN.pdf|Les Vlans]]
<hr>
<div align="center">OSI 3+</div>
<hr>
* Routage:
** [[:Media:CIDR.pdf|Classless Inter-Domain Routing]]
** [[:Media:resume_protocoles_vecteur_distance.pdf|Résumé sur les protocoles à vecteur de distance]]
** [[:Media:EIGRP.pdf|Enhanced Interior Gateway Routing Protocol]]
** [[:Media:OSPF.pdf|Open Shortest Path First]]
** [[:Media:BGP.pdf|Border Gateway Protocol]]
*Services:
** [[:Media:DHCP.pdf|DHCP]]
** [[:Media:DNS.pdf|DNS]]
** [[:Media:SAMBA.pdf|Samba]]
<hr>
<div align="center">Qualité de service</div>
<hr>
* [[:Media:QoS.pdf|La QoS]]
* [[:Media:Iproute2_QoS.pdf|Iproute2 et la QoS]]
<hr>
<div align="center">Protocole</div>
<hr>
* [[:Media:HTTP.pdf|HTTP]]
* [[:Media:SNMP.pdf|SNMP]]
||
<hr>
<div align="center">L'algorithmique</div>
<hr>
* [[:Media:algo_intro.pdf|Introduction]]
* [[:Media:algo_langage.pdf|Le Langage]]
<hr>
<div align="center">SQL</div>
<hr>
* [[:Media:conception_bdd.pdf|Conception de base de données]]
* [[:Media:conception_bdd_simple.pdf|Conception de base de données (simplifié)]]
* [[:Media:langage_de_requête.pdf|Langage de requête]]
<hr>
<div align="center">Langages du Web</div>
<hr>
* [[:Media:HTML xHTML intro.pdf|Le langage HTML]]
* [[:Media:css.pdf|Le langage CSS]]
* [[:Media:javascript.pdf|Le langage JavaScript]]
* [[:Media:php.pdf|Le langage PHP]]
<hr>
<div align="center">Langage bas niveau</div>
<hr>
* [[:Media:C lang.pdf|Le langage C]]
<hr>
<div align="center">Architecture SOA</div>
<hr>
* [[:Media:webservices.pdf|Les Web Services RESTful]]
<hr>
<div align="center">Informatique embarquée</div>
<hr>
* [[:Media:arduino_avr.pdf|Arduino et AVR]]
* [[:Media:IOT.pdf|L'Internet des objets]]
||
<hr>
<div align="center">Gestion</div>
<hr>
* [[:Media:gestion_projet.pdf|Gestion de projet]]
<hr>
<div align="center">Bureautique</div>
<hr>
* [[:Media:powerpoint.pdf|PowerPoint]]
* [[:Media:excel.pdf|Excel]]
* [[:Media:bdd_com.pdf|Les bases de données]]
<hr>
<div align="center">Histoire / évolutions</div>
<hr>
* [[:Media:expertise_codage.pdf|Expertise codage]]
|}
</div>

= La pratique =
<div align="center">
{|class="wikitable" width="100%"
! Système !! Sécurité !! Réseaux !! Développement !! Embarquée !! Virtualisation
|-valign="top"
|align=left|
<hr>
<div align="center">Général</div>
<hr>
* [[Installation de CentOS]]
* [[Installation de Rocky]]
* [[migration_centos8torocky8| Migration CentOS 8 → Rocky 8]]
* [[upgrade_rocky8to9| Upgrade Rocky 8 → 9]]
* [[WSL | WSL : Installation de Linux sur Windows 10]]
* [[Vi / Vim]]
* [[linux_repository|Les dépots (EPEL, EL, ...)]]
* [[cron| Gestionnaire des tâches: cron]]
* [[rpm_yum| Gestionnaires de paquetages: RPM & YUM]]
* [[Les logs]]
* [[users_groups|Utilisateurs et groupes]]
* [[Gestion des disques]]
* CentOS ≥ 7 (≈ Rocky) [[Fichier:Warning-icon.png|20px]]
** [[systemctl|Systemctl sur SystemD]]
** [[systemctl service|Créer un service avec Systemctl (démon)]]
** [[iptables_on_systemd | Firewalld ?!? Rendez moi Iptables ! ]]
** [[chrony|''NTP'' est mort, vive ''Chrony'']]
* CentOS 6
** [[Gestionnaire de démarrage|Gestionnaire de démarrage SysVInit]]
** [[start_stop_daemon|Création d'un service avec start-stop-daemon (SysVInit)]]
<hr>
<div align="center">Réseaux</div>
<hr>
* [[ifcfg-ethX|Les interfaces réseaux]]
* [[sysconfig-network|Les paramètres réseaux]]
* [[resolv.conf|Configuration du client DNS]]
* [[ntpd|Configuration du client NTP]]
<hr>
<div align="center">Haute disponibilité</div>
<hr>
* [[drbd|Réplication à chaud avec DRBD]]
<hr>
<div align="center">Multimédia</div>
<hr>
* [[DLNA|Partage de contenu cross-platform avec DLNA]]
|
<hr>
<div align="center">Réseaux</div>
<hr>
* [[Iptables]]
* [[Squid]]
* [[:Media:Chillispot.pdf|Hotspot avec Chillispot]]
* [[Sécuriser un service avec Fail2ban]]
* [[Openvpn]]
* [[Wireguard]]
<hr>
<div align="center">Système</div>
<hr>
* [[SSH]]
* [[SELinux]]
|
<hr>
<div align="center">Les outils</div>
<hr>
* [[tcpdump | Le scanner ''tcpdump'']]
* [[iproute2 | Contrôle réseau avec la commande ''ip'']]
<hr>
<div align="center">OSI 2</div>
<hr>
* [[source routing|Le routage source]]
* [[bridge|Les bridges]]
* [[alias|Les alias]]
* [[vlan|Les vlans]]
* [[one-arm_router|La passerelle ''one-arm'']]
* [[transparent_firewall|Le proxy ''transparent'']]
<hr>
<div align="center">OSI 3+</div>
<hr>
* Services:
** [[DHCP]]
** [[DNS]]
*Haute-disponibilité
** [[Ucarp]]
<hr>
<div align="center">OSI 7</div>
<hr>
* Services:
** [[SAMBA]]
** [[HTTPD]]
** [[xmpp | Serveur XMPP avec Ejabberd]]
** [[vnc|Installer un serveur VNC]]
* Industrialisation:
** [[:Media:pxe.pdf|Monter un serveur PXE (pdf)]]
** [[PXE|Monter un serveur PXE]]
* Supervision
** [[Nagios| Nagios]]
** [[Cacti| Installer un serveur Cacti]]
** [[SNMP | Utiliser SNMP]]
<hr>
<div align="center">Cisco ISR (routeur)</div>
<hr>
* [[ISR-basics|Les bases]]
|
<hr>
<div align="center">Général</div>
<hr>
* [[eclipse_install|Mise en place de l'environnement de développement]]
* [[svn|Serveur de version SVN]]
<hr>
<div align="center">PHP</div>
<hr>
*Les basiques :
** [[php_httpd_install | Installation sous Linux]]
** [[php_devel| Premier projet en ''PHP'']]
** [[php_algo|Un peu d'algorithmique]]
** [[php_object| Les objets]]
** [[php_xdebug| Debugger avec ''Xdebug'']]
* La partie CLI :
** [[php_memcached| Memcached un serveur de cache]]
** [[php_daemon | Écriture d'un démon]]
** [[php_socket | Utilisation des sockets]]
* La partie Web :
** [[php_$get_$post_$session| Passer des informations entres pages]]
** [[php_pdo| Utiliser une base MySQL avec PDO]]
** [[php_slim | Le framework SLIM]]
<hr>
<div align="center">JavaScript</div>
<hr>
*Les basiques :
** [[js_devel| Premier projet en ''JavaScript'']]
** [[js_algo| Un peu d'algorithmique]]
** [[js_object| Les objets]]
*Les RIA (''R''ich ''I''nternet ''A''pplication) :
** [[js_AJAX| Client AJAX pour utiliser des Web Services]]
** [[js_AJAX_auth | Authentification avec un client AJAX]]
** [[js_AJAX_fetch_api | Découverte de l'API ''fetch'']]
<hr>
<div align="center">Java</div>
<hr>
*Les basiques :
** [[java_devel| Premier projet en ''Java'']]
** [[java_jar|Mon premier objet]]
** [[java_algo| Un peu d'algorithmique]]
* La partie Web:
** [[java_servlet|Les Servlets]]
** [[java_ws_restful| Web Service Restful]]
* Stocker des informations:
** [[java_mysql| Utiliser une base MySQL avec Java]]
** [[java_memcached| Memcached un serveur de cache]]
<hr>
<div align="center">C</div>
<hr>
*Les basiques :
** [[c_devel| Premier projet en ''C'']]
** [[c_devel_cross| Compilation croisée (Cross Compilation)]]
** [[c_algo| Un peu d'algorithmique]]
*Execution parallèle :
** [[c_pthread| Les threads]]
** [[c_fork| Les forks]]
* IPC:
** [[c_pipe| Les tubes]]
** [[c_semaphore| Les sémaphores]]
** [[c_signals| Les signaux POSIX]]
** [[c_socket| Les sockets]]
* GP-GPU avec CUDA:
** [[cuda_install| Installation de CUDA]]
** [[cuda_hello_world| Les concepts et bases]]
<hr>
<div align="center">Python</div>
<hr>
* [[python_devel| Premier projet en ''Python'']]
* [[python_algo|Un peu d'algorithmique]]
<hr>
<div align="center">SQL</div>
<hr>
* [[sql_install| Installation d'un SGBDR]]
* [[SQL_import| Importation d'une base de données]]
|
<hr>
<div align="center">Général</div>
<hr>
* [[Arduino_sketch_writing | Écriture d'un sketch]]
* [[Arduino_CH340_driver_install | Installation du pilote CH340 (Serial TTL)]]
* [[Arduino_FTDI_driver_install | Installation du pilote FTDI(Serial TTL)]]
* [[Arduino_CP210X_driver_install | Installation du pilote CP210X(Serial TTL)]]
* [[Arduino_Eclipse_sketch | Création d'un projet sous Eclipse]]
* [[arduino_diagram | Schémas des cartes Arduino]]
* [[esp8266_diagram | Schémas des cartes ESP8266]]
* [[esp32_diagram | Schémas des cartes ESP32]]
* [[sbc_diagram | Schémas des SBC]]
* [[µc_datasheet | Fiches techniques des microcontrôleurs]]
<hr>
<div align="center">Capteurs</div>
<hr>
* [[Arduino_LDR | Luminosité avec une photorésistance]]
* [[Arduino_BH1750 | Luminosité avec le BH1750]]
* [[Arduino_DS18B20 | Température avec le DS18B20]]
* [[Arduino_LM35DZ | Température avec le LM35]]
* [[Arduino_DHT11 | Température et humidité avec le DHT11]]
* [[Arduino_BMP280 | Température, pression et altitude avec le BMP280]]
* [[Arduino_A3144 | Effet de Hall (magnétisme) avec le A3144 ]]
* [[Arduino_SR501 | Détection de mouvement avec le SR501 (PIR) ]]
* [[Arduino_soil_moisture | Capteur d'humidité du sol ]]
<hr>
<div align="center">Communication</div>
<hr>
* Sans-fil:
** [[Arduino_HC12 | Communication RF433 avec un HC12]]
** [[Arduino_NRF24L01 | Communication 2.4Ghz avec un NRF24L01]]
** [[Arduino_ESP05 | Communication Wi-Fi avec un ESP-05]]
* Shield Ethernet (W5100):
** [[Arduino_W5100_intro | Présentation du shield]]
** [[Arduino_W5100_OSI3 | Configuration OSI 3]]
** [[Arduino_W5100_web_server | Utilisation du Shield Ethernet pour faire un serveur Web]]
<hr>
<div align="center">Composants et montages divers</div>
<hr>
* [[ potentiometre | Potentiomètre ]]
* [[ shift_register | Registre à décalage ]]
* [[ Arduino_2axis_joystick_button | Joystick 2 axes avec bouton ]]
* [[ Arduino_SD_CARD | Module pour cartes SD ]]
<hr>
<div align="center">ESP8266 / ESP32</div>
<hr>
* [[esp_ide_arduino | Cartes ESP et IDE Arduino]]
* [[esp8266_wifi | Utilisation du WiFi ]]
* [[esp8266_webserver | Utilisation du serveur web ]]
* [[esp8266_udp_server | Serveur UDP ]]
* [[esp8266_ntp_client | Client NTP ]]
* [[:Media:esp8266_tp_meteo_dht11.pdf | TP station météo avec le DHT11 ]]
<hr>
<div align="center">Raspberry / Banana / Orange Pi</div>
<hr>
* [[iso_install_sdcard | Installation d'une image ]]
* [[pi_java_install | Mise en place de Java ]]
* [[sbc_qemu_emulation | Émulation avec Qemu ]]
* [[Linux sunxi armbian gpio | Manipulation des GPIO sous Linux]]
* [[Linux sunxi armbian w1 | Utilisation du protocole OneWire sous Linux]]
* [[Linux uart sunxi armbian | Utilisation du protocole UART sous Linux]]
<hr>
<div align="center">Notions avancées</div>
<hr>
* Arduino (ATmega328)
** [[atmega328_registers | Manipulation de registres ]]
** [[atmega328_timers | Les timers ]]
|
<hr>
<div align="center">VmWare</div>
<hr>
* [[vmware_install | Installation ]]
* [[vmware_network | La partie réseau ]]
* [[vmware_create_vm | Création d'une machine virtuelle ]]
* [[vmware_debug_vm | Débogage réseau d'une machine virtuelle]]
<hr>
<div align="center">Proxmox</div>
<hr>
* [[proxmox_install | Installation ]]
* [[proxmox_nic_name | Les interfaces réseaux ]]
* [[proxmox_iptables | Utilisation d'iptables ]]
* [[proxmox_fail2ban | Fail2ban ]]
|}
</div>
<div style="visibility:hidden">
__TOC__
</div>
__NOTOC__

Vi / Vim

2026-01-23T05:14:48Z

Jc.forton : /* Dans tout le fichier */

= Introduction =

== Création d'un fichier texte ==

vi ou vim (alias sous CentOS) est un éditeur en mode console peu convivial certes, mais ultra puissant et qui s'utilise de la manière suivante:
<pre>
vi <nom_fichier>
</pre>

Après l’appui sur la touche entrer, le prompt disparaît pour laisser place à une série de tilde (~) qui indiquent que les lignes sont vides.

== Les modes ==

=== Permutation ===

Il y a deux modes dans vi:
* le mode saisie;
* le mode commande.

Par défaut il est en mode commande et :
* la touche ''insert'' ou ''i'' permet de passer en mode insertion ;
* la touche ''Echap'' permet de revenir au mode commande.

Lorsque l'on est en mode insertion un nouvel appui sur la touche ''insert'' permet de passer en mode ''replace'' (remplacement).

=== Répétitions ===

<pre>
n<commande>
</pre>

Par exemple ''dd'' efface une ligne et ''5dd'' efface 5 lignes

== Quitter... ==
=== ...en sauvant ===

Lorsque l'on a fini d'éditer son fichier texte, on peut le sauver en repassant en mode commande (touche ''Echap'') et en tapant:
<pre>
:wq
</pre>
ou bien
<pre>
:x
</pre>
ou encore en appuyant deux fois sur la touche ''Z'' (deux ''Z'' majuscules)

=== ...en abandonnant les modifications ===
Si l'on a fait une erreur et que l'on veut quitter sans sauver, on peut le faire en repassant en mode commande (touche ''Echap'') et en tapant:
<pre>
:q!
</pre>

= Éditer =

== Undo ==

''u'' permet de défaire une modification

== Repeat ==

''.'' permet de répéter la dernière commande d’édition

== Effacer ==

* ''x'' permet d’effacer le caractère courant

*''c'' permet d’effacer le texte et de passer en mode insertion:
**''cw'' → change du curseur jusqu’à la fin du mot
**''c$'' → change jusqu’à la fin de la ligne
**''cc'' → change la ligne courante

== Couper ==

*''d'' permet de couper grâce à l’appui de:
**''dw'' → coupe du curseur jusqu’à la fin du mot
**''dd'' → coupe la ligne complète
**''d$'' → coupe du curseur à la fin de la ligne
**''d^'' → coupe du curseur au premier caractère non vide (pas une tabulation ou un espace)
**''d0'' → coupe du curseur jusqu’au début de la ligne

== Copier ==
y permet de copier grâce à l’appui de:
*''yw'' → copie du curseur à la fin du mot (''nyw'' copie les n mots)
*''yy'' ou ''Y'' → (yank) copie la ligne courante dans le buffer (''nyy'' copie les n lignes)
*''y0'' → copie du curseur jusqu’au début de la ligne

== Coller ==
*''p'' → colle les lignes copiées en dessous du curseur
*''P'' → colle les lignes copiées au-dessus du curseur

== Suppressions ==
=== Dans tout le fichier ===
*'':g/^#/d'' → permet de supprimer les lignes commençant par ''#''
*'':g/^$/d'' → permet de supprimer les lignes vides (sans espace ni tabulation)

=== Sur la ligne ===
*''dfX'' → permet de supprimer du curseur jusqu'au caractère X
*''dtX'' → permet de supprimer du curseur jusqu'au caractère X non inclue

== Insertion ==
* ''o'' → permet d'insérer une ligne en-dessous du curseur
* ''O'' → permet d'insérer une ligne au-dessus du curseur

== Remplacements ==
=== Au niveau fichier ===
*'':s/toto/titi/g'' → permet de remplacer toutes les occurrences (grâce au ''/g'') de ''toto'' par ''titi'' sur la ligne du curseur
*'':%s/toto/titi/g'' → permet de remplacer toutes les occurrences (grâce au ''/g'') de ''toto'' par ''titi'' dans tout le document (grâce au ''%'')
*'':1,5/toto/titi/g'' → permet de remplacer toutes les occurrences (grâce au ''/g'') de ''toto'' par ''titi'' de la ligne 1 à la ligne 5 (grâce au ''1,5'')

=== Au niveau curseur ===
*''x'' → permet de supprimer le caractère sur le curseur
*''rX'' → permet de remplacer le caractère sur le curseur par X
*''R'' → permet de passer en mode remplacement

=Placements =
=== Dans la globalité du fichier ===
*''A'' → permet de placer le curseur en mode ''insert'' à la fin de la ligne courante
*'':X'' ou ''XG'' → permet de se déplacer à la ligne X du fichier
*''G'' → permet de se déplacer à la fin du fichier
*''``'' → permet de revenir à la position précédente

=== Sur la partie présente à l'écran ===
*''H'' → déplace le curseur à la première ligne visible à l'écran (''HOME'')
*''M'' → déplace le curseur au milieu de l'écran (''MIDDLE'')
*''L'' → déplace le curseur à la dernière ligne visible à l'écran (''LAST'')
*''zz'' → centre l'écran sur le curseur

=== Sur la ligne ===
*''W'' → déplace le curseur sur le mot suivant sans tenir compte de la ponctuation
*''w'' → déplace le curseur sur le mot suivant
*''B'' → déplace le curseur sur le mot précédent sans tenir compte de la ponctuation
*''b'' → déplace le curseur sur le mot précédent

*''^'' → déplace le curseur sur le premier caractère non vide (pas une tabulation ou un espace)
*''0'' → déplace le curseur au début de la ligne
*''$'' → déplace le curseur à la fin de la ligne

== Recherche ==
*''/coucou'' → permet de placer le curseur sur la prochaine occurrence de ''coucou''
* ''n'' → permet de passer à l'occurence suivante (''next'')

*''fX'' permet de recherche le caractère X en avant en appuyant sur '';''
*''FX'' permet de recherche le caractère X en arrière en appuyant sur '';''

=Astuces=
== Exécution ==
*''!'' → permet d’exécuter une commande depuis vi, cela démarrera un Shell interactif.
*'':sh'' → permet de passer l’éditeur de texte en arrière plan pour avoir un shell et ''ctrl+d'' permet de le reprendre

== Récupération ==
Si le système crash, il est possible de récupérer les changements grâce à l'option ''-r'' (''recovery'') de ''vi'' :
<pre>
# vi -r <mon_fichier>
</pre>

Systemctl

2025-12-29T04:29:37Z

Jc.forton : /* Maintenant, que faire ? */

= Introduction =
== Déni, Colère, Expression, Dépression, Acceptation ==
Nous étions habitués aux commandes ''service'', ''chkconfig'' ou encore ''init'' mais maintenant c'est de l'histoire ancienne puisque SysVInit à été remplacé par SystemD, le nouveau gestionnaire de démarrage écrit par RedHat.

On peut se demander pourquoi on change un système qui fonctionne ?

La raison est simple : SysVInit est lent, mal architecturé, possède des faiblesses. C'en était trop pour certain et c'est pourquoi, d'une architecture modulaire (chacun sa tâche), nous sommes passé à une architecture centralisée (une seule commande). Ce nouveau ''moteur'' est écrit en ''C'' et permet un démarrage parallélisé des processus plutôt qu'en série.
Les développeur d'Ubuntu avaient commencé le travail en écrivant ''UStart'' mais n'étaient pas allé jusqu'au bout des choses !

Ci-dessous un dessin expliquant comment se déroule le démarrage du système :
[[Fichier:Comparing services start.png|centré|500px]]

== Explication de texte ==
On voit clairement le gain de temps au démarrage du système ! Une question vient à l'esprit, comment est-ce possible ?<br>
La réponse se trouve dans le type de socket utilisées pour la communication entres les services : on est passé de socket ''AF_INET'', orienté réseaux, à des socket ''AF_UNIX'', orientée système.

Le premier type de socket, ''AF_INET'', permet des connexions réseau entre les services, surtout utilisée dans les systèmes distribués, plus vraiment d'actualité sur un système centralisé.<br>
Pour qu'une communication réseau fonctionne, il faut attendre que le service que l'on veut contacté soit démarré et en écoute sur le réseau... ce qui prend du temps !

Les sockets ''AF_UNIX'' sont des fichiers sur le disque !<br>
Elles ne nécessitent pas la présence du service cible pour démarrer et sont donc créées par le système d'exploitation au démarrage. Les services démarrent en parallèle et se ''branchent'' à la socket, c'est à dire ouvre le fichier pour en lire le contenu, quand ils sont prêt.

Ainsi, le démarrage des services est accéléré au détriment de la possibilité de les faire tourner sur une machine distante... on va s'en remettre :)

= Maintenant, que faire ? =
Ci-dessous un tableau qui fait le lien entre les anciennes et les nouvelles commandes :
{|class="wikitable" width="85%"
! SysVInit!! SystemD !! Description
|-
||service $daemon start
||systemctl start $daemon.service
||Permet de démarrer $daemon
|-
||service $daemon stop
||systemctl stop daemon.service
||Permet de stopper $daemon
|-
||service $daemon restart
||systemctl restart $daemon.service
||Permet de redémarrer $daemon
|-
||service $daemon reload
||systemctl reload $daemon.service
||Permet de recharger la configuration de $daemon
|-
|align="center"|X
||systemctl reload-or-restart $daemon
||Permet de recharger ou redémarrer $daemon
|-
||service $daemon status
||systemctl status $daemon
||Affiche des informations sur le service $daemon
|-
||chkconfig $daemon on
||systemctl enable $daemon.service
||Permet d'enregistrer $daemon au démarrage du système
|-
||chkconfig $daemon off
||systemctl disable $daemon.service
||Permet d'effacer $daemon du démarrage du système
|-
||chkconfig $daemon
||systemctl is-enabled $daemon.service
||Permet de voir si $daemon est actif au démarrage du système
|-
||chkconfig $daemon --list
||systemctl list-units --type=service --all
||Permet de voir la liste des services et s'ils sont actifs ou non au démarrage du système
|-
|align="center"|X
||systemctl is-failed $daemon.service
||Retourne la valeur ''active'' si le service fonctionne sinon ''failed''
|-
|align="center"|X
||systemctl list-units [--all] [--state=inactive] [--type=service]
||Liste toutes les ''unités'' gérées par ''systemctl''
|-
|align="center"|X
||systemctl show --property MainPID --value $daemon.service
||Affiche le PID de $daemon
|}
Il est possible de ne pas ajouter le ''.service'', ''systemctl'' comprendra très bien qu'il s'agit d'un service !

Nous allons maintenant passer en revue les unités que nous pouvons manipuler avec systemctl !

= Gestion des unités =
== État des unités ==
''systemctl'' peut afficher des informations sur les unités :
<pre>
# systemctl list-units
</pre>
Et on peut appliquer des filtre sur cette commande :
* --type : pour spécifier le type d'unité
** mount : les points de montage
** service : les démons
** target : les runlevel ou événements
** scope : les sessions actives
** device : les périphériques
* --state
** loaded : fichier de configuration lu par systemD
** active : l'unité est active
** inactive : l'unité des inactive
* --all : toutes les unités
Par exemple, pour lister les points de montage actif :
<pre>
# systemctl list-units --type=mount --state=active
</pre>
== A distance ==
Toutes les commandes qui figure ici peuvent être exécutées à distance en ajoutant le paramètre ''-H @ip_machine''.

Par exemple, pour vérifier le status du démon ''httpd'' sur l'hôte 192.168.1.1 :
<pre>
# systemctl -H 127.0.0.1 status httpd
</pre>
== Configuration des unités ==
{|class="wikitable" width="85%"
|-
||On peut afficher les fichiers de configuration des unités
||
<pre>
# systemctl list-unit-files
</pre>
Cette commande affiche tous les fichiers, même ceux des unités qui ne sont pas actuellement chargées !
|-
||Il est possible de voir la configuration d'une unité
||
<pre>
# systemctl cat sshd.service
</pre>
|-
||Il est possible d'éditer la configuration d'une unité en utilisant ''edit''. Cela va créer un répertoire portant le nom de l'unité et se terminant par un ''.d''. Par exemple pour Apache, cela créer un répertoire ''/etc/systemd/system/httpd.service.d''. Les informations présentes dans ce fichier vont venir surcharger les informations déjà présentes dans le fichier original. Pour modifier directement la configuration original, il faut utiliser l'option ''--full''.

Pour effacer une configuration additionnelle (surcharge), il suffit de supprimer le répertoire en ''.d''.

Une fois les modifications faite, il ne faut pas oublier de recharger systemD !
||
<pre>
# systemctl edit sshd.service
</pre>
<pre>
# systemctl edit sshd.service --full
</pre>
<pre>
# systemctl daemon-reload
</pre>
|-
||On peut également voir les dépendances d'une unité
||
<pre>
# systemctl list-dependencies sshd.service
</pre>
|-
||On peut également voir l'inverse, c'est à dire quand l'unité est requise. On voit que le service sshd démarre en mode console (multi-user.target) et en mode graphique (graphical.target). Nous aurions, au temps de SysVInit, parlé des [[Gestionnaire_de_démarrage#runlevel.2C_kesako_.3F |runlevel]] 3 et 5.
||
<pre>
# systemctl list-dependencies --reverse sshd.service
sshd.service
● └─multi-user.target
● └─graphical.target
</pre>
|-
|| On peut demander les propriétés d'une unité

Il est même possible de demander une propriété en particulier
||
<pre>
# systemctl show sshd.service
</pre>
<pre>
# systemctl show sshd.service -p WantedBy
WantedBy=multi-user.target
</pre>
|-
||Il est possible de masquer des unités, c'est à dire d'empêcher le démarrage manuel et automatique de l'unité. Il suffit alors de la démasquer pour pouvoir l'utiliser à nouveau
||
<pre>
# systemctl mask httpd.service
Created symlink from /etc/systemd/system/httpd.service to /dev/null.
# systemctl start httpd.service
Failed to start httpd.service: Unit is masked.
# systemctl unmask httpd.service
Removed symlink /etc/systemd/system/httpd.service.
# systemctl start httpd.service
</pre>
|}

== Les cibles ==
===Aperçu===
Les cibles reprennent le concept des [[Gestionnaire_de_démarrage#runlevel.2C_kesako_.3F|''runlevel'']] de SysVInit :
<pre>
# find / -name "runlevel*.target"
/usr/lib/systemd/system/runlevel5.target
/usr/lib/systemd/system/runlevel0.target
/usr/lib/systemd/system/runlevel6.target
/usr/lib/systemd/system/runlevel1.target
/usr/lib/systemd/system/runlevel2.target
/usr/lib/systemd/system/runlevel3.target
/usr/lib/systemd/system/runlevel4.target
</pre>

On voit qu'il y en a 6 et voici leur utilité :
{|class="wikitable" width="85%"
!Run Level!! Target (unité SystemD) !! Description
|-
||0
||runlevel0.target, poweroff.target
||Arrêt du système
|-
||1
||runlevel1.target, rescue.target
||Démarrage du système avec un shell de secours
|-
||2,3,4
||runlevel[2,3,4].target, multi-user.target
||Démarrage du système en mode console
|-
||5
||runlevel5.target, graphical.target
||Démarrage du système en mode graphique
|-
||6
||runlevel6.target, reboot.target
||Redémarrage du système
|}
On peut voir les liens symboliques qui sont fait sur les ''targets'' :
<pre>
# ls -l /usr/lib/systemd/system/*.target | grep runlevel
lrwxrwxrwx. 1 root root 15 26 déc. 20:23 /usr/lib/systemd/system/runlevel0.target -> poweroff.target
lrwxrwxrwx. 1 root root 13 26 déc. 20:23 /usr/lib/systemd/system/runlevel1.target -> rescue.target
lrwxrwxrwx. 1 root root 17 26 déc. 20:23 /usr/lib/systemd/system/runlevel2.target -> multi-user.target
lrwxrwxrwx. 1 root root 17 26 déc. 20:23 /usr/lib/systemd/system/runlevel3.target -> multi-user.target
lrwxrwxrwx. 1 root root 17 26 déc. 20:23 /usr/lib/systemd/system/runlevel4.target -> multi-user.target
lrwxrwxrwx. 1 root root 16 26 déc. 20:23 /usr/lib/systemd/system/runlevel5.target -> graphical.target
lrwxrwxrwx. 1 root root 13 26 déc. 20:23 /usr/lib/systemd/system/runlevel6.target -> reboot.target
</pre>

===Cible courante===
Pour voir la ''target'' courante ou anciennement la commande ''runlevel'' :
<pre>
# systemctl get-default
multi-user.target
# runlevel
N 3
</pre>
===Changement de cible===
Enfin, on peut changer la ''target'' courante grâce à l'option ''isolate'' :
<pre>
# systemctl isolate graphical.target
</pre>
Quand l'option ''isolate'' est utilisée, le suffixe ''.target'' n'est pas obligatoire.

Certaine target on des racourcis :
*
<pre>
# systemctl isolate poweroff.target
</pre>
équivaut à
<pre>
# poweroff
</pre>
*
<pre>
# systemctl isolate reboot.target
</pre>
équivaut à
<pre>
# reboot
</pre>
===Changer la cible par défaut===
La cible par défaut se trouve dans le répertoire ''/etc/systemd/system'' :
<pre>
# ll /etc/systemd/system/default.target
lrwxrwxrwx. 1 root root 37 26 déc. 20:29 /etc/systemd/system/default.target -> /lib/systemd/system/multi-user.target
</pre>
Il suffit de remplacer le lien symbolique pour modifier la cible par défaut !
<pre>
# ln -fs /lib/systemd/system/graphical.target /etc/systemd/system/default.target
</pre>
Ou, plus simple, on peut utiliser l'option ''set-default'' :
<pre>
# systemctl set-default graphical.target
Removed symlink /etc/systemd/system/default.target.
Created symlink from /etc/systemd/system/default.target to /usr/lib/systemd/system/graphical.target.
</pre>
Comme avec ''init'' on évitera de mettre ''poweroff.target'' et ''reboot.target'' comme cible par défaut...

== Gestion des points de montage ==
''systemctl'' est capable de gérer les points de montage et de monter automatiquement un emplacement physique dans un répertoire.
Dans cet exemple, le disque ''sdb'' à déjà été [[Gestion_des_disques#Cr.C3.A9ation_d.27une_partition |partitionné]] et [[Gestion_des_disques#Formatage|formaté]], il ne reste plus qu'à le monter. Traditionnellement nous aurions utilisé la commande [[Gestion_des_disques#mount | ''mount'']] et modifié le fichier [[Gestion_des_disques#fstab |''/etc/fstab'']] pour rendre le point de montage persistant.

Maintenant nous allons créer un fichier ''opt-sdb.mount'' dans le répertoire ''/etc/systemd/system/'' :
<pre>
[Unit]
Description=Deuxième disque

[Mount]
What=/dev/sdb1
Where=/opt/sdb
Type=ext4
Options=defaults

[Install]
WantedBy=local-fs.target
</pre>
Maintenant que le fichier de montage est crée, on peut en informer ''systemctl'' :
<pre>
# systemctl daemon-reload
</pre>
et démarrer le point de montage :
<pre>
# systemctl start opt-sdb.mount
</pre>
Rien ne nous empêche, comme pour les services, de l'enregistrer au démarrage :
<pre>
# systemctl enable opt-sdb.mount
</pre>
On peut même contrôler l'état du point de montage :
<pre>
# systemctl list-units --type=mount | grep opt-sdb
opt-sdb.mount loaded active mounted Deuxième disque
</pre>
{|style="width:800px" align="center"
|
[[Fichier:Warning manual.jpg|centré|300px]]
|valign="top"|
Le nom du fichier doit '''absolument''' correspondre à la destination du point de montage sous peine d'avoir l'erreur suivante :

''systemd[1]: sdb.mount's Where= setting doesn't match''.

Par exemple, si votre point de montage est ''/opt/sdb'' le fichier '''doit''' s'appeler ''opt-sdb.mount'' !
|}
= Journalisation =
Il est possible d'afficher les logs grâce à la commande ''journalctl''.
{|class="wikitable" width="85%"
! Description !! Commande ''journalctl''
|-
||Affichage de tous les logs
||
<pre>
# journalctl
</pre>
|-
||Affichage des logs d'un démon
||
<pre>
# journalctl -u $daemon.service
</pre>
|-
||Suivi des logs
||
<pre>
# journalctl -f
</pre>
|-
||Affichage des logs du kernel uniquement
||
<pre>
# journalctl -k
</pre>
|}

Systemctl

2025-12-29T04:27:12Z

Jc.forton : /* Explication de texte */

= Introduction =
== Déni, Colère, Expression, Dépression, Acceptation ==
Nous étions habitués aux commandes ''service'', ''chkconfig'' ou encore ''init'' mais maintenant c'est de l'histoire ancienne puisque SysVInit à été remplacé par SystemD, le nouveau gestionnaire de démarrage écrit par RedHat.

On peut se demander pourquoi on change un système qui fonctionne ?

La raison est simple : SysVInit est lent, mal architecturé, possède des faiblesses. C'en était trop pour certain et c'est pourquoi, d'une architecture modulaire (chacun sa tâche), nous sommes passé à une architecture centralisée (une seule commande). Ce nouveau ''moteur'' est écrit en ''C'' et permet un démarrage parallélisé des processus plutôt qu'en série.
Les développeur d'Ubuntu avaient commencé le travail en écrivant ''UStart'' mais n'étaient pas allé jusqu'au bout des choses !

Ci-dessous un dessin expliquant comment se déroule le démarrage du système :
[[Fichier:Comparing services start.png|centré|500px]]

== Explication de texte ==
On voit clairement le gain de temps au démarrage du système ! Une question vient à l'esprit, comment est-ce possible ?<br>
La réponse se trouve dans le type de socket utilisées pour la communication entres les services : on est passé de socket ''AF_INET'', orienté réseaux, à des socket ''AF_UNIX'', orientée système.

Le premier type de socket, ''AF_INET'', permet des connexions réseau entre les services, surtout utilisée dans les systèmes distribués, plus vraiment d'actualité sur un système centralisé.<br>
Pour qu'une communication réseau fonctionne, il faut attendre que le service que l'on veut contacté soit démarré et en écoute sur le réseau... ce qui prend du temps !

Les sockets ''AF_UNIX'' sont des fichiers sur le disque !<br>
Elles ne nécessitent pas la présence du service cible pour démarrer et sont donc créées par le système d'exploitation au démarrage. Les services démarrent en parallèle et se ''branchent'' à la socket, c'est à dire ouvre le fichier pour en lire le contenu, quand ils sont prêt.

Ainsi, le démarrage des services est accéléré au détriment de la possibilité de les faire tourner sur une machine distante... on va s'en remettre :)

= Maintenant, que faire ? =
Ci-dessous un tableau qui fait le lien entre les anciennes et les nouvelles commandes :
{|class="wikitable" width="85%"
! SysVInit!! SystemD !! Description
|-
||service $daemon start
||systemctl start $daemon.service
||Permet de démarrer $daemon
|-
||service $daemon stop
||systemctl stop daemon.service
||Permet de stopper $daemon
|-
||service $daemon restart
||systemctl restart $daemon.service
||Permet de redémarrer $daemon
|-
||service $daemon reload
||systemctl reload $daemon.service
||Permet de recharger la configuration de $daemon
|-
|align="center"|X
||systemctl reload-or-restart $daemon
||Permet de recharger ou redémarrer $daemon
|-
||service $daemon status
||systemctl status $daemon
||Affiche des informations sur le service $daemon
|-
||chkconfig $daemon on
||systemctl enable $daemon.service
||Permet d'enregistrer $daemon au démarrage du système
|-
||chkconfig $daemon off
||systemctl disable $daemon.service
||Permet d'effacer $daemon du démarrage du système
|-
||chkconfig $daemon
||systemctl is-enabled $daemon.service
||Permet de voir si $daemon est actif au démarrage du système
|-
||chkconfig $daemon --list
||systemctl list-units --type=service --all
||Permet de voir la liste des services et s'ils sont actifs ou non au démarrage du système
|-
|align="center"|X
||systemctl is-failed $daemon.service
||Retourne la valeur ''active'' si le service fonctionne sinon ''failed''
|-
|align="center"|X
||systemctl list-units [--all] [--state=inactive] [--type=service]
||Liste toutes les ''unités'' gérées par ''systemctl''
|}
Il est possible de ne pas ajouter le ''.service'', ''systemctl'' comprendra très bien qu'il s'agit d'un service !

Nous allons maintenant passer en revue les unités que nous pouvons manipuler avec systemctl !

= Gestion des unités =
== État des unités ==
''systemctl'' peut afficher des informations sur les unités :
<pre>
# systemctl list-units
</pre>
Et on peut appliquer des filtre sur cette commande :
* --type : pour spécifier le type d'unité
** mount : les points de montage
** service : les démons
** target : les runlevel ou événements
** scope : les sessions actives
** device : les périphériques
* --state
** loaded : fichier de configuration lu par systemD
** active : l'unité est active
** inactive : l'unité des inactive
* --all : toutes les unités
Par exemple, pour lister les points de montage actif :
<pre>
# systemctl list-units --type=mount --state=active
</pre>
== A distance ==
Toutes les commandes qui figure ici peuvent être exécutées à distance en ajoutant le paramètre ''-H @ip_machine''.

Par exemple, pour vérifier le status du démon ''httpd'' sur l'hôte 192.168.1.1 :
<pre>
# systemctl -H 127.0.0.1 status httpd
</pre>
== Configuration des unités ==
{|class="wikitable" width="85%"
|-
||On peut afficher les fichiers de configuration des unités
||
<pre>
# systemctl list-unit-files
</pre>
Cette commande affiche tous les fichiers, même ceux des unités qui ne sont pas actuellement chargées !
|-
||Il est possible de voir la configuration d'une unité
||
<pre>
# systemctl cat sshd.service
</pre>
|-
||Il est possible d'éditer la configuration d'une unité en utilisant ''edit''. Cela va créer un répertoire portant le nom de l'unité et se terminant par un ''.d''. Par exemple pour Apache, cela créer un répertoire ''/etc/systemd/system/httpd.service.d''. Les informations présentes dans ce fichier vont venir surcharger les informations déjà présentes dans le fichier original. Pour modifier directement la configuration original, il faut utiliser l'option ''--full''.

Pour effacer une configuration additionnelle (surcharge), il suffit de supprimer le répertoire en ''.d''.

Une fois les modifications faite, il ne faut pas oublier de recharger systemD !
||
<pre>
# systemctl edit sshd.service
</pre>
<pre>
# systemctl edit sshd.service --full
</pre>
<pre>
# systemctl daemon-reload
</pre>
|-
||On peut également voir les dépendances d'une unité
||
<pre>
# systemctl list-dependencies sshd.service
</pre>
|-
||On peut également voir l'inverse, c'est à dire quand l'unité est requise. On voit que le service sshd démarre en mode console (multi-user.target) et en mode graphique (graphical.target). Nous aurions, au temps de SysVInit, parlé des [[Gestionnaire_de_démarrage#runlevel.2C_kesako_.3F |runlevel]] 3 et 5.
||
<pre>
# systemctl list-dependencies --reverse sshd.service
sshd.service
● └─multi-user.target
● └─graphical.target
</pre>
|-
|| On peut demander les propriétés d'une unité

Il est même possible de demander une propriété en particulier
||
<pre>
# systemctl show sshd.service
</pre>
<pre>
# systemctl show sshd.service -p WantedBy
WantedBy=multi-user.target
</pre>
|-
||Il est possible de masquer des unités, c'est à dire d'empêcher le démarrage manuel et automatique de l'unité. Il suffit alors de la démasquer pour pouvoir l'utiliser à nouveau
||
<pre>
# systemctl mask httpd.service
Created symlink from /etc/systemd/system/httpd.service to /dev/null.
# systemctl start httpd.service
Failed to start httpd.service: Unit is masked.
# systemctl unmask httpd.service
Removed symlink /etc/systemd/system/httpd.service.
# systemctl start httpd.service
</pre>
|}

== Les cibles ==
===Aperçu===
Les cibles reprennent le concept des [[Gestionnaire_de_démarrage#runlevel.2C_kesako_.3F|''runlevel'']] de SysVInit :
<pre>
# find / -name "runlevel*.target"
/usr/lib/systemd/system/runlevel5.target
/usr/lib/systemd/system/runlevel0.target
/usr/lib/systemd/system/runlevel6.target
/usr/lib/systemd/system/runlevel1.target
/usr/lib/systemd/system/runlevel2.target
/usr/lib/systemd/system/runlevel3.target
/usr/lib/systemd/system/runlevel4.target
</pre>

On voit qu'il y en a 6 et voici leur utilité :
{|class="wikitable" width="85%"
!Run Level!! Target (unité SystemD) !! Description
|-
||0
||runlevel0.target, poweroff.target
||Arrêt du système
|-
||1
||runlevel1.target, rescue.target
||Démarrage du système avec un shell de secours
|-
||2,3,4
||runlevel[2,3,4].target, multi-user.target
||Démarrage du système en mode console
|-
||5
||runlevel5.target, graphical.target
||Démarrage du système en mode graphique
|-
||6
||runlevel6.target, reboot.target
||Redémarrage du système
|}
On peut voir les liens symboliques qui sont fait sur les ''targets'' :
<pre>
# ls -l /usr/lib/systemd/system/*.target | grep runlevel
lrwxrwxrwx. 1 root root 15 26 déc. 20:23 /usr/lib/systemd/system/runlevel0.target -> poweroff.target
lrwxrwxrwx. 1 root root 13 26 déc. 20:23 /usr/lib/systemd/system/runlevel1.target -> rescue.target
lrwxrwxrwx. 1 root root 17 26 déc. 20:23 /usr/lib/systemd/system/runlevel2.target -> multi-user.target
lrwxrwxrwx. 1 root root 17 26 déc. 20:23 /usr/lib/systemd/system/runlevel3.target -> multi-user.target
lrwxrwxrwx. 1 root root 17 26 déc. 20:23 /usr/lib/systemd/system/runlevel4.target -> multi-user.target
lrwxrwxrwx. 1 root root 16 26 déc. 20:23 /usr/lib/systemd/system/runlevel5.target -> graphical.target
lrwxrwxrwx. 1 root root 13 26 déc. 20:23 /usr/lib/systemd/system/runlevel6.target -> reboot.target
</pre>

===Cible courante===
Pour voir la ''target'' courante ou anciennement la commande ''runlevel'' :
<pre>
# systemctl get-default
multi-user.target
# runlevel
N 3
</pre>
===Changement de cible===
Enfin, on peut changer la ''target'' courante grâce à l'option ''isolate'' :
<pre>
# systemctl isolate graphical.target
</pre>
Quand l'option ''isolate'' est utilisée, le suffixe ''.target'' n'est pas obligatoire.

Certaine target on des racourcis :
*
<pre>
# systemctl isolate poweroff.target
</pre>
équivaut à
<pre>
# poweroff
</pre>
*
<pre>
# systemctl isolate reboot.target
</pre>
équivaut à
<pre>
# reboot
</pre>
===Changer la cible par défaut===
La cible par défaut se trouve dans le répertoire ''/etc/systemd/system'' :
<pre>
# ll /etc/systemd/system/default.target
lrwxrwxrwx. 1 root root 37 26 déc. 20:29 /etc/systemd/system/default.target -> /lib/systemd/system/multi-user.target
</pre>
Il suffit de remplacer le lien symbolique pour modifier la cible par défaut !
<pre>
# ln -fs /lib/systemd/system/graphical.target /etc/systemd/system/default.target
</pre>
Ou, plus simple, on peut utiliser l'option ''set-default'' :
<pre>
# systemctl set-default graphical.target
Removed symlink /etc/systemd/system/default.target.
Created symlink from /etc/systemd/system/default.target to /usr/lib/systemd/system/graphical.target.
</pre>
Comme avec ''init'' on évitera de mettre ''poweroff.target'' et ''reboot.target'' comme cible par défaut...

== Gestion des points de montage ==
''systemctl'' est capable de gérer les points de montage et de monter automatiquement un emplacement physique dans un répertoire.
Dans cet exemple, le disque ''sdb'' à déjà été [[Gestion_des_disques#Cr.C3.A9ation_d.27une_partition |partitionné]] et [[Gestion_des_disques#Formatage|formaté]], il ne reste plus qu'à le monter. Traditionnellement nous aurions utilisé la commande [[Gestion_des_disques#mount | ''mount'']] et modifié le fichier [[Gestion_des_disques#fstab |''/etc/fstab'']] pour rendre le point de montage persistant.

Maintenant nous allons créer un fichier ''opt-sdb.mount'' dans le répertoire ''/etc/systemd/system/'' :
<pre>
[Unit]
Description=Deuxième disque

[Mount]
What=/dev/sdb1
Where=/opt/sdb
Type=ext4
Options=defaults

[Install]
WantedBy=local-fs.target
</pre>
Maintenant que le fichier de montage est crée, on peut en informer ''systemctl'' :
<pre>
# systemctl daemon-reload
</pre>
et démarrer le point de montage :
<pre>
# systemctl start opt-sdb.mount
</pre>
Rien ne nous empêche, comme pour les services, de l'enregistrer au démarrage :
<pre>
# systemctl enable opt-sdb.mount
</pre>
On peut même contrôler l'état du point de montage :
<pre>
# systemctl list-units --type=mount | grep opt-sdb
opt-sdb.mount loaded active mounted Deuxième disque
</pre>
{|style="width:800px" align="center"
|
[[Fichier:Warning manual.jpg|centré|300px]]
|valign="top"|
Le nom du fichier doit '''absolument''' correspondre à la destination du point de montage sous peine d'avoir l'erreur suivante :

''systemd[1]: sdb.mount's Where= setting doesn't match''.

Par exemple, si votre point de montage est ''/opt/sdb'' le fichier '''doit''' s'appeler ''opt-sdb.mount'' !
|}
= Journalisation =
Il est possible d'afficher les logs grâce à la commande ''journalctl''.
{|class="wikitable" width="85%"
! Description !! Commande ''journalctl''
|-
||Affichage de tous les logs
||
<pre>
# journalctl
</pre>
|-
||Affichage des logs d'un démon
||
<pre>
# journalctl -u $daemon.service
</pre>
|-
||Suivi des logs
||
<pre>
# journalctl -f
</pre>
|-
||Affichage des logs du kernel uniquement
||
<pre>
# journalctl -k
</pre>
|}

Systemctl service

2025-12-24T04:18:15Z

Jc.forton : /* Utilisation */

= Introduction =
Dans cet article nous allons créer un service, très simplement, avec '''Systemctl'''.

Pour cela, nous allons d'abord utiliser PHP pour ''fabriquer'' notre service, puis nous allons créer un fichier service pour automatiser son démarrage !

= Le programme =
== Création ==
Le service que nous allons faire va simplement écrire le [https://fr.wikipedia.org/wiki/Heure_Unix temps unix] dans un fichier de journalisation pour que, une fois démarré et passé en tâche de fond, nous puissions nous assurer qu'il tourne toujours !

Dans le dossier ''/opt/php-service'' nous allons créer le fichier clock.php :

<syntaxhighlight lang="php">
<?php

define("LOG_FILE", "/tmp/clock.log");

while(1){
file_put_contents(LOG_FILE, time()."\n", FILE_APPEND);
sleep(2);
}
</syntaxhighlight>
Le but de ce programme est d'écrire, toutes les 2 secondes, la date dans le fichier ''/tmp/clock.log''.

== Pas un démon ==
On peut remarquer que ce n'est même pas un démon et qu'il ne rend pas la main lorsque nous allons l’exécuter.
D’ailleurs il n'utilise aucune des fonctions décrites dans [[Php daemon|cet article]] car nous allons demander à ''SystemD'' de s'occuper de tout.

== Test sans SystemD ==
Nous allons tester ce programme :
<source lang=bash>
# php clock.php
</source>
Puis dans un autre terminal, nous pouvons faire :
<source lang=bash>
# tail -f /tmp/clock.php
1715971610
1715971612
1715971614
1715971616
...
</source>

== Préparation pour devenir un service ==
=== shebang===
Nous pourrions utiliser PHP à chaque fois que l'on veut invoquer notre service mais on va plutôt ajouter le [https://fr.wikipedia.org/wiki/Shebang shebang] à la première ligne de notre fichier ''clock.php'' :
<source lang=bash>
#!/usr/bin/php
</source>
Le dossier de l'exécutable de PHP peut changer en fonction des distributions Linux et, si vous avez un doute, n'hésitez pas à utiliser la commande ''whereis'' :
<source lang=bash>
# whereis php
php: /usr/bin/php /usr/lib64/php /usr/share/php /usr/share/man/man1/php.1.gz
</source>

=== Droit d'exécution ===
Maintenant que nous avons ajouté le shebang, ''bash'' va savoir comment exécuter notre programme et il ne nous reste plus qu'a modifier ses droits pour le rendre exécutable :
<source lang=bash>
# chmod +x clock.php
</source>
On peut maintenant exécuter notre programme ainsi :
<source lang=bash>
# ./clock.php
</source>

=== Ajout dans le path ===
Pour reproduire le même comportement que les autres programmes, il est possible d'ajouter notre programme au path pour pouvoir l'appeler grâce à l’autocomplétion. Pour cela, nous allons ajouter un lien symbolique dans le répertoire ''/usr/bin/'' :
<source lang=bash>
# ln -fs /opt/php-service/clock.php /usr/bin/clock-php
</source>
Le programme clock existant déjà, on rajoute ''-php'' à la fin pour ne pas écraser le programme original :). Si votre programme possède un nom unique sur le système, vous n'avez pas besoin de faire ça !

Maintenant de n'importe où on peut utiliser l'autocomplétion pour appeler notre programme :
<source lang=bash>
# clock-php
</source>
Et même demander à whereis où il se trouve :
<source lang=bash>
# whereis clock-php
clock-php: /usr/bin/clock-php
</source>
Nice !

=== Création d'un utilisateur et un groupe ===
Pour des raisons de sécurité, il est préférable que le programme ne tourne pas en tant que ''root'' mais en tant que simple utilisateur.

Puis un utilisateur un peu spécial, qui ne peut pas se connecter et qui n'a pas de répertoire ''home'' :
<source lang=bash>
# useradd -r -s /sbin/nologin clock-php
</source>
Notez que l'option ''-r'' créer un utilisateur système, c'est à dire qui n'a pas de répertoire ''home'' mais, cela s'occupe également de la création du groupe associé (clock-php) et ajoute l'utilisateur dans ce groupe !

= Fichier de service systemd =
== Création ==
Maintenant que notre programme ressemble à un ''vrai'' programme, nous pouvons créer un fichier ''.service'' pour demander à systemd de s'en occuper.

Nous allons créer le fichier ''clock-php.service'' dans le même répertoire que le programme pour des raison de simplicité :
<pre>
[Unit]
Description=clock-php daemon service
After=network-online.target

[Service]
Type=simple

User=clock-php
Group=clock-php
UMask=007

ExecStart=/usr/bin/clock-php

Restart=on-failure

TimeoutStopSec=300

[Install]
WantedBy=multi-user.target
</pre>

== Explications ==

{|class="wikitable" width="85%"
|-
|| Section || Directive || Description
|-
|| Unit || Description || la description qui apparait avec la commande ''systemctl status clock-php''
|-
|| Unit || After || Nom de la cible après laquelle le service doit être démarré (et avant laquelle il doit être stoppé). Si vous voulez la liste exhaustive de toutes les cibles : ''systemctl list-units --type target''
|-
|| Service || Type || Type de notre service, peut notamment prendre les valeurs suivante :
* simple → systemd considère que le service démarre de suite (notre cas de figure)
* forking → systemd attend que le processus soit détaché du contexte d'exécution courant et que le processus père ait rendu la main (soit terminé). Utile si on avait fait un fork comme mentionné dans [[Php daemon | cet article]]. Dans ce cas de figure il est intéressant de préciser le fichier de pid avec la directive '''PIDFile='''
* oneshot → utile pour des script qui font un travail et rendent la main. Vous pouvez maintenir l'état du service avec la directive '''RemainAfterExit=yes''' pour que systemd considère le service comme actif après l'exécution du script.
* ...
|-
|| Service || User || l'utilisateur utilisé pour l'abaissement de privilège
|-
|| Service || Group || le groupe utilisé pour l'abaissement de privilège
|-
|| Service || Umask || le masque utilisé pour la création de fichiers
|-
|| Service || ExecStart || Le chemin de l'exécutable
|-
|| Service || Restart || précise quand redémarrer le service :
* on-failure → quand le service échoue (code retour différent de zéro)
* always → dès que le service se termine indépendamment du code retour. C'est utile si vous n'avez pas de boucle qui retient le programme (while ou autre)
|-
|| Service || TimeoutStopSec || temps laissé au programme pour s’arrêter avant de le tuer (SIGKILL)
|-
|| Install || WantedBy || le niveau de démarrage du système dans lequel appelé le programme. Je vous laisse voir cette article à propos des [[Systemctl#Aper.C3.A7u | niveau de démarrage]] mais pour faire simple :
* multi-user.target → ligne de commande
* graphical.target → interface graphique
|}

== Lien symbolique et activation ==
Maintenant que le fichier existe, nous allons créer un lien symbolique dans le répertoire ''/etc/systemd/system'':
<source lang=bash>
# systemctl link /opt/php-service/clock-php.service
</source>
Le service devrait être visible:
<source lang=bash>
# systemctl status clock-php.service
</source>

== Utilisation ==
On peut maintenant utiliser le service avec les commandes traditionnelle :
* start
* stop
* status
* ...
Vous avez tous les détails sur systemd dans [[Systemctl | cet article]] mais pour résumer :
*On démarre donc le service avec :
<source lang=bash>
# systemctl start clock-php
</source>
*On vérifie le status du service avec :
<source lang=bash>
# systemctl status clock-php
● clock-php.service - clock-php daemon service
Loaded: loaded (/etc/systemd/system/clock-php.service; alias)
Active: active (running) since Sat 2024-05-18 01:07:46 CEST; 1s ago
Main PID: 1487 (clock-php)
Tasks: 1 (limit: 5904)
Memory: 8.6M
CPU: 27ms
CGroup: /system.slice/clock-php.service
└─1487 /usr/bin/php /usr/bin/clock-php

May 18 01:07:46 prog systemd[1]: Started clock-php daemon service.
</source>
*On peut même enregistrer le service au démarrage :
<source lang=bash>
# systemctl enable clock-php
Created symlink /etc/systemd/system/multi-user.target.wants/clock-php.service → /opt/php-service/clock-php.service.
</source>

Systemctl service

2025-12-24T04:17:30Z

Jc.forton : /* Lien symbolique et activation */

= Introduction =
Dans cet article nous allons créer un service, très simplement, avec '''Systemctl'''.

Pour cela, nous allons d'abord utiliser PHP pour ''fabriquer'' notre service, puis nous allons créer un fichier service pour automatiser son démarrage !

= Le programme =
== Création ==
Le service que nous allons faire va simplement écrire le [https://fr.wikipedia.org/wiki/Heure_Unix temps unix] dans un fichier de journalisation pour que, une fois démarré et passé en tâche de fond, nous puissions nous assurer qu'il tourne toujours !

Dans le dossier ''/opt/php-service'' nous allons créer le fichier clock.php :

<syntaxhighlight lang="php">
<?php

define("LOG_FILE", "/tmp/clock.log");

while(1){
file_put_contents(LOG_FILE, time()."\n", FILE_APPEND);
sleep(2);
}
</syntaxhighlight>
Le but de ce programme est d'écrire, toutes les 2 secondes, la date dans le fichier ''/tmp/clock.log''.

== Pas un démon ==
On peut remarquer que ce n'est même pas un démon et qu'il ne rend pas la main lorsque nous allons l’exécuter.
D’ailleurs il n'utilise aucune des fonctions décrites dans [[Php daemon|cet article]] car nous allons demander à ''SystemD'' de s'occuper de tout.

== Test sans SystemD ==
Nous allons tester ce programme :
<source lang=bash>
# php clock.php
</source>
Puis dans un autre terminal, nous pouvons faire :
<source lang=bash>
# tail -f /tmp/clock.php
1715971610
1715971612
1715971614
1715971616
...
</source>

== Préparation pour devenir un service ==
=== shebang===
Nous pourrions utiliser PHP à chaque fois que l'on veut invoquer notre service mais on va plutôt ajouter le [https://fr.wikipedia.org/wiki/Shebang shebang] à la première ligne de notre fichier ''clock.php'' :
<source lang=bash>
#!/usr/bin/php
</source>
Le dossier de l'exécutable de PHP peut changer en fonction des distributions Linux et, si vous avez un doute, n'hésitez pas à utiliser la commande ''whereis'' :
<source lang=bash>
# whereis php
php: /usr/bin/php /usr/lib64/php /usr/share/php /usr/share/man/man1/php.1.gz
</source>

=== Droit d'exécution ===
Maintenant que nous avons ajouté le shebang, ''bash'' va savoir comment exécuter notre programme et il ne nous reste plus qu'a modifier ses droits pour le rendre exécutable :
<source lang=bash>
# chmod +x clock.php
</source>
On peut maintenant exécuter notre programme ainsi :
<source lang=bash>
# ./clock.php
</source>

=== Ajout dans le path ===
Pour reproduire le même comportement que les autres programmes, il est possible d'ajouter notre programme au path pour pouvoir l'appeler grâce à l’autocomplétion. Pour cela, nous allons ajouter un lien symbolique dans le répertoire ''/usr/bin/'' :
<source lang=bash>
# ln -fs /opt/php-service/clock.php /usr/bin/clock-php
</source>
Le programme clock existant déjà, on rajoute ''-php'' à la fin pour ne pas écraser le programme original :). Si votre programme possède un nom unique sur le système, vous n'avez pas besoin de faire ça !

Maintenant de n'importe où on peut utiliser l'autocomplétion pour appeler notre programme :
<source lang=bash>
# clock-php
</source>
Et même demander à whereis où il se trouve :
<source lang=bash>
# whereis clock-php
clock-php: /usr/bin/clock-php
</source>
Nice !

=== Création d'un utilisateur et un groupe ===
Pour des raisons de sécurité, il est préférable que le programme ne tourne pas en tant que ''root'' mais en tant que simple utilisateur.

Puis un utilisateur un peu spécial, qui ne peut pas se connecter et qui n'a pas de répertoire ''home'' :
<source lang=bash>
# useradd -r -s /sbin/nologin clock-php
</source>
Notez que l'option ''-r'' créer un utilisateur système, c'est à dire qui n'a pas de répertoire ''home'' mais, cela s'occupe également de la création du groupe associé (clock-php) et ajoute l'utilisateur dans ce groupe !

= Fichier de service systemd =
== Création ==
Maintenant que notre programme ressemble à un ''vrai'' programme, nous pouvons créer un fichier ''.service'' pour demander à systemd de s'en occuper.

Nous allons créer le fichier ''clock-php.service'' dans le même répertoire que le programme pour des raison de simplicité :
<pre>
[Unit]
Description=clock-php daemon service
After=network-online.target

[Service]
Type=simple

User=clock-php
Group=clock-php
UMask=007

ExecStart=/usr/bin/clock-php

Restart=on-failure

TimeoutStopSec=300

[Install]
WantedBy=multi-user.target
</pre>

== Explications ==

{|class="wikitable" width="85%"
|-
|| Section || Directive || Description
|-
|| Unit || Description || la description qui apparait avec la commande ''systemctl status clock-php''
|-
|| Unit || After || Nom de la cible après laquelle le service doit être démarré (et avant laquelle il doit être stoppé). Si vous voulez la liste exhaustive de toutes les cibles : ''systemctl list-units --type target''
|-
|| Service || Type || Type de notre service, peut notamment prendre les valeurs suivante :
* simple → systemd considère que le service démarre de suite (notre cas de figure)
* forking → systemd attend que le processus soit détaché du contexte d'exécution courant et que le processus père ait rendu la main (soit terminé). Utile si on avait fait un fork comme mentionné dans [[Php daemon | cet article]]. Dans ce cas de figure il est intéressant de préciser le fichier de pid avec la directive '''PIDFile='''
* oneshot → utile pour des script qui font un travail et rendent la main. Vous pouvez maintenir l'état du service avec la directive '''RemainAfterExit=yes''' pour que systemd considère le service comme actif après l'exécution du script.
* ...
|-
|| Service || User || l'utilisateur utilisé pour l'abaissement de privilège
|-
|| Service || Group || le groupe utilisé pour l'abaissement de privilège
|-
|| Service || Umask || le masque utilisé pour la création de fichiers
|-
|| Service || ExecStart || Le chemin de l'exécutable
|-
|| Service || Restart || précise quand redémarrer le service :
* on-failure → quand le service échoue (code retour différent de zéro)
* always → dès que le service se termine indépendamment du code retour. C'est utile si vous n'avez pas de boucle qui retient le programme (while ou autre)
|-
|| Service || TimeoutStopSec || temps laissé au programme pour s’arrêter avant de le tuer (SIGKILL)
|-
|| Install || WantedBy || le niveau de démarrage du système dans lequel appelé le programme. Je vous laisse voir cette article à propos des [[Systemctl#Aper.C3.A7u | niveau de démarrage]] mais pour faire simple :
* multi-user.target → ligne de commande
* graphical.target → interface graphique
|}

== Lien symbolique et activation ==
Maintenant que le fichier existe, nous allons créer un lien symbolique dans le répertoire ''/etc/systemd/system'':
<source lang=bash>
# systemctl link /opt/php-service/clock-php.service
</source>
Le service devrait être visible:
<source lang=bash>
# systemctl status clock-php.service
</source>

== Utilisation ==
On peut maintenant utiliser le service avec les commandes traditionnelle :
* start
* stop
* status
* ...
Vous avez tous les détails sur systemd dans [[Systemctl | cet article]] mais pour résumer :
*On démarre donc le service avec :
<pre>
# systemctl start clock-php
</pre>
*On vérifie le status du service avec :
<pre>
# systemctl status clock-php
● clock-php.service - clock-php daemon service
Loaded: loaded (/etc/systemd/system/clock-php.service; alias)
Active: active (running) since Sat 2024-05-18 01:07:46 CEST; 1s ago
Main PID: 1487 (clock-php)
Tasks: 1 (limit: 5904)
Memory: 8.6M
CPU: 27ms
CGroup: /system.slice/clock-php.service
└─1487 /usr/bin/php /usr/bin/clock-php

May 18 01:07:46 prog systemd[1]: Started clock-php daemon service.
</pre>
*On peut même enregistrer le service au démarrage :
<pre>
# systemctl enable clock-php
Created symlink /etc/systemd/system/multi-user.target.wants/clock-php.service → /opt/php-service/clock-php.service.
</pre>

Systemctl service

2025-12-24T04:17:04Z

Jc.forton : /* Création d'un utilisateur et un groupe */

= Introduction =
Dans cet article nous allons créer un service, très simplement, avec '''Systemctl'''.

Pour cela, nous allons d'abord utiliser PHP pour ''fabriquer'' notre service, puis nous allons créer un fichier service pour automatiser son démarrage !

= Le programme =
== Création ==
Le service que nous allons faire va simplement écrire le [https://fr.wikipedia.org/wiki/Heure_Unix temps unix] dans un fichier de journalisation pour que, une fois démarré et passé en tâche de fond, nous puissions nous assurer qu'il tourne toujours !

Dans le dossier ''/opt/php-service'' nous allons créer le fichier clock.php :

<syntaxhighlight lang="php">
<?php

define("LOG_FILE", "/tmp/clock.log");

while(1){
file_put_contents(LOG_FILE, time()."\n", FILE_APPEND);
sleep(2);
}
</syntaxhighlight>
Le but de ce programme est d'écrire, toutes les 2 secondes, la date dans le fichier ''/tmp/clock.log''.

== Pas un démon ==
On peut remarquer que ce n'est même pas un démon et qu'il ne rend pas la main lorsque nous allons l’exécuter.
D’ailleurs il n'utilise aucune des fonctions décrites dans [[Php daemon|cet article]] car nous allons demander à ''SystemD'' de s'occuper de tout.

== Test sans SystemD ==
Nous allons tester ce programme :
<source lang=bash>
# php clock.php
</source>
Puis dans un autre terminal, nous pouvons faire :
<source lang=bash>
# tail -f /tmp/clock.php
1715971610
1715971612
1715971614
1715971616
...
</source>

== Préparation pour devenir un service ==
=== shebang===
Nous pourrions utiliser PHP à chaque fois que l'on veut invoquer notre service mais on va plutôt ajouter le [https://fr.wikipedia.org/wiki/Shebang shebang] à la première ligne de notre fichier ''clock.php'' :
<source lang=bash>
#!/usr/bin/php
</source>
Le dossier de l'exécutable de PHP peut changer en fonction des distributions Linux et, si vous avez un doute, n'hésitez pas à utiliser la commande ''whereis'' :
<source lang=bash>
# whereis php
php: /usr/bin/php /usr/lib64/php /usr/share/php /usr/share/man/man1/php.1.gz
</source>

=== Droit d'exécution ===
Maintenant que nous avons ajouté le shebang, ''bash'' va savoir comment exécuter notre programme et il ne nous reste plus qu'a modifier ses droits pour le rendre exécutable :
<source lang=bash>
# chmod +x clock.php
</source>
On peut maintenant exécuter notre programme ainsi :
<source lang=bash>
# ./clock.php
</source>

=== Ajout dans le path ===
Pour reproduire le même comportement que les autres programmes, il est possible d'ajouter notre programme au path pour pouvoir l'appeler grâce à l’autocomplétion. Pour cela, nous allons ajouter un lien symbolique dans le répertoire ''/usr/bin/'' :
<source lang=bash>
# ln -fs /opt/php-service/clock.php /usr/bin/clock-php
</source>
Le programme clock existant déjà, on rajoute ''-php'' à la fin pour ne pas écraser le programme original :). Si votre programme possède un nom unique sur le système, vous n'avez pas besoin de faire ça !

Maintenant de n'importe où on peut utiliser l'autocomplétion pour appeler notre programme :
<source lang=bash>
# clock-php
</source>
Et même demander à whereis où il se trouve :
<source lang=bash>
# whereis clock-php
clock-php: /usr/bin/clock-php
</source>
Nice !

=== Création d'un utilisateur et un groupe ===
Pour des raisons de sécurité, il est préférable que le programme ne tourne pas en tant que ''root'' mais en tant que simple utilisateur.

Puis un utilisateur un peu spécial, qui ne peut pas se connecter et qui n'a pas de répertoire ''home'' :
<source lang=bash>
# useradd -r -s /sbin/nologin clock-php
</source>
Notez que l'option ''-r'' créer un utilisateur système, c'est à dire qui n'a pas de répertoire ''home'' mais, cela s'occupe également de la création du groupe associé (clock-php) et ajoute l'utilisateur dans ce groupe !

= Fichier de service systemd =
== Création ==
Maintenant que notre programme ressemble à un ''vrai'' programme, nous pouvons créer un fichier ''.service'' pour demander à systemd de s'en occuper.

Nous allons créer le fichier ''clock-php.service'' dans le même répertoire que le programme pour des raison de simplicité :
<pre>
[Unit]
Description=clock-php daemon service
After=network-online.target

[Service]
Type=simple

User=clock-php
Group=clock-php
UMask=007

ExecStart=/usr/bin/clock-php

Restart=on-failure

TimeoutStopSec=300

[Install]
WantedBy=multi-user.target
</pre>

== Explications ==

{|class="wikitable" width="85%"
|-
|| Section || Directive || Description
|-
|| Unit || Description || la description qui apparait avec la commande ''systemctl status clock-php''
|-
|| Unit || After || Nom de la cible après laquelle le service doit être démarré (et avant laquelle il doit être stoppé). Si vous voulez la liste exhaustive de toutes les cibles : ''systemctl list-units --type target''
|-
|| Service || Type || Type de notre service, peut notamment prendre les valeurs suivante :
* simple → systemd considère que le service démarre de suite (notre cas de figure)
* forking → systemd attend que le processus soit détaché du contexte d'exécution courant et que le processus père ait rendu la main (soit terminé). Utile si on avait fait un fork comme mentionné dans [[Php daemon | cet article]]. Dans ce cas de figure il est intéressant de préciser le fichier de pid avec la directive '''PIDFile='''
* oneshot → utile pour des script qui font un travail et rendent la main. Vous pouvez maintenir l'état du service avec la directive '''RemainAfterExit=yes''' pour que systemd considère le service comme actif après l'exécution du script.
* ...
|-
|| Service || User || l'utilisateur utilisé pour l'abaissement de privilège
|-
|| Service || Group || le groupe utilisé pour l'abaissement de privilège
|-
|| Service || Umask || le masque utilisé pour la création de fichiers
|-
|| Service || ExecStart || Le chemin de l'exécutable
|-
|| Service || Restart || précise quand redémarrer le service :
* on-failure → quand le service échoue (code retour différent de zéro)
* always → dès que le service se termine indépendamment du code retour. C'est utile si vous n'avez pas de boucle qui retient le programme (while ou autre)
|-
|| Service || TimeoutStopSec || temps laissé au programme pour s’arrêter avant de le tuer (SIGKILL)
|-
|| Install || WantedBy || le niveau de démarrage du système dans lequel appelé le programme. Je vous laisse voir cette article à propos des [[Systemctl#Aper.C3.A7u | niveau de démarrage]] mais pour faire simple :
* multi-user.target → ligne de commande
* graphical.target → interface graphique
|}

== Lien symbolique et activation ==
Maintenant que le fichier existe, nous allons créer un lien symbolique dans le répertoire ''/etc/systemd/system'':
<pre>
# systemctl link /opt/php-service/clock-php.service
</pre>
Le service devrait être visible:
<pre>
# systemctl status clock-php.service
</pre>

== Utilisation ==
On peut maintenant utiliser le service avec les commandes traditionnelle :
* start
* stop
* status
* ...
Vous avez tous les détails sur systemd dans [[Systemctl | cet article]] mais pour résumer :
*On démarre donc le service avec :
<pre>
# systemctl start clock-php
</pre>
*On vérifie le status du service avec :
<pre>
# systemctl status clock-php
● clock-php.service - clock-php daemon service
Loaded: loaded (/etc/systemd/system/clock-php.service; alias)
Active: active (running) since Sat 2024-05-18 01:07:46 CEST; 1s ago
Main PID: 1487 (clock-php)
Tasks: 1 (limit: 5904)
Memory: 8.6M
CPU: 27ms
CGroup: /system.slice/clock-php.service
└─1487 /usr/bin/php /usr/bin/clock-php

May 18 01:07:46 prog systemd[1]: Started clock-php daemon service.
</pre>
*On peut même enregistrer le service au démarrage :
<pre>
# systemctl enable clock-php
Created symlink /etc/systemd/system/multi-user.target.wants/clock-php.service → /opt/php-service/clock-php.service.
</pre>

Systemctl service

2025-12-24T04:16:42Z

Jc.forton : /* Ajout dans le path */

= Introduction =
Dans cet article nous allons créer un service, très simplement, avec '''Systemctl'''.

Pour cela, nous allons d'abord utiliser PHP pour ''fabriquer'' notre service, puis nous allons créer un fichier service pour automatiser son démarrage !

= Le programme =
== Création ==
Le service que nous allons faire va simplement écrire le [https://fr.wikipedia.org/wiki/Heure_Unix temps unix] dans un fichier de journalisation pour que, une fois démarré et passé en tâche de fond, nous puissions nous assurer qu'il tourne toujours !

Dans le dossier ''/opt/php-service'' nous allons créer le fichier clock.php :

<syntaxhighlight lang="php">
<?php

define("LOG_FILE", "/tmp/clock.log");

while(1){
file_put_contents(LOG_FILE, time()."\n", FILE_APPEND);
sleep(2);
}
</syntaxhighlight>
Le but de ce programme est d'écrire, toutes les 2 secondes, la date dans le fichier ''/tmp/clock.log''.

== Pas un démon ==
On peut remarquer que ce n'est même pas un démon et qu'il ne rend pas la main lorsque nous allons l’exécuter.
D’ailleurs il n'utilise aucune des fonctions décrites dans [[Php daemon|cet article]] car nous allons demander à ''SystemD'' de s'occuper de tout.

== Test sans SystemD ==
Nous allons tester ce programme :
<source lang=bash>
# php clock.php
</source>
Puis dans un autre terminal, nous pouvons faire :
<source lang=bash>
# tail -f /tmp/clock.php
1715971610
1715971612
1715971614
1715971616
...
</source>

== Préparation pour devenir un service ==
=== shebang===
Nous pourrions utiliser PHP à chaque fois que l'on veut invoquer notre service mais on va plutôt ajouter le [https://fr.wikipedia.org/wiki/Shebang shebang] à la première ligne de notre fichier ''clock.php'' :
<source lang=bash>
#!/usr/bin/php
</source>
Le dossier de l'exécutable de PHP peut changer en fonction des distributions Linux et, si vous avez un doute, n'hésitez pas à utiliser la commande ''whereis'' :
<source lang=bash>
# whereis php
php: /usr/bin/php /usr/lib64/php /usr/share/php /usr/share/man/man1/php.1.gz
</source>

=== Droit d'exécution ===
Maintenant que nous avons ajouté le shebang, ''bash'' va savoir comment exécuter notre programme et il ne nous reste plus qu'a modifier ses droits pour le rendre exécutable :
<source lang=bash>
# chmod +x clock.php
</source>
On peut maintenant exécuter notre programme ainsi :
<source lang=bash>
# ./clock.php
</source>

=== Ajout dans le path ===
Pour reproduire le même comportement que les autres programmes, il est possible d'ajouter notre programme au path pour pouvoir l'appeler grâce à l’autocomplétion. Pour cela, nous allons ajouter un lien symbolique dans le répertoire ''/usr/bin/'' :
<source lang=bash>
# ln -fs /opt/php-service/clock.php /usr/bin/clock-php
</source>
Le programme clock existant déjà, on rajoute ''-php'' à la fin pour ne pas écraser le programme original :). Si votre programme possède un nom unique sur le système, vous n'avez pas besoin de faire ça !

Maintenant de n'importe où on peut utiliser l'autocomplétion pour appeler notre programme :
<source lang=bash>
# clock-php
</source>
Et même demander à whereis où il se trouve :
<source lang=bash>
# whereis clock-php
clock-php: /usr/bin/clock-php
</source>
Nice !

=== Création d'un utilisateur et un groupe ===
Pour des raisons de sécurité, il est préférable que le programme ne tourne pas en tant que ''root'' mais en tant que simple utilisateur.

Puis un utilisateur un peu spécial, qui ne peut pas se connecter et qui n'a pas de répertoire ''home'' :
<pre>
# useradd -r -s /sbin/nologin clock-php
</pre>
Notez que l'option ''-r'' créer un utilisateur système, c'est à dire qui n'a pas de répertoire ''home'' mais, cela s'occupe également de la création du groupe associé (clock-php) et ajoute l'utilisateur dans ce groupe !

= Fichier de service systemd =
== Création ==
Maintenant que notre programme ressemble à un ''vrai'' programme, nous pouvons créer un fichier ''.service'' pour demander à systemd de s'en occuper.

Nous allons créer le fichier ''clock-php.service'' dans le même répertoire que le programme pour des raison de simplicité :
<pre>
[Unit]
Description=clock-php daemon service
After=network-online.target

[Service]
Type=simple

User=clock-php
Group=clock-php
UMask=007

ExecStart=/usr/bin/clock-php

Restart=on-failure

TimeoutStopSec=300

[Install]
WantedBy=multi-user.target
</pre>

== Explications ==

{|class="wikitable" width="85%"
|-
|| Section || Directive || Description
|-
|| Unit || Description || la description qui apparait avec la commande ''systemctl status clock-php''
|-
|| Unit || After || Nom de la cible après laquelle le service doit être démarré (et avant laquelle il doit être stoppé). Si vous voulez la liste exhaustive de toutes les cibles : ''systemctl list-units --type target''
|-
|| Service || Type || Type de notre service, peut notamment prendre les valeurs suivante :
* simple → systemd considère que le service démarre de suite (notre cas de figure)
* forking → systemd attend que le processus soit détaché du contexte d'exécution courant et que le processus père ait rendu la main (soit terminé). Utile si on avait fait un fork comme mentionné dans [[Php daemon | cet article]]. Dans ce cas de figure il est intéressant de préciser le fichier de pid avec la directive '''PIDFile='''
* oneshot → utile pour des script qui font un travail et rendent la main. Vous pouvez maintenir l'état du service avec la directive '''RemainAfterExit=yes''' pour que systemd considère le service comme actif après l'exécution du script.
* ...
|-
|| Service || User || l'utilisateur utilisé pour l'abaissement de privilège
|-
|| Service || Group || le groupe utilisé pour l'abaissement de privilège
|-
|| Service || Umask || le masque utilisé pour la création de fichiers
|-
|| Service || ExecStart || Le chemin de l'exécutable
|-
|| Service || Restart || précise quand redémarrer le service :
* on-failure → quand le service échoue (code retour différent de zéro)
* always → dès que le service se termine indépendamment du code retour. C'est utile si vous n'avez pas de boucle qui retient le programme (while ou autre)
|-
|| Service || TimeoutStopSec || temps laissé au programme pour s’arrêter avant de le tuer (SIGKILL)
|-
|| Install || WantedBy || le niveau de démarrage du système dans lequel appelé le programme. Je vous laisse voir cette article à propos des [[Systemctl#Aper.C3.A7u | niveau de démarrage]] mais pour faire simple :
* multi-user.target → ligne de commande
* graphical.target → interface graphique
|}

== Lien symbolique et activation ==
Maintenant que le fichier existe, nous allons créer un lien symbolique dans le répertoire ''/etc/systemd/system'':
<pre>
# systemctl link /opt/php-service/clock-php.service
</pre>
Le service devrait être visible:
<pre>
# systemctl status clock-php.service
</pre>

== Utilisation ==
On peut maintenant utiliser le service avec les commandes traditionnelle :
* start
* stop
* status
* ...
Vous avez tous les détails sur systemd dans [[Systemctl | cet article]] mais pour résumer :
*On démarre donc le service avec :
<pre>
# systemctl start clock-php
</pre>
*On vérifie le status du service avec :
<pre>
# systemctl status clock-php
● clock-php.service - clock-php daemon service
Loaded: loaded (/etc/systemd/system/clock-php.service; alias)
Active: active (running) since Sat 2024-05-18 01:07:46 CEST; 1s ago
Main PID: 1487 (clock-php)
Tasks: 1 (limit: 5904)
Memory: 8.6M
CPU: 27ms
CGroup: /system.slice/clock-php.service
└─1487 /usr/bin/php /usr/bin/clock-php

May 18 01:07:46 prog systemd[1]: Started clock-php daemon service.
</pre>
*On peut même enregistrer le service au démarrage :
<pre>
# systemctl enable clock-php
Created symlink /etc/systemd/system/multi-user.target.wants/clock-php.service → /opt/php-service/clock-php.service.
</pre>

Systemctl service

2025-12-24T04:16:13Z

Jc.forton : /* Test sans SystemD */

= Introduction =
Dans cet article nous allons créer un service, très simplement, avec '''Systemctl'''.

Pour cela, nous allons d'abord utiliser PHP pour ''fabriquer'' notre service, puis nous allons créer un fichier service pour automatiser son démarrage !

= Le programme =
== Création ==
Le service que nous allons faire va simplement écrire le [https://fr.wikipedia.org/wiki/Heure_Unix temps unix] dans un fichier de journalisation pour que, une fois démarré et passé en tâche de fond, nous puissions nous assurer qu'il tourne toujours !

Dans le dossier ''/opt/php-service'' nous allons créer le fichier clock.php :

<syntaxhighlight lang="php">
<?php

define("LOG_FILE", "/tmp/clock.log");

while(1){
file_put_contents(LOG_FILE, time()."\n", FILE_APPEND);
sleep(2);
}
</syntaxhighlight>
Le but de ce programme est d'écrire, toutes les 2 secondes, la date dans le fichier ''/tmp/clock.log''.

== Pas un démon ==
On peut remarquer que ce n'est même pas un démon et qu'il ne rend pas la main lorsque nous allons l’exécuter.
D’ailleurs il n'utilise aucune des fonctions décrites dans [[Php daemon|cet article]] car nous allons demander à ''SystemD'' de s'occuper de tout.

== Test sans SystemD ==
Nous allons tester ce programme :
<source lang=bash>
# php clock.php
</source>
Puis dans un autre terminal, nous pouvons faire :
<source lang=bash>
# tail -f /tmp/clock.php
1715971610
1715971612
1715971614
1715971616
...
</source>

== Préparation pour devenir un service ==
=== shebang===
Nous pourrions utiliser PHP à chaque fois que l'on veut invoquer notre service mais on va plutôt ajouter le [https://fr.wikipedia.org/wiki/Shebang shebang] à la première ligne de notre fichier ''clock.php'' :
<source lang=bash>
#!/usr/bin/php
</source>
Le dossier de l'exécutable de PHP peut changer en fonction des distributions Linux et, si vous avez un doute, n'hésitez pas à utiliser la commande ''whereis'' :
<source lang=bash>
# whereis php
php: /usr/bin/php /usr/lib64/php /usr/share/php /usr/share/man/man1/php.1.gz
</source>

=== Droit d'exécution ===
Maintenant que nous avons ajouté le shebang, ''bash'' va savoir comment exécuter notre programme et il ne nous reste plus qu'a modifier ses droits pour le rendre exécutable :
<source lang=bash>
# chmod +x clock.php
</source>
On peut maintenant exécuter notre programme ainsi :
<source lang=bash>
# ./clock.php
</source>

=== Ajout dans le path ===
Pour reproduire le même comportement que les autres programmes, il est possible d'ajouter notre programme au path pour pouvoir l'appeler grâce à l’autocomplétion. Pour cela, nous allons ajouter un lien symbolique dans le répertoire ''/usr/bin/'' :
<pre>
# ln -fs /opt/php-service/clock.php /usr/bin/clock-php
</pre>
Le programme clock existant déjà, on rajoute ''-php'' à la fin pour ne pas écraser le programme original :). Si votre programme possède un nom unique sur le système, vous n'avez pas besoin de faire ça !

Maintenant de n'importe où on peut utiliser l'autocomplétion pour appeler notre programme :
<pre>
# clock-php
</pre>
Et même demander à whereis où il se trouve :
<pre>
# whereis clock-php
clock-php: /usr/bin/clock-php
</pre>
Nice !
=== Création d'un utilisateur et un groupe ===
Pour des raisons de sécurité, il est préférable que le programme ne tourne pas en tant que ''root'' mais en tant que simple utilisateur.

Puis un utilisateur un peu spécial, qui ne peut pas se connecter et qui n'a pas de répertoire ''home'' :
<pre>
# useradd -r -s /sbin/nologin clock-php
</pre>
Notez que l'option ''-r'' créer un utilisateur système, c'est à dire qui n'a pas de répertoire ''home'' mais, cela s'occupe également de la création du groupe associé (clock-php) et ajoute l'utilisateur dans ce groupe !

= Fichier de service systemd =
== Création ==
Maintenant que notre programme ressemble à un ''vrai'' programme, nous pouvons créer un fichier ''.service'' pour demander à systemd de s'en occuper.

Nous allons créer le fichier ''clock-php.service'' dans le même répertoire que le programme pour des raison de simplicité :
<pre>
[Unit]
Description=clock-php daemon service
After=network-online.target

[Service]
Type=simple

User=clock-php
Group=clock-php
UMask=007

ExecStart=/usr/bin/clock-php

Restart=on-failure

TimeoutStopSec=300

[Install]
WantedBy=multi-user.target
</pre>

== Explications ==

{|class="wikitable" width="85%"
|-
|| Section || Directive || Description
|-
|| Unit || Description || la description qui apparait avec la commande ''systemctl status clock-php''
|-
|| Unit || After || Nom de la cible après laquelle le service doit être démarré (et avant laquelle il doit être stoppé). Si vous voulez la liste exhaustive de toutes les cibles : ''systemctl list-units --type target''
|-
|| Service || Type || Type de notre service, peut notamment prendre les valeurs suivante :
* simple → systemd considère que le service démarre de suite (notre cas de figure)
* forking → systemd attend que le processus soit détaché du contexte d'exécution courant et que le processus père ait rendu la main (soit terminé). Utile si on avait fait un fork comme mentionné dans [[Php daemon | cet article]]. Dans ce cas de figure il est intéressant de préciser le fichier de pid avec la directive '''PIDFile='''
* oneshot → utile pour des script qui font un travail et rendent la main. Vous pouvez maintenir l'état du service avec la directive '''RemainAfterExit=yes''' pour que systemd considère le service comme actif après l'exécution du script.
* ...
|-
|| Service || User || l'utilisateur utilisé pour l'abaissement de privilège
|-
|| Service || Group || le groupe utilisé pour l'abaissement de privilège
|-
|| Service || Umask || le masque utilisé pour la création de fichiers
|-
|| Service || ExecStart || Le chemin de l'exécutable
|-
|| Service || Restart || précise quand redémarrer le service :
* on-failure → quand le service échoue (code retour différent de zéro)
* always → dès que le service se termine indépendamment du code retour. C'est utile si vous n'avez pas de boucle qui retient le programme (while ou autre)
|-
|| Service || TimeoutStopSec || temps laissé au programme pour s’arrêter avant de le tuer (SIGKILL)
|-
|| Install || WantedBy || le niveau de démarrage du système dans lequel appelé le programme. Je vous laisse voir cette article à propos des [[Systemctl#Aper.C3.A7u | niveau de démarrage]] mais pour faire simple :
* multi-user.target → ligne de commande
* graphical.target → interface graphique
|}

== Lien symbolique et activation ==
Maintenant que le fichier existe, nous allons créer un lien symbolique dans le répertoire ''/etc/systemd/system'':
<pre>
# systemctl link /opt/php-service/clock-php.service
</pre>
Le service devrait être visible:
<pre>
# systemctl status clock-php.service
</pre>

== Utilisation ==
On peut maintenant utiliser le service avec les commandes traditionnelle :
* start
* stop
* status
* ...
Vous avez tous les détails sur systemd dans [[Systemctl | cet article]] mais pour résumer :
*On démarre donc le service avec :
<pre>
# systemctl start clock-php
</pre>
*On vérifie le status du service avec :
<pre>
# systemctl status clock-php
● clock-php.service - clock-php daemon service
Loaded: loaded (/etc/systemd/system/clock-php.service; alias)
Active: active (running) since Sat 2024-05-18 01:07:46 CEST; 1s ago
Main PID: 1487 (clock-php)
Tasks: 1 (limit: 5904)
Memory: 8.6M
CPU: 27ms
CGroup: /system.slice/clock-php.service
└─1487 /usr/bin/php /usr/bin/clock-php

May 18 01:07:46 prog systemd[1]: Started clock-php daemon service.
</pre>
*On peut même enregistrer le service au démarrage :
<pre>
# systemctl enable clock-php
Created symlink /etc/systemd/system/multi-user.target.wants/clock-php.service → /opt/php-service/clock-php.service.
</pre>

Systemctl service

2025-12-24T04:15:48Z

Jc.forton : /* Droit d'exécution */

= Introduction =
Dans cet article nous allons créer un service, très simplement, avec '''Systemctl'''.

Pour cela, nous allons d'abord utiliser PHP pour ''fabriquer'' notre service, puis nous allons créer un fichier service pour automatiser son démarrage !

= Le programme =
== Création ==
Le service que nous allons faire va simplement écrire le [https://fr.wikipedia.org/wiki/Heure_Unix temps unix] dans un fichier de journalisation pour que, une fois démarré et passé en tâche de fond, nous puissions nous assurer qu'il tourne toujours !

Dans le dossier ''/opt/php-service'' nous allons créer le fichier clock.php :

<syntaxhighlight lang="php">
<?php

define("LOG_FILE", "/tmp/clock.log");

while(1){
file_put_contents(LOG_FILE, time()."\n", FILE_APPEND);
sleep(2);
}
</syntaxhighlight>
Le but de ce programme est d'écrire, toutes les 2 secondes, la date dans le fichier ''/tmp/clock.log''.

== Pas un démon ==
On peut remarquer que ce n'est même pas un démon et qu'il ne rend pas la main lorsque nous allons l’exécuter.
D’ailleurs il n'utilise aucune des fonctions décrites dans [[Php daemon|cet article]] car nous allons demander à ''SystemD'' de s'occuper de tout.

== Test sans SystemD ==
Nous allons tester ce programme :
<pre>
# php clock.php
</pre>
Puis dans un autre terminal, nous pouvons faire :
<pre>
# tail -f /tmp/clock.php
1715971610
1715971612
1715971614
1715971616
...
</pre>

== Préparation pour devenir un service ==
=== shebang===
Nous pourrions utiliser PHP à chaque fois que l'on veut invoquer notre service mais on va plutôt ajouter le [https://fr.wikipedia.org/wiki/Shebang shebang] à la première ligne de notre fichier ''clock.php'' :
<source lang=bash>
#!/usr/bin/php
</source>
Le dossier de l'exécutable de PHP peut changer en fonction des distributions Linux et, si vous avez un doute, n'hésitez pas à utiliser la commande ''whereis'' :
<source lang=bash>
# whereis php
php: /usr/bin/php /usr/lib64/php /usr/share/php /usr/share/man/man1/php.1.gz
</source>

=== Droit d'exécution ===
Maintenant que nous avons ajouté le shebang, ''bash'' va savoir comment exécuter notre programme et il ne nous reste plus qu'a modifier ses droits pour le rendre exécutable :
<source lang=bash>
# chmod +x clock.php
</source>
On peut maintenant exécuter notre programme ainsi :
<source lang=bash>
# ./clock.php
</source>

=== Ajout dans le path ===
Pour reproduire le même comportement que les autres programmes, il est possible d'ajouter notre programme au path pour pouvoir l'appeler grâce à l’autocomplétion. Pour cela, nous allons ajouter un lien symbolique dans le répertoire ''/usr/bin/'' :
<pre>
# ln -fs /opt/php-service/clock.php /usr/bin/clock-php
</pre>
Le programme clock existant déjà, on rajoute ''-php'' à la fin pour ne pas écraser le programme original :). Si votre programme possède un nom unique sur le système, vous n'avez pas besoin de faire ça !

Maintenant de n'importe où on peut utiliser l'autocomplétion pour appeler notre programme :
<pre>
# clock-php
</pre>
Et même demander à whereis où il se trouve :
<pre>
# whereis clock-php
clock-php: /usr/bin/clock-php
</pre>
Nice !
=== Création d'un utilisateur et un groupe ===
Pour des raisons de sécurité, il est préférable que le programme ne tourne pas en tant que ''root'' mais en tant que simple utilisateur.

Puis un utilisateur un peu spécial, qui ne peut pas se connecter et qui n'a pas de répertoire ''home'' :
<pre>
# useradd -r -s /sbin/nologin clock-php
</pre>
Notez que l'option ''-r'' créer un utilisateur système, c'est à dire qui n'a pas de répertoire ''home'' mais, cela s'occupe également de la création du groupe associé (clock-php) et ajoute l'utilisateur dans ce groupe !

= Fichier de service systemd =
== Création ==
Maintenant que notre programme ressemble à un ''vrai'' programme, nous pouvons créer un fichier ''.service'' pour demander à systemd de s'en occuper.

Nous allons créer le fichier ''clock-php.service'' dans le même répertoire que le programme pour des raison de simplicité :
<pre>
[Unit]
Description=clock-php daemon service
After=network-online.target

[Service]
Type=simple

User=clock-php
Group=clock-php
UMask=007

ExecStart=/usr/bin/clock-php

Restart=on-failure

TimeoutStopSec=300

[Install]
WantedBy=multi-user.target
</pre>

== Explications ==

{|class="wikitable" width="85%"
|-
|| Section || Directive || Description
|-
|| Unit || Description || la description qui apparait avec la commande ''systemctl status clock-php''
|-
|| Unit || After || Nom de la cible après laquelle le service doit être démarré (et avant laquelle il doit être stoppé). Si vous voulez la liste exhaustive de toutes les cibles : ''systemctl list-units --type target''
|-
|| Service || Type || Type de notre service, peut notamment prendre les valeurs suivante :
* simple → systemd considère que le service démarre de suite (notre cas de figure)
* forking → systemd attend que le processus soit détaché du contexte d'exécution courant et que le processus père ait rendu la main (soit terminé). Utile si on avait fait un fork comme mentionné dans [[Php daemon | cet article]]. Dans ce cas de figure il est intéressant de préciser le fichier de pid avec la directive '''PIDFile='''
* oneshot → utile pour des script qui font un travail et rendent la main. Vous pouvez maintenir l'état du service avec la directive '''RemainAfterExit=yes''' pour que systemd considère le service comme actif après l'exécution du script.
* ...
|-
|| Service || User || l'utilisateur utilisé pour l'abaissement de privilège
|-
|| Service || Group || le groupe utilisé pour l'abaissement de privilège
|-
|| Service || Umask || le masque utilisé pour la création de fichiers
|-
|| Service || ExecStart || Le chemin de l'exécutable
|-
|| Service || Restart || précise quand redémarrer le service :
* on-failure → quand le service échoue (code retour différent de zéro)
* always → dès que le service se termine indépendamment du code retour. C'est utile si vous n'avez pas de boucle qui retient le programme (while ou autre)
|-
|| Service || TimeoutStopSec || temps laissé au programme pour s’arrêter avant de le tuer (SIGKILL)
|-
|| Install || WantedBy || le niveau de démarrage du système dans lequel appelé le programme. Je vous laisse voir cette article à propos des [[Systemctl#Aper.C3.A7u | niveau de démarrage]] mais pour faire simple :
* multi-user.target → ligne de commande
* graphical.target → interface graphique
|}

== Lien symbolique et activation ==
Maintenant que le fichier existe, nous allons créer un lien symbolique dans le répertoire ''/etc/systemd/system'':
<pre>
# systemctl link /opt/php-service/clock-php.service
</pre>
Le service devrait être visible:
<pre>
# systemctl status clock-php.service
</pre>

== Utilisation ==
On peut maintenant utiliser le service avec les commandes traditionnelle :
* start
* stop
* status
* ...
Vous avez tous les détails sur systemd dans [[Systemctl | cet article]] mais pour résumer :
*On démarre donc le service avec :
<pre>
# systemctl start clock-php
</pre>
*On vérifie le status du service avec :
<pre>
# systemctl status clock-php
● clock-php.service - clock-php daemon service
Loaded: loaded (/etc/systemd/system/clock-php.service; alias)
Active: active (running) since Sat 2024-05-18 01:07:46 CEST; 1s ago
Main PID: 1487 (clock-php)
Tasks: 1 (limit: 5904)
Memory: 8.6M
CPU: 27ms
CGroup: /system.slice/clock-php.service
└─1487 /usr/bin/php /usr/bin/clock-php

May 18 01:07:46 prog systemd[1]: Started clock-php daemon service.
</pre>
*On peut même enregistrer le service au démarrage :
<pre>
# systemctl enable clock-php
Created symlink /etc/systemd/system/multi-user.target.wants/clock-php.service → /opt/php-service/clock-php.service.
</pre>

Systemctl service

2025-12-24T04:15:21Z

Jc.forton : /* shebang */

= Introduction =
Dans cet article nous allons créer un service, très simplement, avec '''Systemctl'''.

Pour cela, nous allons d'abord utiliser PHP pour ''fabriquer'' notre service, puis nous allons créer un fichier service pour automatiser son démarrage !

= Le programme =
== Création ==
Le service que nous allons faire va simplement écrire le [https://fr.wikipedia.org/wiki/Heure_Unix temps unix] dans un fichier de journalisation pour que, une fois démarré et passé en tâche de fond, nous puissions nous assurer qu'il tourne toujours !

Dans le dossier ''/opt/php-service'' nous allons créer le fichier clock.php :

<syntaxhighlight lang="php">
<?php

define("LOG_FILE", "/tmp/clock.log");

while(1){
file_put_contents(LOG_FILE, time()."\n", FILE_APPEND);
sleep(2);
}
</syntaxhighlight>
Le but de ce programme est d'écrire, toutes les 2 secondes, la date dans le fichier ''/tmp/clock.log''.

== Pas un démon ==
On peut remarquer que ce n'est même pas un démon et qu'il ne rend pas la main lorsque nous allons l’exécuter.
D’ailleurs il n'utilise aucune des fonctions décrites dans [[Php daemon|cet article]] car nous allons demander à ''SystemD'' de s'occuper de tout.

== Test sans SystemD ==
Nous allons tester ce programme :
<pre>
# php clock.php
</pre>
Puis dans un autre terminal, nous pouvons faire :
<pre>
# tail -f /tmp/clock.php
1715971610
1715971612
1715971614
1715971616
...
</pre>

== Préparation pour devenir un service ==
=== shebang===
Nous pourrions utiliser PHP à chaque fois que l'on veut invoquer notre service mais on va plutôt ajouter le [https://fr.wikipedia.org/wiki/Shebang shebang] à la première ligne de notre fichier ''clock.php'' :
<source lang=bash>
#!/usr/bin/php
</source>
Le dossier de l'exécutable de PHP peut changer en fonction des distributions Linux et, si vous avez un doute, n'hésitez pas à utiliser la commande ''whereis'' :
<source lang=bash>
# whereis php
php: /usr/bin/php /usr/lib64/php /usr/share/php /usr/share/man/man1/php.1.gz
</source>

=== Droit d'exécution ===
Maintenant que nous avons ajouté le shebang, ''bash'' va savoir comment exécuter notre programme et il ne nous reste plus qu'a modifier ses droits pour le rendre exécutable :
<pre>
# chmod +x clock.php
</pre>
On peut maintenant exécuter notre programme ainsi :
<pre>
# ./clock.php
</pre>
=== Ajout dans le path ===
Pour reproduire le même comportement que les autres programmes, il est possible d'ajouter notre programme au path pour pouvoir l'appeler grâce à l’autocomplétion. Pour cela, nous allons ajouter un lien symbolique dans le répertoire ''/usr/bin/'' :
<pre>
# ln -fs /opt/php-service/clock.php /usr/bin/clock-php
</pre>
Le programme clock existant déjà, on rajoute ''-php'' à la fin pour ne pas écraser le programme original :). Si votre programme possède un nom unique sur le système, vous n'avez pas besoin de faire ça !

Maintenant de n'importe où on peut utiliser l'autocomplétion pour appeler notre programme :
<pre>
# clock-php
</pre>
Et même demander à whereis où il se trouve :
<pre>
# whereis clock-php
clock-php: /usr/bin/clock-php
</pre>
Nice !
=== Création d'un utilisateur et un groupe ===
Pour des raisons de sécurité, il est préférable que le programme ne tourne pas en tant que ''root'' mais en tant que simple utilisateur.

Puis un utilisateur un peu spécial, qui ne peut pas se connecter et qui n'a pas de répertoire ''home'' :
<pre>
# useradd -r -s /sbin/nologin clock-php
</pre>
Notez que l'option ''-r'' créer un utilisateur système, c'est à dire qui n'a pas de répertoire ''home'' mais, cela s'occupe également de la création du groupe associé (clock-php) et ajoute l'utilisateur dans ce groupe !

= Fichier de service systemd =
== Création ==
Maintenant que notre programme ressemble à un ''vrai'' programme, nous pouvons créer un fichier ''.service'' pour demander à systemd de s'en occuper.

Nous allons créer le fichier ''clock-php.service'' dans le même répertoire que le programme pour des raison de simplicité :
<pre>
[Unit]
Description=clock-php daemon service
After=network-online.target

[Service]
Type=simple

User=clock-php
Group=clock-php
UMask=007

ExecStart=/usr/bin/clock-php

Restart=on-failure

TimeoutStopSec=300

[Install]
WantedBy=multi-user.target
</pre>

== Explications ==

{|class="wikitable" width="85%"
|-
|| Section || Directive || Description
|-
|| Unit || Description || la description qui apparait avec la commande ''systemctl status clock-php''
|-
|| Unit || After || Nom de la cible après laquelle le service doit être démarré (et avant laquelle il doit être stoppé). Si vous voulez la liste exhaustive de toutes les cibles : ''systemctl list-units --type target''
|-
|| Service || Type || Type de notre service, peut notamment prendre les valeurs suivante :
* simple → systemd considère que le service démarre de suite (notre cas de figure)
* forking → systemd attend que le processus soit détaché du contexte d'exécution courant et que le processus père ait rendu la main (soit terminé). Utile si on avait fait un fork comme mentionné dans [[Php daemon | cet article]]. Dans ce cas de figure il est intéressant de préciser le fichier de pid avec la directive '''PIDFile='''
* oneshot → utile pour des script qui font un travail et rendent la main. Vous pouvez maintenir l'état du service avec la directive '''RemainAfterExit=yes''' pour que systemd considère le service comme actif après l'exécution du script.
* ...
|-
|| Service || User || l'utilisateur utilisé pour l'abaissement de privilège
|-
|| Service || Group || le groupe utilisé pour l'abaissement de privilège
|-
|| Service || Umask || le masque utilisé pour la création de fichiers
|-
|| Service || ExecStart || Le chemin de l'exécutable
|-
|| Service || Restart || précise quand redémarrer le service :
* on-failure → quand le service échoue (code retour différent de zéro)
* always → dès que le service se termine indépendamment du code retour. C'est utile si vous n'avez pas de boucle qui retient le programme (while ou autre)
|-
|| Service || TimeoutStopSec || temps laissé au programme pour s’arrêter avant de le tuer (SIGKILL)
|-
|| Install || WantedBy || le niveau de démarrage du système dans lequel appelé le programme. Je vous laisse voir cette article à propos des [[Systemctl#Aper.C3.A7u | niveau de démarrage]] mais pour faire simple :
* multi-user.target → ligne de commande
* graphical.target → interface graphique
|}

== Lien symbolique et activation ==
Maintenant que le fichier existe, nous allons créer un lien symbolique dans le répertoire ''/etc/systemd/system'':
<pre>
# systemctl link /opt/php-service/clock-php.service
</pre>
Le service devrait être visible:
<pre>
# systemctl status clock-php.service
</pre>

== Utilisation ==
On peut maintenant utiliser le service avec les commandes traditionnelle :
* start
* stop
* status
* ...
Vous avez tous les détails sur systemd dans [[Systemctl | cet article]] mais pour résumer :
*On démarre donc le service avec :
<pre>
# systemctl start clock-php
</pre>
*On vérifie le status du service avec :
<pre>
# systemctl status clock-php
● clock-php.service - clock-php daemon service
Loaded: loaded (/etc/systemd/system/clock-php.service; alias)
Active: active (running) since Sat 2024-05-18 01:07:46 CEST; 1s ago
Main PID: 1487 (clock-php)
Tasks: 1 (limit: 5904)
Memory: 8.6M
CPU: 27ms
CGroup: /system.slice/clock-php.service
└─1487 /usr/bin/php /usr/bin/clock-php

May 18 01:07:46 prog systemd[1]: Started clock-php daemon service.
</pre>
*On peut même enregistrer le service au démarrage :
<pre>
# systemctl enable clock-php
Created symlink /etc/systemd/system/multi-user.target.wants/clock-php.service → /opt/php-service/clock-php.service.
</pre>

Systemctl service

2025-12-24T03:33:29Z

Jc.forton : /* Lien symbolique et activation */

= Introduction =
Dans cet article nous allons créer un service, très simplement, avec '''Systemctl'''.

Pour cela, nous allons d'abord utiliser PHP pour ''fabriquer'' notre service, puis nous allons créer un fichier service pour automatiser son démarrage !

= Le programme =
== Création ==
Le service que nous allons faire va simplement écrire le [https://fr.wikipedia.org/wiki/Heure_Unix temps unix] dans un fichier de journalisation pour que, une fois démarré et passé en tâche de fond, nous puissions nous assurer qu'il tourne toujours !

Dans le dossier ''/opt/php-service'' nous allons créer le fichier clock.php :

<syntaxhighlight lang="php">
<?php

define("LOG_FILE", "/tmp/clock.log");

while(1){
file_put_contents(LOG_FILE, time()."\n", FILE_APPEND);
sleep(2);
}
</syntaxhighlight>
Le but de ce programme est d'écrire, toutes les 2 secondes, la date dans le fichier ''/tmp/clock.log''.

== Pas un démon ==
On peut remarquer que ce n'est même pas un démon et qu'il ne rend pas la main lorsque nous allons l’exécuter.
D’ailleurs il n'utilise aucune des fonctions décrites dans [[Php daemon|cet article]] car nous allons demander à ''SystemD'' de s'occuper de tout.

== Test sans SystemD ==
Nous allons tester ce programme :
<pre>
# php clock.php
</pre>
Puis dans un autre terminal, nous pouvons faire :
<pre>
# tail -f /tmp/clock.php
1715971610
1715971612
1715971614
1715971616
...
</pre>

== Préparation pour devenir un service ==
=== shebang===
Nous pourrions utiliser PHP à chaque fois que l'on veut invoquer notre service mais on va plutôt ajouter le [https://fr.wikipedia.org/wiki/Shebang shebang] à la première ligne de notre fichier ''clock.php'' :
<pre>
#!/usr/bin/php
</pre>
Le dossier de l'exécutable de PHP peut changer en fonction des distributions Linux et, si vous avez un doute, n'hésitez pas à utiliser la commande ''whereis'' :
<pre>
# whereis php
php: /usr/bin/php /usr/lib64/php /usr/share/php /usr/share/man/man1/php.1.gz
</pre>
=== Droit d'exécution ===
Maintenant que nous avons ajouté le shebang, ''bash'' va savoir comment exécuter notre programme et il ne nous reste plus qu'a modifier ses droits pour le rendre exécutable :
<pre>
# chmod +x clock.php
</pre>
On peut maintenant exécuter notre programme ainsi :
<pre>
# ./clock.php
</pre>
=== Ajout dans le path ===
Pour reproduire le même comportement que les autres programmes, il est possible d'ajouter notre programme au path pour pouvoir l'appeler grâce à l’autocomplétion. Pour cela, nous allons ajouter un lien symbolique dans le répertoire ''/usr/bin/'' :
<pre>
# ln -fs /opt/php-service/clock.php /usr/bin/clock-php
</pre>
Le programme clock existant déjà, on rajoute ''-php'' à la fin pour ne pas écraser le programme original :). Si votre programme possède un nom unique sur le système, vous n'avez pas besoin de faire ça !

Maintenant de n'importe où on peut utiliser l'autocomplétion pour appeler notre programme :
<pre>
# clock-php
</pre>
Et même demander à whereis où il se trouve :
<pre>
# whereis clock-php
clock-php: /usr/bin/clock-php
</pre>
Nice !
=== Création d'un utilisateur et un groupe ===
Pour des raisons de sécurité, il est préférable que le programme ne tourne pas en tant que ''root'' mais en tant que simple utilisateur.

Puis un utilisateur un peu spécial, qui ne peut pas se connecter et qui n'a pas de répertoire ''home'' :
<pre>
# useradd -r -s /sbin/nologin clock-php
</pre>
Notez que l'option ''-r'' créer un utilisateur système, c'est à dire qui n'a pas de répertoire ''home'' mais, cela s'occupe également de la création du groupe associé (clock-php) et ajoute l'utilisateur dans ce groupe !

= Fichier de service systemd =
== Création ==
Maintenant que notre programme ressemble à un ''vrai'' programme, nous pouvons créer un fichier ''.service'' pour demander à systemd de s'en occuper.

Nous allons créer le fichier ''clock-php.service'' dans le même répertoire que le programme pour des raison de simplicité :
<pre>
[Unit]
Description=clock-php daemon service
After=network-online.target

[Service]
Type=simple

User=clock-php
Group=clock-php
UMask=007

ExecStart=/usr/bin/clock-php

Restart=on-failure

TimeoutStopSec=300

[Install]
WantedBy=multi-user.target
</pre>

== Explications ==

{|class="wikitable" width="85%"
|-
|| Section || Directive || Description
|-
|| Unit || Description || la description qui apparait avec la commande ''systemctl status clock-php''
|-
|| Unit || After || Nom de la cible après laquelle le service doit être démarré (et avant laquelle il doit être stoppé). Si vous voulez la liste exhaustive de toutes les cibles : ''systemctl list-units --type target''
|-
|| Service || Type || Type de notre service, peut notamment prendre les valeurs suivante :
* simple → systemd considère que le service démarre de suite (notre cas de figure)
* forking → systemd attend que le processus soit détaché du contexte d'exécution courant et que le processus père ait rendu la main (soit terminé). Utile si on avait fait un fork comme mentionné dans [[Php daemon | cet article]]. Dans ce cas de figure il est intéressant de préciser le fichier de pid avec la directive '''PIDFile='''
* oneshot → utile pour des script qui font un travail et rendent la main. Vous pouvez maintenir l'état du service avec la directive '''RemainAfterExit=yes''' pour que systemd considère le service comme actif après l'exécution du script.
* ...
|-
|| Service || User || l'utilisateur utilisé pour l'abaissement de privilège
|-
|| Service || Group || le groupe utilisé pour l'abaissement de privilège
|-
|| Service || Umask || le masque utilisé pour la création de fichiers
|-
|| Service || ExecStart || Le chemin de l'exécutable
|-
|| Service || Restart || précise quand redémarrer le service :
* on-failure → quand le service échoue (code retour différent de zéro)
* always → dès que le service se termine indépendamment du code retour. C'est utile si vous n'avez pas de boucle qui retient le programme (while ou autre)
|-
|| Service || TimeoutStopSec || temps laissé au programme pour s’arrêter avant de le tuer (SIGKILL)
|-
|| Install || WantedBy || le niveau de démarrage du système dans lequel appelé le programme. Je vous laisse voir cette article à propos des [[Systemctl#Aper.C3.A7u | niveau de démarrage]] mais pour faire simple :
* multi-user.target → ligne de commande
* graphical.target → interface graphique
|}

== Lien symbolique et activation ==
Maintenant que le fichier existe, nous allons créer un lien symbolique dans le répertoire ''/etc/systemd/system'':
<pre>
# systemctl link /opt/php-service/clock-php.service
</pre>
Le service devrait être visible:
<pre>
# systemctl status clock-php.service
</pre>

== Utilisation ==
On peut maintenant utiliser le service avec les commandes traditionnelle :
* start
* stop
* status
* ...
Vous avez tous les détails sur systemd dans [[Systemctl | cet article]] mais pour résumer :
*On démarre donc le service avec :
<pre>
# systemctl start clock-php
</pre>
*On vérifie le status du service avec :
<pre>
# systemctl status clock-php
● clock-php.service - clock-php daemon service
Loaded: loaded (/etc/systemd/system/clock-php.service; alias)
Active: active (running) since Sat 2024-05-18 01:07:46 CEST; 1s ago
Main PID: 1487 (clock-php)
Tasks: 1 (limit: 5904)
Memory: 8.6M
CPU: 27ms
CGroup: /system.slice/clock-php.service
└─1487 /usr/bin/php /usr/bin/clock-php

May 18 01:07:46 prog systemd[1]: Started clock-php daemon service.
</pre>
*On peut même enregistrer le service au démarrage :
<pre>
# systemctl enable clock-php
Created symlink /etc/systemd/system/multi-user.target.wants/clock-php.service → /opt/php-service/clock-php.service.
</pre>

Systemctl service

2025-12-24T03:33:17Z

Jc.forton : /* Lien symbolique et activation */

= Introduction =
Dans cet article nous allons créer un service, très simplement, avec '''Systemctl'''.

Pour cela, nous allons d'abord utiliser PHP pour ''fabriquer'' notre service, puis nous allons créer un fichier service pour automatiser son démarrage !

= Le programme =
== Création ==
Le service que nous allons faire va simplement écrire le [https://fr.wikipedia.org/wiki/Heure_Unix temps unix] dans un fichier de journalisation pour que, une fois démarré et passé en tâche de fond, nous puissions nous assurer qu'il tourne toujours !

Dans le dossier ''/opt/php-service'' nous allons créer le fichier clock.php :

<syntaxhighlight lang="php">
<?php

define("LOG_FILE", "/tmp/clock.log");

while(1){
file_put_contents(LOG_FILE, time()."\n", FILE_APPEND);
sleep(2);
}
</syntaxhighlight>
Le but de ce programme est d'écrire, toutes les 2 secondes, la date dans le fichier ''/tmp/clock.log''.

== Pas un démon ==
On peut remarquer que ce n'est même pas un démon et qu'il ne rend pas la main lorsque nous allons l’exécuter.
D’ailleurs il n'utilise aucune des fonctions décrites dans [[Php daemon|cet article]] car nous allons demander à ''SystemD'' de s'occuper de tout.

== Test sans SystemD ==
Nous allons tester ce programme :
<pre>
# php clock.php
</pre>
Puis dans un autre terminal, nous pouvons faire :
<pre>
# tail -f /tmp/clock.php
1715971610
1715971612
1715971614
1715971616
...
</pre>

== Préparation pour devenir un service ==
=== shebang===
Nous pourrions utiliser PHP à chaque fois que l'on veut invoquer notre service mais on va plutôt ajouter le [https://fr.wikipedia.org/wiki/Shebang shebang] à la première ligne de notre fichier ''clock.php'' :
<pre>
#!/usr/bin/php
</pre>
Le dossier de l'exécutable de PHP peut changer en fonction des distributions Linux et, si vous avez un doute, n'hésitez pas à utiliser la commande ''whereis'' :
<pre>
# whereis php
php: /usr/bin/php /usr/lib64/php /usr/share/php /usr/share/man/man1/php.1.gz
</pre>
=== Droit d'exécution ===
Maintenant que nous avons ajouté le shebang, ''bash'' va savoir comment exécuter notre programme et il ne nous reste plus qu'a modifier ses droits pour le rendre exécutable :
<pre>
# chmod +x clock.php
</pre>
On peut maintenant exécuter notre programme ainsi :
<pre>
# ./clock.php
</pre>
=== Ajout dans le path ===
Pour reproduire le même comportement que les autres programmes, il est possible d'ajouter notre programme au path pour pouvoir l'appeler grâce à l’autocomplétion. Pour cela, nous allons ajouter un lien symbolique dans le répertoire ''/usr/bin/'' :
<pre>
# ln -fs /opt/php-service/clock.php /usr/bin/clock-php
</pre>
Le programme clock existant déjà, on rajoute ''-php'' à la fin pour ne pas écraser le programme original :). Si votre programme possède un nom unique sur le système, vous n'avez pas besoin de faire ça !

Maintenant de n'importe où on peut utiliser l'autocomplétion pour appeler notre programme :
<pre>
# clock-php
</pre>
Et même demander à whereis où il se trouve :
<pre>
# whereis clock-php
clock-php: /usr/bin/clock-php
</pre>
Nice !
=== Création d'un utilisateur et un groupe ===
Pour des raisons de sécurité, il est préférable que le programme ne tourne pas en tant que ''root'' mais en tant que simple utilisateur.

Puis un utilisateur un peu spécial, qui ne peut pas se connecter et qui n'a pas de répertoire ''home'' :
<pre>
# useradd -r -s /sbin/nologin clock-php
</pre>
Notez que l'option ''-r'' créer un utilisateur système, c'est à dire qui n'a pas de répertoire ''home'' mais, cela s'occupe également de la création du groupe associé (clock-php) et ajoute l'utilisateur dans ce groupe !

= Fichier de service systemd =
== Création ==
Maintenant que notre programme ressemble à un ''vrai'' programme, nous pouvons créer un fichier ''.service'' pour demander à systemd de s'en occuper.

Nous allons créer le fichier ''clock-php.service'' dans le même répertoire que le programme pour des raison de simplicité :
<pre>
[Unit]
Description=clock-php daemon service
After=network-online.target

[Service]
Type=simple

User=clock-php
Group=clock-php
UMask=007

ExecStart=/usr/bin/clock-php

Restart=on-failure

TimeoutStopSec=300

[Install]
WantedBy=multi-user.target
</pre>

== Explications ==

{|class="wikitable" width="85%"
|-
|| Section || Directive || Description
|-
|| Unit || Description || la description qui apparait avec la commande ''systemctl status clock-php''
|-
|| Unit || After || Nom de la cible après laquelle le service doit être démarré (et avant laquelle il doit être stoppé). Si vous voulez la liste exhaustive de toutes les cibles : ''systemctl list-units --type target''
|-
|| Service || Type || Type de notre service, peut notamment prendre les valeurs suivante :
* simple → systemd considère que le service démarre de suite (notre cas de figure)
* forking → systemd attend que le processus soit détaché du contexte d'exécution courant et que le processus père ait rendu la main (soit terminé). Utile si on avait fait un fork comme mentionné dans [[Php daemon | cet article]]. Dans ce cas de figure il est intéressant de préciser le fichier de pid avec la directive '''PIDFile='''
* oneshot → utile pour des script qui font un travail et rendent la main. Vous pouvez maintenir l'état du service avec la directive '''RemainAfterExit=yes''' pour que systemd considère le service comme actif après l'exécution du script.
* ...
|-
|| Service || User || l'utilisateur utilisé pour l'abaissement de privilège
|-
|| Service || Group || le groupe utilisé pour l'abaissement de privilège
|-
|| Service || Umask || le masque utilisé pour la création de fichiers
|-
|| Service || ExecStart || Le chemin de l'exécutable
|-
|| Service || Restart || précise quand redémarrer le service :
* on-failure → quand le service échoue (code retour différent de zéro)
* always → dès que le service se termine indépendamment du code retour. C'est utile si vous n'avez pas de boucle qui retient le programme (while ou autre)
|-
|| Service || TimeoutStopSec || temps laissé au programme pour s’arrêter avant de le tuer (SIGKILL)
|-
|| Install || WantedBy || le niveau de démarrage du système dans lequel appelé le programme. Je vous laisse voir cette article à propos des [[Systemctl#Aper.C3.A7u | niveau de démarrage]] mais pour faire simple :
* multi-user.target → ligne de commande
* graphical.target → interface graphique
|}

== Lien symbolique et activation ==
Maintenant que le fichier existe, nous allons créer un lien symbolique dans le répertoire ''/etc/systemd/system'':
<pre>
# systemctl link /opt/php-service/clock-php.service
</pre>
Le service devrait être visible:
<pre>
systemctl status clock-php.service
</pre>

== Utilisation ==
On peut maintenant utiliser le service avec les commandes traditionnelle :
* start
* stop
* status
* ...
Vous avez tous les détails sur systemd dans [[Systemctl | cet article]] mais pour résumer :
*On démarre donc le service avec :
<pre>
# systemctl start clock-php
</pre>
*On vérifie le status du service avec :
<pre>
# systemctl status clock-php
● clock-php.service - clock-php daemon service
Loaded: loaded (/etc/systemd/system/clock-php.service; alias)
Active: active (running) since Sat 2024-05-18 01:07:46 CEST; 1s ago
Main PID: 1487 (clock-php)
Tasks: 1 (limit: 5904)
Memory: 8.6M
CPU: 27ms
CGroup: /system.slice/clock-php.service
└─1487 /usr/bin/php /usr/bin/clock-php

May 18 01:07:46 prog systemd[1]: Started clock-php daemon service.
</pre>
*On peut même enregistrer le service au démarrage :
<pre>
# systemctl enable clock-php
Created symlink /etc/systemd/system/multi-user.target.wants/clock-php.service → /opt/php-service/clock-php.service.
</pre>

The Linux Craftsman

2025-12-21T16:36:31Z

Jc.forton : /* La pratique */

= Ce wiki =
<div align="center">
{|class="wikitable" width="100%"
! Le contenu !! Public visé !! L'auteur
|-valign=top
|width="33%"|
Ce wiki propose des articles, cours, TPs et TDs sur des sujets gravitant autour des technologies du système d'information, notamment sur le système Linux, sur la distribution CentOS et maintenant Rocky Linux.

Vous y trouverez des articles traitant de la mise en place de services réseaux tels que DHCP et DNS mais également des articles sur la mise en place de pare-feu, site Web, etc... Il y a un peu de tout et je vous encourage à utiliser le champ de recherche pour trouver ce dont vous avez besoin.
|width="33%"|

Ce wiki s'adresse principalement à mes élèves mais il peut également servir à des enseignants qui désirent monter leurs cours sans se "prendre la tête".

Tout est disponible sous [http://www.gnu.org/copyleft/fdl.html licence GNU Free Documentation License 1.3] ou ultérieure et vous pouvez récupérer les contenus et en faire ce que vous voulez !
|width="33%"|

Je m'appelle Jean-Christophe FORTON et je suis professeur d'informatique depuis 2011 mais cela n'a pas toujours été mon métier, plus d'info [[jcf|ici]]...

N'hésitez pas à faire un tour sur :
{|
|-valign=middle
|align=center|
[[Image:Logo-YouTube-rouge.png|30px|link=https://www.youtube.com/@tala-informatique]]
|| ma chaîne Youtube pour découvrir mes aventures ou (re)visionner certains cours
|-valign=middle
|align=center|
[[Fichier:Logo-Tipeee.png|27px|link=https://fr.tipeee.com/tala-informatique]]
||mon Tipeee pour me remercier
|}
|}
</div>

= Les cours =
<div align="center">
{|class="wikitable" width="100%"
! Système !! Sécurité !! Réseaux !! Développement !! Général
|-valign=top
||
<hr>
<div align="center">Linux</div>
<hr>
* [[:Media:intro_linux.pdf|Introduction au système Linux]]
* [[:Media:tp_linux_commandes_de_bases.pdf|TP Linux : commandes de bases]]
<hr>
<div align="center">Windows</div>
<hr>
* Architecture des ordinateurs en environnement Windows
** [[:Media:materiel.pdf|Le matériel]]
** [[:Media:system_exploitation.pdf|Le système d'exploitation]]
** [[:Media:gestion_disques.pdf|La gestion des disques]]
** [[:Media:sauvegarde.pdf|La sauvegarde]]
* Active Directory
** [[:Media:ad_intro.pdf|Les principes fondamentaux]]
** [[:Media:ad_gpo.pdf|Gestion des stratégies]]
||
<hr>
<div align="center">Réseaux</div>
<hr>
* [[:Media:Les pare-feux.pdf|Les pare-feux]]
* [[:Media:Les pare-feux_tech.pdf|Les pare-feux (fiche technique)]]
* [[:Media:Les VPN.pdf|Les VPN]]
* [[:Media:Haute_dispo.pdf|Haute disponibilité]]
* [[:Media:sauvegarde_pca.pdf|La sauvegarde]]
<hr>
<div align="center">Sécurité des Systèmes d’Information</div>
<hr>
* [[:Media:principes_SSI.pdf|Les principes fondamentaux]]
* [[:Media:implémentation_concrete_SSI.pdf|Implémentation concrète de la sécurité]]
* [[:Media:cryptographie.pdf|Cryptographie]]
* [[:Media:TD1_SSI.pdf|TD1: Principes Fondamentaux]]
* [[:Media:TP1_SSI.pdf|TP1: Écoute d'une connexion]]
* [[:Media:TP2_SSI.pdf|TP2: Chiffrement asymétrique avec PGP]]
<hr>
<div align="center">Web</div>
<hr>
* [[:Media:apache server.pdf|Le serveur Apache]]
* [[:Media:pilotage web bdd.pdf|Pilotage d'une page web]]
* [[:Media:web app security.pdf|Sécurité des applications Web]]
||
<hr>
<div align="center">Modèle OSI</div>
<hr>
*[[:Media:OSI.pdf|Le modèle OSI en version cours]]
*[[:Media:OSI_Slides.pdf|Le modèle OSI en version slides]]
<hr>
<div align="center">OSI 1 </div>
<hr>
* [[:Media:Normes_cablages.pdf|Les normes de câblage]]
<hr>
<div align="center">OSI 2</div>
<hr>
* [[:Media:Ethernet-802.3.pdf|La norme Ethernet (802.3)]]
* [[:Media:WiFi-802.11.pdf|La norme Wi-Fi (802.11)]]
* [[:Media:Bridge.pdf|Les bridges]]
* [[:Media:STP.pdf|Spanning Tree Protocol]]
* [[:Media:VLAN.pdf|Les Vlans]]
<hr>
<div align="center">OSI 3+</div>
<hr>
* Routage:
** [[:Media:CIDR.pdf|Classless Inter-Domain Routing]]
** [[:Media:resume_protocoles_vecteur_distance.pdf|Résumé sur les protocoles à vecteur de distance]]
** [[:Media:EIGRP.pdf|Enhanced Interior Gateway Routing Protocol]]
** [[:Media:OSPF.pdf|Open Shortest Path First]]
** [[:Media:BGP.pdf|Border Gateway Protocol]]
*Services:
** [[:Media:DHCP.pdf|DHCP]]
** [[:Media:DNS.pdf|DNS]]
** [[:Media:SAMBA.pdf|Samba]]
<hr>
<div align="center">Qualité de service</div>
<hr>
* [[:Media:QoS.pdf|La QoS]]
* [[:Media:Iproute2_QoS.pdf|Iproute2 et la QoS]]
<hr>
<div align="center">Protocole</div>
<hr>
* [[:Media:HTTP.pdf|HTTP]]
* [[:Media:SNMP.pdf|SNMP]]
||
<hr>
<div align="center">L'algorithmique</div>
<hr>
* [[:Media:algo_intro.pdf|Introduction]]
* [[:Media:algo_langage.pdf|Le Langage]]
<hr>
<div align="center">SQL</div>
<hr>
* [[:Media:conception_bdd.pdf|Conception de base de données]]
* [[:Media:conception_bdd_simple.pdf|Conception de base de données (simplifié)]]
* [[:Media:langage_de_requête.pdf|Langage de requête]]
<hr>
<div align="center">Langages du Web</div>
<hr>
* [[:Media:HTML xHTML intro.pdf|Le langage HTML]]
* [[:Media:css.pdf|Le langage CSS]]
* [[:Media:javascript.pdf|Le langage JavaScript]]
* [[:Media:php.pdf|Le langage PHP]]
<hr>
<div align="center">Langage bas niveau</div>
<hr>
* [[:Media:C lang.pdf|Le langage C]]
<hr>
<div align="center">Architecture SOA</div>
<hr>
* [[:Media:webservices.pdf|Les Web Services RESTful]]
<hr>
<div align="center">Informatique embarquée</div>
<hr>
* [[:Media:arduino_avr.pdf|Arduino et AVR]]
* [[:Media:IOT.pdf|L'Internet des objets]]
||
<hr>
<div align="center">Gestion</div>
<hr>
* [[:Media:gestion_projet.pdf|Gestion de projet]]
<hr>
<div align="center">Bureautique</div>
<hr>
* [[:Media:powerpoint.pdf|PowerPoint]]
* [[:Media:excel.pdf|Excel]]
* [[:Media:bdd_com.pdf|Les bases de données]]
<hr>
<div align="center">Histoire / évolutions</div>
<hr>
* [[:Media:expertise_codage.pdf|Expertise codage]]
|}
</div>

= La pratique =
<div align="center">
{|class="wikitable" width="100%"
! Système !! Sécurité !! Réseaux !! Développement !! Embarquée !! Virtualisation
|-valign="top"
|align=left|
<hr>
<div align="center">Général</div>
<hr>
* [[Installation de CentOS]]
* [[Installation de Rocky]]
* [[migration_centos8torocky8| Migration CentOS 8 → Rocky 8]]
* [[upgrade_rocky8to9| Upgrade Rocky 8 → 9]]
* [[WSL | WSL : Installation de Linux sur Windows 10]]
* [[Vi / Vim]]
* [[linux_repository|Les dépots (EPEL, EL, ...)]]
* [[cron| Gestionnaire des tâches: cron]]
* [[rpm_yum| Gestionnaires de paquetages: RPM & YUM]]
* [[Les logs]]
* [[users_groups|Utilisateurs et groupes]]
* [[Gestion des disques]]
* CentOS ≥ 7 (≈ Rocky) [[Fichier:Warning-icon.png|20px]]
** [[systemctl|Systemctl sur SystemD]]
** [[systemctl service|Créer un service avec Systemctl (démon)]]
** [[iptables_on_systemd | Firewalld ?!? Rendez moi Iptables ! ]]
** [[chrony|''NTP'' est mort, vive ''Chrony'']]
* CentOS 6
** [[Gestionnaire de démarrage|Gestionnaire de démarrage SysVInit]]
** [[start_stop_daemon|Création d'un service avec start-stop-daemon (SysVInit)]]
<hr>
<div align="center">Réseaux</div>
<hr>
* [[ifcfg-ethX|Les interfaces réseaux]]
* [[sysconfig-network|Les paramètres réseaux]]
* [[resolv.conf|Configuration du client DNS]]
* [[ntpd|Configuration du client NTP]]
<hr>
<div align="center">Haute disponibilité</div>
<hr>
* [[drbd|Réplication à chaud avec DRBD]]
<hr>
<div align="center">Multimédia</div>
<hr>
* [[DLNA|Partage de contenu cross-platform avec DLNA]]
|
<hr>
<div align="center">Réseaux</div>
<hr>
* [[Iptables]]
* [[Squid]]
* [[:Media:Chillispot.pdf|Hotspot avec Chillispot]]
* [[Sécuriser un service avec Fail2ban]]
* [[Openvpn]]
* [[Wireguard]]
<hr>
<div align="center">Système</div>
<hr>
* [[SSH]]
* [[SELinux]]
|
<hr>
<div align="center">Les outils</div>
<hr>
* [[tcpdump | Le scanner ''tcpdump'']]
* [[iproute2 | Contrôle réseau avec la commande ''ip'']]
<hr>
<div align="center">OSI 2</div>
<hr>
* [[source routing|Le routage source]]
* [[bridge|Les bridges]]
* [[alias|Les alias]]
* [[vlan|Les vlans]]
* [[one-arm_router|La passerelle ''one-arm'']]
* [[transparent_firewall|Le proxy ''transparent'']]
<hr>
<div align="center">OSI 3+</div>
<hr>
* Services:
** [[DHCP]]
** [[DNS]]
*Haute-disponibilité
** [[Ucarp]]
<hr>
<div align="center">OSI 7</div>
<hr>
* Services:
** [[SAMBA]]
** [[HTTPD]]
** [[xmpp | Serveur XMPP avec Ejabberd]]
** [[vnc|Installer un serveur VNC]]
* Industrialisation:
** [[:Media:pxe.pdf|Monter un serveur PXE (pdf)]]
** [[PXE|Monter un serveur PXE]]
* Supervision
** [[Nagios| Nagios]]
** [[Cacti| Installer un serveur Cacti]]
** [[SNMP | Utiliser SNMP]]
<hr>
<div align="center">Cisco ISR (routeur)</div>
<hr>
* [[ISR-basics|Les bases]]
|
<hr>
<div align="center">Général</div>
<hr>
* [[eclipse_install|Mise en place de l'environnement de développement]]
* [[svn|Serveur de version SVN]]
<hr>
<div align="center">PHP</div>
<hr>
*Les basiques :
** [[php_httpd_install | Installation sous Linux]]
** [[php_devel| Premier projet en ''PHP'']]
** [[php_algo|Un peu d'algorithmique]]
** [[php_object| Les objets]]
** [[php_xdebug| Debugger avec ''Xdebug'']]
* La partie CLI :
** [[php_memcached| Memcached un serveur de cache]]
** [[php_daemon | Écriture d'un démon]]
** [[php_socket | Utilisation des sockets]]
* La partie Web :
** [[php_$get_$post_$session| Passer des informations entres pages]]
** [[php_pdo| Utiliser une base MySQL avec PDO]]
** [[php_slim | Le framework SLIM]]
<hr>
<div align="center">JavaScript</div>
<hr>
*Les basiques :
** [[js_devel| Premier projet en ''JavaScript'']]
** [[js_algo| Un peu d'algorithmique]]
** [[js_object| Les objets]]
*Les RIA (''R''ich ''I''nternet ''A''pplication) :
** [[js_AJAX| Client AJAX pour utiliser des Web Services]]
** [[js_AJAX_auth | Authentification avec un client AJAX]]
** [[js_AJAX_fetch_api | Découverte de l'API ''fetch'']]
<hr>
<div align="center">Java</div>
<hr>
*Les basiques :
** [[java_devel| Premier projet en ''Java'']]
** [[java_jar|Mon premier objet]]
** [[java_algo| Un peu d'algorithmique]]
* La partie Web:
** [[java_servlet|Les Servlets]]
** [[java_ws_restful| Web Service Restful]]
* Stocker des informations:
** [[java_mysql| Utiliser une base MySQL avec Java]]
** [[java_memcached| Memcached un serveur de cache]]
<hr>
<div align="center">C</div>
<hr>
*Les basiques :
** [[c_devel| Premier projet en ''C'']]
** [[c_devel_cross| Compilation croisée (Cross Compilation)]]
** [[c_algo| Un peu d'algorithmique]]
*Execution parallèle :
** [[c_pthread| Les threads]]
** [[c_fork| Les forks]]
* IPC:
** [[c_pipe| Les tubes]]
** [[c_semaphore| Les sémaphores]]
** [[c_signals| Les signaux POSIX]]
** [[c_socket| Les sockets]]
* GP-GPU avec CUDA:
** [[cuda_install| Installation de CUDA]]
** [[cuda_hello_world| Les concepts et bases]]
<hr>
<div align="center">Python</div>
<hr>
* [[python_devel| Premier projet en ''Python'']]
* [[python_algo|Un peu d'algorithmique]]
<hr>
<div align="center">SQL</div>
<hr>
* [[sql_install| Installation d'un SGBDR]]
* [[SQL_import| Importation d'une base de données]]
|
<hr>
<div align="center">Général</div>
<hr>
* [[Arduino_sketch_writing | Écriture d'un sketch]]
* [[Arduino_CH340_driver_install | Installation du pilote CH340 (Serial TTL)]]
* [[Arduino_FTDI_driver_install | Installation du pilote FTDI(Serial TTL)]]
* [[Arduino_CP210X_driver_install | Installation du pilote CP210X(Serial TTL)]]
* [[Arduino_Eclipse_sketch | Création d'un projet sous Eclipse]]
* [[arduino_diagram | Schémas des cartes Arduino]]
* [[esp8266_diagram | Schémas des cartes ESP8266]]
* [[esp32_diagram | Schémas des cartes ESP32]]
* [[sbc_diagram | Schémas des SBC]]
* [[µc_datasheet | Fiches techniques des microcontrôleurs]]
<hr>
<div align="center">Capteurs</div>
<hr>
* [[Arduino_LDR | Luminosité avec une photorésistance]]
* [[Arduino_BH1750 | Luminosité avec le BH1750]]
* [[Arduino_DS18B20 | Température avec le DS18B20]]
* [[Arduino_LM35DZ | Température avec le LM35]]
* [[Arduino_DHT11 | Température et humidité avec le DHT11]]
* [[Arduino_BMP280 | Température, pression et altitude avec le BMP280]]
* [[Arduino_A3144 | Effet de Hall (magnétisme) avec le A3144 ]]
* [[Arduino_SR501 | Détection de mouvement avec le SR501 (PIR) ]]
* [[Arduino_soil_moisture | Capteur d'humidité du sol ]]
<hr>
<div align="center">Communication</div>
<hr>
* Sans-fil:
** [[Arduino_HC12 | Communication RF433 avec un HC12]]
** [[Arduino_NRF24L01 | Communication 2.4Ghz avec un NRF24L01]]
** [[Arduino_ESP05 | Communication Wi-Fi avec un ESP-05]]
* Shield Ethernet (W5100):
** [[Arduino_W5100_intro | Présentation du shield]]
** [[Arduino_W5100_OSI3 | Configuration OSI 3]]
** [[Arduino_W5100_web_server | Utilisation du Shield Ethernet pour faire un serveur Web]]
<hr>
<div align="center">Composants et montages divers</div>
<hr>
* [[ potentiometre | Potentiomètre ]]
* [[ shift_register | Registre à décalage ]]
* [[ Arduino_2axis_joystick_button | Joystick 2 axes avec bouton ]]
* [[ Arduino_SD_CARD | Module pour cartes SD ]]
<hr>
<div align="center">ESP8266 / ESP32</div>
<hr>
* [[esp_ide_arduino | Cartes ESP et IDE Arduino]]
* [[esp8266_wifi | Utilisation du WiFi ]]
* [[esp8266_webserver | Utilisation du serveur web ]]
* [[esp8266_udp_server | Serveur UDP ]]
* [[esp8266_ntp_client | Client NTP ]]
* [[:Media:esp8266_tp_meteo_dht11.pdf | TP station météo avec le DHT11 ]]
<hr>
<div align="center">Raspberry / Banana / Orange Pi</div>
<hr>
* [[iso_install_sdcard | Installation d'une image ]]
* [[pi_java_install | Mise en place de Java ]]
* [[sbc_qemu_emulation | Émulation avec Qemu ]]
* [[Linux sunxi armbian gpio | Manipulation des GPIO sous Linux]]
* [[Linux sunxi armbian w1 | Utilisation du protocole OneWire sous Linux]]
* [[Linux uart sunxi armbian | Utilisation du protocole UART sous Linux]]
<hr>
<div align="center">Notions avancées</div>
<hr>
* Arduino (ATmega328)
** [[atmega328_registers | Manipulation de registres ]]
** [[atmega328_timers | Les timers ]]
|
<hr>
<div align="center">VmWare</div>
<hr>
* [[vmware_install | Installation ]]
* [[vmware_network | La partie réseau ]]
* [[vmware_create_vm | Création d'une machine virtuelle ]]
* [[vmware_debug_vm | Débogage réseau d'une machine virtuelle]]
<hr>
<div align="center">Proxmox</div>
<hr>
* [[proxmox_install | Installation ]]
* [[proxmox_iptables | Utilisation d'iptables ]]
* [[proxmox_fail2ban | Fail2ban ]]
|}
</div>
<div style="visibility:hidden">
__TOC__
</div>
__NOTOC__

DHCP

2025-12-21T16:15:12Z

Jc.forton :

{|border=1 class="wikitable"
! !! Client !! Serveur
|-align="center"
| '''Protocole''' || udp || udp
|-align="center"
| '''Port''' || 68 || 67
|-align="center"
| '''Configuration Iptables''' || X || iptables -I INPUT 2 -p udp --dport 67 -j ACCEPT
|}

= Introduction =

*Dynamic Host Configuration Protocol (DHCP) est un protocole réseau ;

*Défini dans la RFC1531 et présenté pour la première fois en 1993 ;

*Son rôle est d'assurer la configuration automatique des paramètres IP d'une station ;

*DHCP configure l'adresse IP et le masque de la station cliente mais peut également configurer sa passerelle par défaut ainsi que ses serveurs DNS et NBNS (WINS).

* DHCP est arrivé d'un problème : la conception d'IP suppose la configuration de chaque ordinateur connecté sur le réseau ;

* Quasi impossible pour des réseaux de grande taille ;

* Source d'erreur pour les FAI qui possèdent plus de clients que d'adresse IP publique.

= Fonctionnement =

L'ordinateur équipé d'une carte réseau mais dépourvu d'IP :

# Envoie par diffusion un datagramme '''DHCP DISCOVER''' sur le port 67 ;
# Tout serveur en mesure de répondre sur le réseau du client, envoie un datagramme '''DHCP OFFER''' en diffusion sur le port 68 et à destination du client (@MAC) ;
# Le client retient une des offres reçues, et diffuse un datagramme '''DHCP REQUEST''' comportant l'IP du serveur et l'IP retenue ;
# Le serveur DHCP envoie un datagramme '''DHCP ACK''' qui assigne au client l'adresse IP, le masque ainsi que la durée du bail pour cette adresse. C'est ce paquet qui contient les paramètres annexes comme la passerelle, les serveurs DNS, …

= Préparation =

Dans un premier temps, il faudra avoir une connexion à Internet, utiliser un serveur DNS et désactiver SELinux.

Pour ceux qui auraient manqué des étapes, les voici:
* [[resolv.conf|Configuration du client DNS]]
* [[ifcfg-ethX|Paramétrer sa carte réseau]]
* [[SELinux#Changement_d.27.C3.A9tat|Désactiver SELinux]]

Une fois ces étapes effectuées, entrons dans le vif du sujet !

= Installation =
* Sur CentOS 6 et 7
<pre>
# yum -y install dhcp
</pre>
* Sur CentOS 8+ :

<pre>
# dnf -y install dhcp-server
</pre>

= Configuration du service =

Le fichier de configuration du démon DHCP est : /etc/dhcp/dhcpd.conf

<pre>

# Pour spécifier une interface d'écoute
DHCPD_INTERFACE="eth0";

subnet 192.168.50.0 netmask 255.255.255.0 {
# Ce serveur DHCP fait autorité pour ce sous-réseau
authoritative;
# Spécifie le routeur que le client prendra comme passerelle
option routers 192.168.50.254;
# Spécifie un serveur NTP
option ntp-servers 192.168.50.254;
# Le client prendra la chaîne comme suffixe DNS (eg. ping www au lieu de www.tala-informatique.fr)
option domain-name "tala-informatique.fr";
# Spécifie le serveur DNS du réseau
option domain-name-servers 192.168.50.253;
# Utilise cette portion d'IP pour l'attribution d'adresse
# Cette plage doit exclure les adresses spécifiées plus bas pour les hôtes !
range 192.168.50.10 192.168.50.50;

# Durée de conservation du bail
default-lease-time 7200;
max-lease-time 10800;

# DHCP donnera le nom d'hôte (eg. tc1) à la machine
use-host-decl-names on;

host tc1 {
hardware ethernet 00:80:64:1A:E9:14;
fixed-address 192.168.50.1;
# A mettre uniquement si l'option "use-host-decl-names" n'est pas explicitement spécifiée ou à "off"
option host-name "tc1";
}
}
</pre>

= Démarrage et enregistrement dans le chargeur de démarrage =
* Pour SystemVInit:
<pre>
# service dhcpd start
# chkconfig dhcpd on
</pre>
* Pour SystemD :
<pre>
# systemctl start dhcpd.service
# systemctl enable dhcpd.service
</pre>

= Parcours des logs =
{{#lst:Les_logs|log_dhcpd}}
= Mise à jour sécurisée du DNS =

Il est possible de configurer ''dhcpd'' pour qu'il envoie des mises à jour à ''named''

== Configuration de ''dhcpd'' ==

=== Section global ===

Pour cela, il faut ajouter les lignes suivantes au début du fichier:
<pre>
ddns-update-style interim;
ignore client-updates;
update-static-leases on;

key DHCP_DAEMON {
algorithm hmac-md5;
secret "m6y00sQNwZQkQKq92ODj/5iSGIejHKGuURLVxHDE/iM=";
}

zone tala-informatique.fr. {
primary 192.168.200.253;
key DHCP_DAEMON;
}

zone 200.168.192.in-addr.arpa. {
primary 192.168.200.253;
key DHCP_DAEMON;
}
</pre>

La méthode interim est le standard. Le client peut demander au serveur DHCP de mettre à jour le serveur DNS en lui passant ses propres paramètres et le serveur est configuré pour honorer (''allow client-updates'') ou pas la demande du client (''ignore client-updates'')

''ddns-domainname'' et ''ddns-rev-domainname'' permettent de spécifier au serveur DNS de quelle zone il s'agit pour qu'il ajoute les enregistrements de type ''A'' et ''PTR'' dans les bons fichiers de zones.

=== Section ''subnet'' ===

Dans la section subnet il faut ajouter une section ''group'' qui permettra de délimiter les hôtes mis à jour de manière automatique

<pre>
group {
option domain-name "tala-informatique.fr";
ddns-domainname "tala-informatique.fr";

host proxy {
hardware ethernet 00:0C:29:A1:CA:BC;
fixed-address 192.168.200.249;
ddns-hostname "proxy";
}
}
</pre>

== Vérification ==

A chaque mise à jour on peut constater dans ''/var/log/messages''

<pre>
# tail -f /var/log/messages
Dec 27 22:50:47 fw dhcpd: Added new forward map from proxy.tala-informatique.fr to 192.168.200.249
Dec 27 22:50:47 fw dhcpd: added reverse map from 249.200.168.192.in-addr.arpa. to proxy.tala-informatique.fr
Dec 27 22:50:47 fw dhcpd: DHCPREQUEST for 192.168.200.249 from 00:0c:29:a1:ca:bc via eth1
Dec 27 22:50:47 fw dhcpd: DHCPACK on 192.168.200.249 to 00:0c:29:a1:ca:bc via eth1
</pre>

= Relais DHCP =
Quand les machines qui demandent une configuration de niveau 3 OSI ne sont pas sur le même domaine de broadcast que le serveur DHCP, il faut installer un relais DHCP.
[[Fichier:Dhcrelay.png|centré]]
Pour cela, il faut agir sur le routeur en lui ajoutant l'agent de relais DHCP.
== Installation ==
Pour CentOS 6 / 7
<pre>
# yum -y install dhcp
</pre>
Pour CentOS 8+
<pre>
# dnf -y install dhcp-relay
</pre>

== Configuration sur CentOS 6/7 ==
Partons du postulat suivant :
* le serveur DHCP est à l'adresse 192.168.2.250
* le routeur possède les interfaces suivantes: eth0, eth1
Nous allons modifier le fichier ''/etc/sysconfig/dhcrelay'' comme cela :
<pre>
# Command line options here
DHCRELAYARGS=""
# DHCPv4 only
INTERFACES="eth0 eth1"
# DHCPv4 only
DHCPSERVERS="192.168.3.250"
</pre>
Si vous avez plusieurs serveurs DHCP, ajoutez seulement leurs adresses IP séparées par un espace.

== Configuration sur CentOS 8+ ==
Sur CentOS 8 ou ultérieur (eg. Rocky), il faut copier le fichier exemple dans le répertoire des services :
<pre>
cp /lib/systemd/system/dhcrelay.service /etc/systemd/system/
</pre>
Maintenant nous pouvons modifier la ligne suivante :
<pre>
ExecStart=/usr/sbin/dhcrelay -d --no-pid
</pre>

Pour ajouter des options :
<pre>
ExecStart=/usr/sbin/dhcrelay -d --no-pid -i eth0 -i eth1 192.168.3.250
</pre>
Cela mettra le service dhcrelay en écoute sur ''eth0'' et ''eth1'' pour relayer les requêtes au serveur dhcp à l'adresse ''192.168.3.250''.

Comme nous venons d'ajouter un fichier dans le répertoire de systemD, il faut lui demander de recharger sa configuration :
<pre>
# systemctl daemon-reload
</pre>
On peut maintenant enregistrer le service au démarrage et le démarrer :
<pre>
# systemctl enable dhcrelay --now
</pre>

== Démarrage ==
On n'oublie pas de démarrer et d'enregistrer le service dans le gestionnaire de démarrage :
<pre>
# service dhcrelay start
# chkconfig dhcrelay on
</pre>

= DHCP Esclave =
Dans cette section, nous allons nous intéresser à la continuité de service en installant un deuxième serveur DHCP qui agira quand le serveur maître sera indisponible.

Si vous avez déjà configuré votre serveur maître, c'est très bien, nous allons utiliser cette configuration pour le serveur esclave, si vous n'avez pas encore configuré votre serveur maître, retour à la case [[DHCP#Pr.C3.A9paration | départ]] !

== Principe ==
Le serveur maître et le serveur esclave échange sur un port ''TCP'', généralement le 520, leurs informations sur les baux délivré.
Il sont donc synchronisés et peuvent très bien marcher en tandem.

On part du postulat suivant :
* DHCP maître : 192.168.3.251
* DHCP esclave : 192.168.3.250
== Configuration du maître ==
Dans le fichier ''/etc/dhcp/dhcpd.conf'' vous devez mettre le bloc suivante au début, avant les déclarations de ''subnet'':
<pre>
failover peer "dhcp" {
primary;
address 192.168.3.251;
port 520;
peer address 192.168.3.250;
peer port 520;
max-response-delay 60;
max-unacked-updates 10;
mclt 3600;
split 128;
load balance max seconds 3;
}
</pre>
Ensuite, il suffit de faire référence à l'esclave dans chaque déclaration de ''subnet'' que l'on veut redonder:
<pre>
subnet 192.168.3.0 netmask 255.255.255.0 {
authoritative;
pool{
failover peer "dhcp";
option routers 192.168.1.254;

range 192.168.1.10 192.168.1.50;
}
}
</pre>
== Configuration de l'esclave ==
Dans le fichier ''/etc/dhcp/dhcpd.conf'' c'est la même histoire que pour le maître en inversant les IP, en remplaçant ''primary'' par ''secondary'' et en supprimant les informations de balance de charge:
<pre>
failover peer "dhcp" {
secondary;
address 192.168.3.250;
port 520;
peer address 192.168.3.251;
peer port 520;
max-response-delay 60;
max-unacked-updates 10;
mclt 3600;
}
</pre>
Ensuite, il suffit de faire référence à l'esclave dans chaque déclaration de ''subnet'' que l'on à redondé sur le maître ainsi que d'enlever la directive ''authoritative'':
<pre>
subnet 192.168.3.0 netmask 255.255.255.0 {
pool{
failover peer "dhcp";
option routers 192.168.1.254;

range 192.168.1.10 192.168.1.50;
}
}
</pre>
== Iptables ==
N'oublions pas d'ouvrir le port ''TCP'' 520 sur les deux machines:
<pre>
# iptables -I INPUT 2 -p tcp --dport 520 -j ACCEPT
</pre>

== Relais ==
Si vous avez un ''dhcrelay'' sur votre ou vos pares-feu, n'oubliez pas de modifier la directive ''DHCPSERVERS'' pour y ajouter l'adresse de l'esclave !

MediaWiki:Common.js

2025-12-20T18:26:05Z

Jc.forton :

/* Tout JavaScript ici sera chargé avec chaque page accédée par n’importe quel utilisateur. */

MediaWiki:Common.js

2025-12-20T18:24:54Z

Jc.forton :

/* Tout JavaScript ici sera chargé avec chaque page accédée par n’importe quel utilisateur. */
<script src="//unpkg.com/@highlightjs/cdn-assets@11.5.1/languages/cpp.min.js"></script>

Arduino sketch writing

2025-12-20T16:14:09Z

Jc.forton :

= Introduction =
Un sketch est le nom donnée par Arduino aux programmes qui sont téléversés sur un ATMega (cerveau de la carte Arduino).

Comme un programme informatique, le sketch est découpé en plusieurs parties qui ont toutes leur importance.
=Les différentes sections d'un sketch=
== Commentaires ==
{|
|valign="top"|
La première partie d'un sketch est très certainement composée de commentaires. Dans cette introduction, on décrit l'objectif du sketch, l'auteur, sa date de création, le montage électronique qu'il implique, etc...

Ci-contre un exemple de commentaire présent dans le sketch ''blink'' livré avec l'IDE Arduino.
|valign="top"|
<syntaxhighlight lang="c">
/*
Blink
Turns on an LED on for one second, then off for one second, repeatedly.

Most Arduinos have an on-board LED you can control. On the UNO, MEGA and ZERO
it is attached to digital pin 13, on MKR1000 on pin 6. LED_BUILTIN takes care
of use the correct LED pin whatever is the board used.
If you want to know what pin the on-board LED is connected to on your Arduino model, check
the Technical Specs of your board at https://www.arduino.cc/en/Main/Products

This example code is in the public domain.

modified 8 May 2014
by Scott Fitzgerald

modified 2 Sep 2016
by Arturo Guadalupi
*/
</syntaxhighlight>
|}

== Les imports ==
{|
|valign="top"|
Les imports, correspondent à des inclusions de bibliothèques ou librairies et ce font grâce au mot clé ''#include''. En d'autres termes, lorsque vous faites une inclusion, vous ajouter toutes les lignes de code qui composent la bibliothèque en question.

Le problème avec les imports est que l'on à du mal à évaluer la complexité du code qui est appelé. La plus part du temps, on utilise qu'une infime partie des possibilités offertes par certaine bibliothèque très complète. Si c'est le cas et que vous n'avez plus de place pour votre sketch, il est peut-être intéressant d'isoler le code dont on a besoin plutôt que d'utiliser la bibliothèque en entier... la place est limitée sur un ATMega et chaque octet compte !

Ci-contre un exemple d'inclusion de la bibliothèque ''Ethernet''.

|valign="top"|
Cette inclusion fait 1482 lignes de code...
<syntaxhighlight lang="c">
# include "Ethernet.h"
</syntaxhighlight>
|}
== Variables globales ==
{|
|valign="top"|
Les variables globales servent, à l'inverse de leurs homologues locales, à plusieurs endroit dans le sketch. Il peut aussi être intéressant, surtout pour les gros objets, de les faire instancier pendant la phase de démarrage de la puce plutôt que de le faire lors du premier appel. L’intérêt ici n'est pas une utilisation à plusieurs endroit mais un gain de temps.

Ci-contre un exemple de variable globale accessible dans tout le sketch :
|valign="top"|
<syntaxhighlight lang="c">
// Variable statique (portée sketch) et constante (sa valeur ne change pas)
static const char METHOD[] = "GET";
</syntaxhighlight>
|}

== Fonction setup() ==
{|
|valign="top"|
La fonction ''setup()'' est appelée une fois, au démarrage de la puce. C'est généralement ici qu'il faut positionner correctement les broches (en entrée ou en sortie) ainsi que leurs états (haut ou bas).

Lorsque l'on a des conditions qui doivent être satisfaites obligatoirement pour le bon fonctionnement du sketch, il ne faut pas hésiter à utiliser une LED pour montrer à l'utilisateur que le démarrage s'est effectué correctement, un peu comme avec un ''buzzer'' sur une carte mère.

Ci-contre un exemple qui test le bon fonctionnement d'un module HC12 et qui utilise une LED pour signaler à l'utilisateur l'état du système :
|valign="top"|
<syntaxhighlight lang="c">
void setup() {
// Positionnement en sortie des pins
pinMode(ledPin, OUTPUT);
pinMode(setPin, OUTPUT);
// On éteint la LED
digitalWrite(ledPin, LOW);
// passage en mode commande
digitalWrite(setPin, LOW);
// Démarrage de la communication avec le module
hc12.begin(9600);
// On demande au module un acquittement
hc12.print(F("AT+"));
// Délais pour que le module traite la commande
delay(100);
// On attend la réponse du module
while(!hc12.available());
// Le module doit répondre ''OK''
if(strcmp(hc12.readString(), "OK") != 0){
// Quelque chose s'est mal passé...
while(true){
// ... on fait clignoter la LED pour signaler l’erreur !
digitalWrite(ledPin, HIGH);
delay(500);
digitalWrite(ledPin, LOW);
delay(500);
}
}
// passage en mode transparent
digitalWrite(setPin, HIGH);
// on allume la LED de manière fixe pour signaler la fin du setup()
digitalWrite(ledPin, HIGH);
}
</syntaxhighlight>
|}
== Fonction loop() ==
{|
|valign="top"|
La fonction ''loop()'' est le cœur du sketch et peut s'apparenter à un ''while(true)'' dans le sens ou le code à l'intérieur de cette fonction va s’exécuter indéfiniment.

Cette fonction permet de comprendre ce que le sketch est censé faire. Il ne faut pas la surcharger avec un code trop complexe. Il est considéré comme une bonne pratique de fragmenter le code en fonctions et de faire appel à ces fonctions dans ''loop()''.
C'est là tout l'intérêt des fonction annexes !

Ci-contre un exemple de la fonction ''loop()'' de l'exemple ''blink'' :
|valign="top"|
<syntaxhighlight lang="c">
// the loop function runs over and over again forever
void loop() {
digitalWrite(ledPin, HIGH); // turn the LED on (HIGH is the voltage level)
delay(1000); // wait for a second
digitalWrite(ledPin, LOW); // turn the LED off by making the voltage LOW
delay(1000); // wait for a second
}
</syntaxhighlight>
|}
== Fonction annexes ==
{|
|valign="top"|
Les fonctions annexes sont la pour accueillir toute la complexité du code et chacune doit avoir un but précis.

Il ne faut pas hésiter à ''décortiquer'' un code complexe en plusieurs fonctions :
* le code est plus simple ;
* le code gagne en lisibilité ;
* les bugs sont corrigés plus rapidement ;

Ci-contre un exemple tronqué de fonctions annexes servant dans l'élaboration d'un serveur Web avec un module WizNet.

Les fonctions annexes contiennent quelques 300 lignes qui auraient rendu illisible la fonction ''loop()''...
|valign="top"|
<syntaxhighlight lang="c">
void loop() {
// listen for incoming clients
EthernetClient client = server.available();
if (client) {
while (client.connected()) {
if (client.available()) {
char c = client.read();
if (readLine(c)) {
if (readBytes == 0) {
if (isUrl) {
executeRequest(client);
} else {
// Error happened
sendHeader(http_error, client);
client.println();
}
// give the web browser time to receive the data
delay(1);
// close the connection:
client.stop();
} else {
if (!isUrl && readUrl()) {
isUrl = true;
}
}
}
}
}
}
}
/**
Read a line in the HTTP request and put it in a buffer
*/
bool readLine(char c) {
// code de readLine
}
/**
Used to parse the URL and arguments
*/
bool readUrl() {
// code de readUrl
}
/**
Process the HTTP request
*/
bool executeRequest(EthernetClient client) {
// Code de executeRequest
}
/**
Used to send the HTTP header with the given code
*/
void sendHeader(int16_t code, EthernetClient client) {
// code de sendHeader
}
</syntaxhighlight>
|}
== Sketch complet ==
Ci-dessous un sketch qui reprend toutes les section précédentes :
<syntaxhighlight lang="c">
/**
* Sketch d'exemple pour montrer
* l'utilité de chacune des sections
* d'un sketch
*
* @author jcf
*/
#include "Arduino.h"

// Delais de clignotement en ms
static const uint8_t BLINK_DELAY=500;
// Pin sur laquelle est connectée l'anode de la LED
static const uint8_t LED_PIN = 13;

void setup() {
pinMode(LED_PIN, OUTPUT);
digitalWrite(LED_PIN, LOW);
}

void loop() {
blink();
}
/**
* Fait clignoter une led
*/
void blink(){
digitalWrite(LED_PIN, HIGH);
delay(BLINK_DELAY);
digitalWrite(LED_PIN, LOW);
delay(BLINK_DELAY);
}
</syntaxhighlight>

= Le langage C/C++ =
==Les mots clés==
===static===
{|
|valign="top" width="40%"|
Le mot clé [https://en.wikipedia.org/wiki/Static_(keyword) ''static''] possède deux utilités :
* dans une fonction, il permet de garder la valeur de la variable entre deux invocations. Cette technique est intéressante car elle permet de ne pas polluer l'espace global avec des variables utilisées uniquement dans une fonction mais, il faut garder à l'esprit que le code est moins lisible ;
* pour une variable globale ou une fonction cela fixera la portée au niveau fichier (encapsulation).

|valign="top" width="20%"|
Ci-dessous est illustré le premier cas de figure :
<syntaxhighlight lang="c">
void setup(){
Serial.begin(9600);
}

void loop(){
add();
delay(100);
}

void add(){
// instanciation et affectation
static uint8_t i = 0;
// incrémentation
Serial.print(i++);
if(i == 10){
// Remise à zéro
Serial.println(F("."));
i = 0;
}else{
Serial.print(F(", "));
}
}
</syntaxhighlight>
|valign="top" width="10%"|
Le programme précédent affichera indéfiniment la ligne suivante :
<pre>
0, 1, 2, 3, 4, 5, 6, 7, 8, 9.
0, 1, 2, 3, 4, 5, 6, 7, 8, 9.
...
</pre>
|}

===const===
{|
|valign="top" width="55%"|
Le mot clé [https://en.wikipedia.org/wiki/Const_(computer_programming) ''const''] permet de préciser que la valeur d'une variable ne changera pas, à l'instar de son homologue, la variable.

Attention cependant, en ''C'' ''const'' fait partie du type et non de la variable. Ce qui veut dire que le code ci-contre ne fonctionnera pas.

Cette particularité permet au programmeur de spécifier un contrat avec l'appelant. Si la fonction contient le mot clé ''const'', la valeur des variables ou structures passées en paramètre n'est pas modifiée.

Cela fait partie d'un sujet plus vaste qui s'appelle la [https://en.wikipedia.org/wiki/Correctness_(computer_science) ''correction programmatique''].
|valign="top" width="15%"|
<syntaxhighlight lang="c">
void add(uint8_t i);

const uint8_t i = 0;
/**
* Impossible car i est de
* type "const uint8_t" et non "uint8_t"
*/
add(i);
</syntaxhighlight>
|}

===volatile===
{|
|valign="top"|
Le mot clé [https://en.wikipedia.org/wiki/Volatile_(computer_programming) ''volatile''] permet de spécifier si la valeur d'une variable est susceptible d'être modifier entre deux accès. Cela permet de préciser à un compilateur, qui voudrait trop optimiser le code en supprimant des lectures ou écritures en mémoire, de ne pas réutiliser la valeur mais de la relire.

La valeur peut être modifiée par un autre thread (processus) ou par une interruption. L'exemple sur le site [https://www.arduino.cc/en/Reference/AttachInterrupt Arduino], met en exergue ce cas de figure :
<syntaxhighlight lang="c">
const byte ledPin = 13;
// Broche permettant une interruption (bouton, etc...)
const byte interruptPin = 2;
// État de la led à bas
volatile byte state = LOW;

void setup() {
// On configure l'anode en sortie
pinMode(ledPin, OUTPUT);
// On tire la broche du bouton vers le haut (pullup)
pinMode(interruptPin, INPUT_PULLUP);
/**
* On attache une interruption sur la broche du bouton
* Lorsque l'on appuie sur le bouton, la fonction blink est appelée
*/
attachInterrupt(digitalPinToInterrupt(interruptPin), blink, CHANGE);
}

void loop() {
digitalWrite(ledPin, state);
}

void blink() {
state = !state;
}
</syntaxhighlight>
|valign="top"|
On voit bien dans l'exemple précédent que la valeur de la variable ''state'' ne change pas à l'intérieur de la fonction ''loop()'' et cette modification d'état est prise en compte uniquement grâce à ''volatile''.

Il faut garder à l'esprit que le compilateur transforme le code !
*sans ''volatile'':
<syntaxhighlight lang="c">
void loop() {
digitalWrite(13, LOW);
}
</syntaxhighlight>
*avec ''volatile'' :
<syntaxhighlight lang="c">
void loop() {
digitalWrite(13, state);
}
</syntaxhighlight>
|}

==Les types numériques==
{|
|valign="top" width="40%"|
Quand on code en C, il est bon d'utiliser la norme [https://en.wikipedia.org/wiki/C99 C99] qui spécifie plusieurs types numériques de taille fixe. Cette norme à été introduite pour palier les différences qu'il y a entre les compilateurs et les plateformes pour lesquels ils sont écrits (processeur 32bit, microcontrôleur 8bits, etc...) :
*''int8_t'' pour un nombre sur 8 bits (1 octet) ;
*''int16_t'' pour un nombre sur 16 bits (2 octets) ;
*''int32_t'' pour un nombre sur 32 bits (4 octets) ;
*''int64_t'' pour un nombre sur 64 bits (8 octets).

Les types de tailles variables restent disponible :
*''byte'' sur 8 bits (1 octet);
*''int'' sur 16 bits (2 octets) ;
*''short'' sur 16 bits (2 octets) ;
*''float'' sur 32 bits (4 octets) ;
*''double'' sur 32 bits (4 octets) ;
*''long'' sur 32 bits (4 octets) ;

On en arrive à la conclusion suivante, sur ''Arduino'' :
*short = int ;
*float = double;
|valign="top"|
Le sketch ci-dessous permet de s'en rendre compte.
<syntaxhighlight lang="c">
void setup() {
Serial.begin(9600);
Serial.println(F("Types numeriques à taille variable : "));
byte b = 0;
Serial.print(F("byte\t : "));
Serial.println(sizeof(b));
int i = 0;
Serial.print(F("int\t : "));
Serial.println(sizeof(i));
float f = 0;
Serial.print(F("float\t : "));
Serial.println(sizeof(f));
double d = 0;
Serial.print(F("double\t : "));
Serial.println(sizeof(d));
long l = 0;
Serial.print(F("long\t : "));
Serial.println(sizeof(l));
Serial.println(F("Types numeriques à taille fixe (C99): "));
int8_t i8 = 0;
Serial.print(F("uint8_t : "));
Serial.println(sizeof(i8));
int16_t i16 = 0;
Serial.print(F("uint16_t : "));
Serial.println(sizeof(i16));
int32_t i32 = 0;
Serial.print(F("uint32_t : "));
Serial.println(sizeof(i32));
int64_t i64 = 0;
Serial.print(F("uint64_t : "));
Serial.println(sizeof(i64));
}
void loop(){
}
</syntaxhighlight>
|valign="top"|
Il donne le résultat suivant :
<pre>
Types numeriques a taille variable :
int : 2
float : 4
double : 4
long : 4
long long : 4
Types numeriques a taille fixe (C99):
uint8_t : 1
uint16_t : 2
uint32_t : 4
uint64_t : 8
</pre>
|}
Voici les valeurs aux limites des types fixes C99 :
{|border=1
|-
|
|align="center"| int8_t
|align="center"| uint8_t
|align="center"| int16_t
|align="center"| uint16_t
|align="center"| int32_t
|align="center"| uint32_t
|align="center"| int64_t
|align="center"| uint64_t
|-
|min
|align="center"| -128
|align="center"| 0
|align="center"| -32 678
|align="center"| 0
|align="center"| -2 147 483 648
|align="center"| 0
|align="center"| -922 337 203 685 477
|align="center"| 0
|-
|max
|align="center"| 127
|align="center"| 255
|align="center"| 32 677
|align="center"| 65 535
|align="center"| 2 147 483 648
|align="center"| 4 294 967 295
|align="center"| 922 337 203 685 477
|align="center"| 18446744073709551616
|}
Voici les valeurs aux limites des types variables :
{|border=1
|-
|
|align="center"| byte
|align="center"| short/int
|align="center"| unsigned short/int
|align="center"| float/double
|align="center"| long
|align="center"| unsigned long
|-
|min
|align="center"| 0
|align="center"| -32,768
|align="center"| 0
|align="center"| -3.4028235E+38
|align="center"| -2 147 483 647
|align="center"| 0
|-
|max
|align="center"| 255
|align="center"| 32 677
|align="center"| 65 535
|align="center"| 3.4028235E+38
|align="center"| 2 147 483 648
|align="center"| 4 294 967 295
|}

En plus de rendre le programme portable sur plusieurs plateforme, l'utilisation des types fixes permet de minimiser l'espace occupé par les variables en mémoire vive. Cela force le programmeur à réfléchir à la taille des données qu'il va manipuler et, par la même, augmente la robustesse du programme (débordement de tampon, etc...).

==Compilation conditionnelle==
La compilation conditionnelle permet de choisir les lignes de codes qui vont faire partie du programme final en fonction d'assertions.
Celle est particulièrement utile pour modifier le code, par exemple, en fonction du microcontrôleur utilisée (328p-pu, mega2560, etc...).

<syntaxhighlight lang="c">
#if defined(__AVR_ATmega328P__)
// Code du UNO
#elif defined(__AVR_ATmega1280__)
// Code du Mega 1280
#elif defined(__AVR_ATmega2560__)
// Code du Mega 2560
#endif
</syntaxhighlight>

=Les fonctions spécifiques à Arduino=
==Numérique==
===pinMode()===
{|
|valign="top"|
Permet de configurer une broche en entrée ou en sortie.
*[https://www.arduino.cc/en/Reference/PinMode pinMode(pin, mode)]:
**''pin'': la broche à configurer ;
**''mode'': la configuration à appliquer sur la broche. Peut prendre les valeurs ''INPUT'' en entrée, ''OUTPUT'' en sortie ou ''INPUT_PULLUP'' pour tirer l'entrée vers le haut.

Ci-contre un exemple qui met la broche 13 en sortie :
|valign="top"|
<syntaxhighlight lang="c">
void setup(){
pinMode(13, OUTPUT);
}
void loop(){
}
</syntaxhighlight>
|}

===digitalWrite() / digitalRead()===
{|
|valign="top"|
Permet de modifier ou de lire l'état d'une broche.
*[https://www.arduino.cc/en/Reference/DigitalWrite digitalWrite(pin, value)]:
**''pin'' correspond au numéro de la broche
**''value'' correspond soit à la valeur HIGH (3.3v ou 5v) soit à la valeur LOW (0v).
*[https://www.arduino.cc/en/Reference/DigitalRead digitalRead(pin)]:
**''pin'' correspond au numéro de la broche

L'exemple ci-contre fait clignoter la LED présente sur un ''Arduino UNO'':
|valign="top"|
<syntaxhighlight lang="c">
void setup(){
pinMode(13, OUTPUT);
digitalWrite(13, LOW);
}
void loop(){
digitalWrite(13, !digitalRead(13));
delay(1000);
}
</syntaxhighlight>
|}

===pulseIn()===
Permet de mesurer la durée d'une impulsion.
*[https://www.arduino.cc/en/Reference/PulseIn pulseIn(pin, value, timeout)]:
**''pin'' correspond à la broche sur laquelle lire l'impulsion ;
**''value'' correspond au type d'impulsion lue (HIGH ou LOW) ;
**''timeout'' correspond au temps au bout duquel ''pulseIn()'' rend la main si l'impulsion n'est pas observée.
==Analogique==
{|
|valign="top"|
===analogReference()===
Permet de configurer le voltage de référence utilisé pour les entrées analogiques
*[https://www.arduino.cc/en/Reference/AnalogReference analogReference(type)]: ''type'' correspond au type de référence et peut prendre les valeurs suivantes :
**DEFAULT: référence par défaut (3.3v ou 5v)
**INTERNAL: référence interne égale à 1.1v sur l'ATmega168 et ATmega328 et égale à 2.56v sur l'ATmega8
**INTERNAL1V1: référence interne de 1.1V sur le Mega
**INTERNAL2V56: référence interne de 2.56V sur le Mega
**EXTERNAL: référence externe présente sur la broche AREF (entre 0v et 5V uniquement).
===analogWrite() / analogRead()===
Permet de modifier ou de lire l'état d'une broche analogique.
*[https://www.arduino.cc/en/Reference/AnalogWrite analogWrite(pin, value)]:
**pin correspond au numéro de la broche ;
**value correspond à la largeur de l'impulsion envoyée sur la broche ([https://fr.wikipedia.org/wiki/Modulation_de_largeur_d'impulsion Modulation de Largeur d'Impulsion]). La valeur varie entre 0 (toujours éteint) et 255 (toujours allumé) et permet de faire varier l'intensité d'une LED, la vitesse d'un moteur, etc...
Seulement certaine broches permettent d'effectuer cette modulation:
*ATMega168/328 : 3, 5, 6, 9, 10, et 11;
*ATMega1280/2560 : de 2 à 13 et de 44 à 46

*[https://www.arduino.cc/en/Reference/AnalogRead analogRead(pin)]:
**pin correspond au numéro de la broche ;

Ci-contre, un exemple qui fait briller une LED sur la broche [https://www.arduino.cc/en/Tutorial/PWM PWM] numéro 9:
|valign="top"|
<syntaxhighlight lang="c">
uint8_t ledPin = 9;

void setup() {
pinMode(ledPin, OUTPUT);
}

void loop() {
// Entier correspondant à la largeur de l'impulsion
static uint8_t brightness = 0;
// boolean pour savoir si on incrémente ou décrémente la valeur
static bool isFading = false;
if (isFading) {
brightness--;
// Si on arrive à 0, on ne décrémente plus
if (brightness == 0) {
isFading = false;
}
} else {
brightness++;
// Si on arrive à 255, on n'incrémente plus
if (brightness == 255) {
isFading = true;
}
}
// On modifie la largeur de l'impulsion
analogWrite(ledPin, brightness);
// On attend un peu sinon c'est trop rapide
delay(5);
}
</syntaxhighlight>
|}

==Temps==
===millis() / micros()===
Indique le temps qui s'est écoulé depuis le démarrage du microcontrôleur.
* [https://www.arduino.cc/en/Reference/Millis millis()]: résolution de 50 jours, après la valeur repart à zéro (''overflow'')
* [https://www.arduino.cc/en/Reference/Micros micros()]: résolution de 70 minutes, après la valeur repart à zéro (''overflow'')
===delay() / delayMicroseconds()===
Permet de mettre l’exécution du programme en pause pendant le temps désiré.
* [https://www.arduino.cc/en/Reference/Delay delay(unsigned long ms)]: ''ms'' le temps en millisecondes pendant lequel le programme s'arrête.
* [https://www.arduino.cc/en/Reference/DelayMicroseconds delayMicroseconds(unsigned long us)] : ''us'' le temps en micro secondes pendant lequel le programme s'arrête. Cette fonction est précise pour un maximum de 16383 micro secondes, pour des délais plus grand il faut utiliser la fonction ''delay()''.

Attention, ''delayMicroseconds()'' arrête les interruptions avant son travail et repositionne le [https://en.wikipedia.org/wiki/Status_register SREG] (''Status REGister'') après.

==Interruptions==
===attachInterrupt() / detachInterrupt()===
{|
|valign="top" width="60%"|
Permet d'attacher et détacher des interruptions externes. Les interruptions sont des éventements qui arrivent de manière non prédictive et dont on souhaite être prévenu.

Cela peut-être intéressant pour déclencher du code à l'appuie d'un bouton ou encore pour ''réveiller'' l'ATMega.
*[https://www.arduino.cc/en/Reference/AttachInterrupt attachInterrupt(interrupt, ISR, mode)]
**''interrupt'': correspond au numéro d'interruption, en relation avec une broche, généralement déterminé par la fonction ''digitalPinToInterrupt(pin)''. Cependant, il est possible d'utiliser directement le numéro d'interruption, par exemple, la broche deux sur un UNO correspond à l'interruption 0.
**''ISR'': correspond à la ''routine'' (fonction) appelée lorsque l'interruption est levée.
**''mode'': correspond au type d'interruption et peut prendre les valeurs suivantes : LOW (état bas), CHANGE (changement d'état), RISING (état bas vers haut) et FALLING (état haut vers bas).
*[https://www.arduino.cc/en/Reference/DetachInterrupt detachInterrupt(interrupt)]:
**interrupt: correspond au numéro d'interruption, en relation avec une broche, généralement déterminé par la fonction ''digitalPinToInterrupt(pin)''. Cependant, il est possible d'utiliser directement le numéro d'interruption, par exemple, la broche deux sur un UNO correspond à l'interruption 0.

Ci-contre, un code qui permet d'allumer une LED quand on appuie sur un bouton:
|valign="top"|
<syntaxhighlight lang="c">
const uint8_t ledPin = 13;
const uint8_t interruptPin = 2;

void setup() {
pinMode(ledPin, OUTPUT);
pinMode(interruptPin, INPUT_PULLUP);
attachInterrupt(digitalPinToInterrupt(interruptPin), toggle, FALLING);
}

void loop() {}

// Change l'état de la LED
void toggle() {
uint8_t pinState = !digitalRead(ledPin);
digitalWrite(ledPin, pinState);
}
</syntaxhighlight>
|}

===interrupts() / noInterrupts()===
{|
|valign="top" width="50%"|
Permet de désactiver ([https://www.arduino.cc/en/Reference/NoInterrupts noInterrupts]) et réactiver ([https://www.arduino.cc/en/Reference/Interrupts interrupts]) les interruptions qui sont actives par défaut. Cela peut être intéressant pour une portion de code ''critique'' ou l'on ne souhaite pas être dérangé par un événement externe. Il faut garder à l'esprit que l'ATMega fonctionne correctement grâce aux interruptions, il ne faut pas les désactiver trop longtemps !
|valign="top"|
<syntaxhighlight lang="c">
void setup() {}

void loop(){
noInterrupts();
// code sensible ici
interrupts();
// retour à la normale !
}
</syntaxhighlight>
|}

== Cas de l'ESP8266 ==
{|
|valign="top" width="50%"|
Pour la carte ESP8266 il faut préciser, pour les fonctions qui servent de vecteurs d'interruption, qu'elles doivent être stockées dans la mémoire RAM et non la flash grâce au spécificateur ''ICACHE_RAM_ATTR''
|valign="top"|
<syntaxhighlight lang="c">
void ICACHE_RAM_ATTR toggle() {
...
}
</syntaxhighlight>
|}

==Communication==
===Serial===
{|
|valign="top"|
Les communications sur les broches ''Rx'' et ''Tx'' utilise les niveaux logiques [https://fr.wikipedia.org/wiki/Transistor-Transistor_logic TTL] (3.3v ou 5v). Touts les ''Arduino'' possèdent au moins un contrôleur [https://fr.wikipedia.org/wiki/UART UART] qui permet de communiquer avec un périphérique tier (PC, autre Arduino, module radio, etc...).
* [https://www.arduino.cc/en/Reference/Serial Serial(speed)] : ''speed'' correspond à la vitesse du port série et peut prendre différentes valeurs comme ''9600'' ou ''115200''.

Ci-contre un exemple qui utilise le port série :
|valign="top"|
<syntaxhighlight lang="c">
void setup(){
Serial.begin(9600);
Serial.println(F("Hello World"));
}
void loop(){
}
</syntaxhighlight>
|}

=Gestion mémoire sur Arduino=
==Les différents types de mémoires==
{|
|valign="top"|
===La flash===
La mémoire flash est utilisée pour stocker le programme qui va s'exécuter sur l'Arduino. Cette mémoire permet l'exécution du code mais pour pouvoir le modifier il faut d'abord le copier en SRAM. La mémoire flash est non volatile et permet la conservation du programme même en l'absence de source d’énergie mais possède un nombre de cycle d'écriture limité à 100.000.

===La SRAM===
La ''Static Random Access Memory'' ou SRAM, peut être lue et modifiée par le programme en cours d'exécution dans plusieurs buts :
*Les données statiques – Il existe un bloc réservé dans la SRAM pour toutes les données globales et statiques. Pour les variables avec une valeur initiale, le système copie les données de la flash vers la SRAM au démarrage du programme.
*''Heap'' – La ''heap'' sert pour les données dynamiquement allouée et commence à partir des données statique et s’étend au fur et à mesure que des données dynamiques sont allouée.
*''Stack'' – La ''stack'' sert pour les variables locales et pour mémoriser les interruptions et les appels de fonction. Elle grossie du haut de la mémoire vers la ''stack''. Chaque interruption, appel de fonction, allocation de variable locales fait grossir la ''stack'' vers la ''heap''. A la fin de l'interruption ou de l'exécution d'une fonction, l'espace alloué redevient libre.

La plupart des problèmes mémoire surviennent quand la ''heap'' recontre la ''stack''. Lorsque cela survient, les deux mémoires deviennent corrompues ce qui, dans la majorité des cas, se conclu par un crash. Si la collision n'est pas détectée et que l'ATMega ne redémarre pas, le comportement du programme devient erratique.

===l'EEPROM===
L'EEPROM est une autre mémoire non-volatile avec un nombre de cycle d'écriture limité à 100.000. Cette mémoire se lit bit par bit, ce qui peut rendre son utilisation un peu fastidieuse. Elle sert principalement à enregistrer des données de configuration ensuite utilisées par le programme pour modifier son comportement.
|
[[Fichier:Arduino sram diagram.jpg|centré|500px]]
|}

==Architectures mémoire==
===Deux concepts===
Au début de l'ère de l'électronique ont émergé deux types d'architectures mémoire : Harvard et Princeton.
{|align="center" cellspacing="0" style="width:300px border-collapse:collapse"
|-
|
|align="center" style="border:1px solid black"|Harvard
|align="center" style="border:1px solid black"|Princeton (Von Neumann)
|-
|align="center" style="border:1px solid black"|Principe
|style="border:1px solid black"|Utilise deux types d'espaces mémoire : un pour le programme et un pour les données dynamiques.
|style="border:1px solid black"|Utilise un seul espace mémoire pour les programmes et les données dynamiques.
|-
|align="center" style="border:1px solid black"|Avantage
|align="center" style="border:1px solid black"|Rapidité
|align="center" style="border:1px solid black"|Fléxibilité
|}

===Les microcontrôleurs===
Les microcontrôleurs comme l'ATMega sont étudiés pour les applications embarquées et, à l'inverse des ordinateurs de bureau, ont une tâche bien définie qu'ils doivent effectuer de manière sûre et efficace. Le design des microcontrôleur est plutôt spartiate, bien éloigné des mise en cache multicouche ou encore des disques virtuels en mémoire, il se concentre sur ce qui est essentiel à son fonctionnement.

Le modèle Harvard convient tout à fait pour une utilisation dans le domaine de l'embarqué et d’ailleurs, sur un ATMega, on a bien le programme qui est stocké en mémoire flash et les données qui se trouvent en ''SRAM''.

La plupart du temps, le compilateur et le système gèrent ces choses automatiquement mais, quand l'espace commence à devenir exiguë, il est bon de savoir comment les choses se passent ''sous le capot''.
===Différence avec un ordinateur classique===
Les ordinateurs classique, MAC et PC, sont de conception hybride et profitent du meilleur des deux architecture. Au cœur du processeur ont est sur une concpetion Harvard qui compartimente les caches pour les instructions et les données pour maximiser les performance. Cependant ces instructions et données sont chargées d'un espace mémoire commum. Du point de vue du programmeur, cela apparaît comme une architecture ''Von Neumann'' avec plusieurs giga d'espace de stockage mémoire.

La différence la plus flagrante qui existe entre les ordinateurs et les microcontrôleurs est la quantité de mémoire disponible. L'Arduino Uno ne dispose que de 32Ko de mémoire flash et de 2Ko de SRAM ce qui est environ 100.000 fois plus petit qu'un PC bas de gamme !

En travaillant dans un environnement minimaliste, il faut utiliser intelligemment les ressources disponible !

==Mesurer la consommation de SRAM==
{|
|-
|valign="top"|
Lorsqu'on écrit un programme destiné à tourner sur un microcontrôleur comme l'ATMega, l'utilisation de la mémoire est très importante et surtout la détection de fuites !
Le programme peut très bien s'exécuter pendant 1, 2 voire 3 jours puis, d'un coup, plus rien...
Très souvent, les fuites viennent de l'utilisation de fonction d'allocation mémoire comme ''malloc'' ou ''new'' et qui doivent être suivie de ''free'' ou ''delete''.
Le temps de correction d'un bug de ce type est très rapide, encore faut-il s'en rendre compte !

La fonction ci-contre permet de mesurer la quantité de mémoire disponible, c'est à dire, l'espace qui sépare la ''heap'' de la ''stack''.
|valign="top"|
<syntaxhighlight lang="c">
int freeRam () {
extern int __heap_start, *__brkval;
int v;
return (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval);
}
</syntaxhighlight>
|-
|valign="top"|
{|width="90%"
|
Pour suivre l'évolution de la consommation mémoire il faut appeler, de manière régulière, la fonction précédente à des endroits choisi dans le code (là où on pense que la fuite se situe).
|}
Prenons l'exemple suivant :
<syntaxhighlight lang="c">
// Pointeur accessible de manière globale
char* str;
void setup() {
Serial.begin(9600);
printFreeRam();
}
void loop() {
// Affectation d'un tableau de taille 50
str = (char*) malloc(50);
printFreeRam();
delay(200);
}

void printFreeRam () {
extern int __heap_start, *__brkval;
int v;
v = (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval);
Serial.print(F("Free ram : "));
Serial.println(v);
}
</syntaxhighlight>
|valign="top"|

On voit clairement la quantité de mémoire diminuer...
<pre>
Free ram : 1836
Free ram : 1784
Free ram : 1732
Free ram : 1680
Free ram : 1628
</pre>

Si on ajoute la ligne suivante après le ''malloc'' :
<syntaxhighlight lang="c">
free(str);
</syntaxhighlight>
Plus aucun problème.

Il ne faut pas oublier de libérer l'espace réservè en mémoire ou, encore mieux, de reposer sur les des-allocation naturelle du système (en n'utilisant pas ''malloc'' ou ''new'').

De plus, il ne faut pas oublier qu'utiliser trop l'allocation dynamique conduit à la fragmentation de la ''heap''...
|}

==Limiter l'utilisation de la mémoire==
===Mémoire Flash===
{|
|-
|valign="top"|
Lorsque le programme est conséquent, par exemple à cause de l'import de libraires, la mémoire flash commence à manquer cruellement. Il n'y a pas vraiment de miracle mais, suivre les préceptes suivants peut aider :
*Utiliser des fonctions : lorsque c'est possible, il faut essayer de factoriser le code qui se répète dans des fonctions. En plus d'augmenter la lisibilité, cela permet de faciliter la correction de bug.
*Supprimer le code mort : le plus compliqué, dans des programmes de plusieurs millier de lignes, c'est de s’apercevoir du code qui ne sert plus.
*Supprimer le ''bootloader'' : quand on à atteint les limites et que plus aucune optimisation n'est possible, il faut penser à supprimer le ''bootloader''. Cela va permettre à votre programme de s'exécuter plus rapidement mais il n'est plus possible d'utiliser l'Arduino tel quel, il faut utiliser un Arduino ISP (In-System Programer) comme celui ci-contre.
|
[[Fichier:Arduino isp.jpg|centré|250px]]
|}

===Mémoire flash et PROGMEM===

C socket

2025-12-20T16:13:30Z

Jc.forton :

= Introduction =
{|
|-
||
Les sockets permettent de connecter deux programmes qui s'exécutent sur deux machines différentes. Cette connexion se fait à travers le réseau grâce à l'utilisation d'un port (TCP ou UDP) et d'une adresse IP.

Il y a deux types de sockets, une qui est démarrée par la partie serveur en ''écoute'' et l'autre démarrée par la partie cliente qui se connecte à la première.

Ci-contre une image résumant les différentes étapes pour arriver à l'envoi de données.
||
[[Fichier:Socket workflow.png|centré|200px]]
|}

= Création =
== Côté serveur ==
Tout d'abord il faut créer l'objet socket:
<syntaxhighlight lang="c">
#include <sys/socket.h>
#include <netinet/in.h>

int socket(int domain, int type, int protocol)
</syntaxhighlight>
*domain → integer, communication domain e.g., AF_INET (IPv4 protocol) , AF_INET6 (IPv6 protocol)
*type → type de communication
**SOCK_STREAM: TCP
**SOCK_DGRAM: UDP
**SOCK_RAW: socket à l'état brut (bas niveau)
*protocol → valeur du champ ''protocol'' de l'en-tête de niveau 3 (généralement ''0'')
*la valeur de retour est le fichier descripteur de la socket ou ''-1'' en cas d'erreur (''errno'' est positionnée)

Une fois le descripteur de socket créé, il est possible de le configurer:
<syntaxhighlight lang="c">
#include <sys/socket.h>
#include <netinet/in.h>

int setsockopt(int sockfd, int level, int optname, const void *optval, socklen_t optlen)
</syntaxhighlight>
* sockfd → le fichier descripteur de la socket;
* level → niveau d'application de l'option (SOL_SOCKET, TCP, UDP, ...);
* optname → le nom de l'option (''SO_REUSEADDR'', ''SO_REUSEPORT'', ''SO_KEEPALIVE'', ...)
* optval, optlen → utilisé pour accéder aux options de la socket;
* le code retour varie entre ''0'' et ''-1'' en cas d'erreur (''errno'' est positionnée)
Il existe plusieurs options de socket, les plus utilisées étant :
* ''SO_REUSEADDR'' → permet de réutiliser l'adresse de la socket tout de suite même si cette dernière est dans l'état ''wait'';
* ''SO_REUSEPORT'' → permet de réutiliser le port de la socket tout de suite même si cette dernière est dans l'état ''wait'';
* ''SO_KEEPALIVE'' → envoie des informations périodiquement pour tester si l'extrémité du tunnel est toujours présente;

Il faut maintenant attacher la socket à un port Internet et une adresse IP:
<syntaxhighlight lang="c">
int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen)
</syntaxhighlight>
* sockfd → le fichier descripteur de la socket;
* addr → une structure symbolisant l'adresse
<syntaxhighlight lang="c">
struct sockaddr_in {
short sin_family; // e.g: AF_INET
unsigned short sin_port; // e.g: htons(3490)
struct in_addr sin_addr; // détaillé ci-dessous
char sin_zero[8]; // '0' habituellement
};
struct in_addr {
unsigned long s_addr; // initialiser avec inet_aton()
};
</syntaxhighlight>
* addrlen → la taille de l'objet addr;
* le code retour varie entre ''0'' et ''-1'' en cas d'erreur (''errno'' est positionnée)

On peut maintenant passer la socket en état d'écoute, elle est prête à recevoir des connexions:
<syntaxhighlight lang="c">
int listen(int sockfd, int backlog)
</syntaxhighlight>
* sockfd → le fichier descripteur de la socket;
* backlog → taille maximum de la file d'attente de la socket après laquelle le système répond avec ''ECONNREFUSED'';
* le code retour varie entre ''0'' et ''-1'' en cas d'erreur (''errno'' est positionnée)

On peut maintenant attendre une connexion:
<syntaxhighlight lang="c">
int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
</syntaxhighlight>
* sockfd → le fichier descripteur de la socket;
* addr → l'adresse du client;
* addrlen → la taille de la structure addr;
* le code retour varie entre un entier positif qui correspond au descripteur de la socket cliente et ''-1'' en cas d'erreur (''errno'' est positionnée)

== Côté client ==
Après avoir créé la socket avec ''socket'' on peut se connecter à la partie serveur:
<syntaxhighlight lang="c">
int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen);
</syntaxhighlight>
* sockfd → le fichier descripteur de la socket;
* addr → une structure symbolisant l'adresse (cf. ci-dessus)
* addrlen → la taille de l'objet addr;
* le code retour varie entre ''0'' et ''-1'' en cas d'erreur (''errno'' est positionnée)

= Lecture / écriture =
== Fonctions génériques ==
Tout d'abord, on peut dire que la socket est un fichier et se manipule donc comme un fichier !
===Lecture===
Pour lire dans une socket on peut utiliser ''read'':
<syntaxhighlight lang="c">
#include <unistd.h>

ssize_t read(int fd, void *buf, size_t count);
</syntaxhighlight>
* sockfd → le fichier descripteur de la socket;
* buf → le tableau de caractères où mettre le message reçu;
* count → le nombre de caractères à recevoir;
* le code retour correspond au nombre de caractères reçus ou ''-1'' si une erreur survient (errno est positionné);

===Écriture===
Pour écrire dans une socket ou peut utiliser ''write'':
<syntaxhighlight lang="c">
#include <unistd.h>

ssize_t write(int fd, const void *buf, size_t count);
</syntaxhighlight>
* sockfd → le fichier descripteur de la socket;
* buf → le tableau de caractères contenant le message à envoyer;
* count → le nombre de caractères à envoyer;
* le code retour correspond au nombre de caractères envoyés ou ''-1'' si une erreur survient (errno est positionné);

===Modification===
Pour modifier un descripteur fichier de socket on utilise ''fcntl'':
<syntaxhighlight lang="c">
#include <unistd.h>
#include <fcntl.h>

int fcntl(int fd, int cmd, ... /* int args */ );
</syntaxhighlight>
* sockfd → le fichier descripteur de la socket;
* cmd → la commande de modification (descripteur, drapeaux, ...);
* args → les arguments correspondant à la commande

Cette commande va nous permettre de modifier le drapeau du descripteur de la socket (''F_SETFL'') pour le rendre non bloquant (''O_NONBLOCK'') !

== Fonctions spécifiques ==
Il existe des fonctions spécifiques pour manipuler les sockets. Ces fonctions ressemblent aux précédentes mais acceptent des drapeaux en plus pour pouvoir modifier le descripteur ''à la volée''.
===Lecture===
Pour lire dans une socket on peut utiliser ''recv'':
<syntaxhighlight lang="c">
#include <unistd.h>

ssize_t recv(int fd, void *buf, size_t count, int flags);
</syntaxhighlight>
* sockfd → le fichier descripteur de la socket;
* buf → le tableau de caractères où mettre le message reçu;
* count → le nombre de caractères à recevoir;
* flags → liste de drapeaux (eg. ''O_NONBLOCK'');
* le code retour correspond au nombre de caractères reçus ou ''-1'' si une erreur survient (errno est positionné);

===Écriture===
Pour écrire dans une socket ou peut utiliser ''send'':
<syntaxhighlight lang="c">
#include <unistd.h>

ssize_t send(int fd, const void *buf, size_t count, int flags);
</syntaxhighlight>
* sockfd → le fichier descripteur de la socket;
* buf → le tableau de caractères contenant le message à envoyer;
* count → le nombre de caractères à envoyer;
* flags → liste de drapeaux (eg. ''MSG_CONFIRM'', ''MSG_DONTWAIT '', ...);
* le code retour correspond au nombre de caractères envoyés ou ''-1'' si une erreur survient (errno est positionné);

= Cas d'utilisation =
== Création ==
Pour commencer, il faut créer le descripteur de fichier:
<syntaxhighlight lang="c">
int fdsocket;
if ((fdsocket = socket(AF_INET, SOCK_STREAM, 0)) == -1) {
printf("Echec de la création: %s\n", strerror(errno));
exit(EXIT_FAILURE);
}
</syntaxhighlight>

== Paramétrage des options ==
Il faut maintenant configurer la réutilisation de l'adresse et du port
<syntaxhighlight lang="c">
int opt = 1;
if (setsockopt(fdsocket, SOL_SOCKET, SO_REUSEADDR | SO_REUSEPORT, &opt, sizeof(opt)) != 0) {
printf("Echec de paramètrage: %s\n", strerror(errno));
exit(EXIT_FAILURE);
}
</syntaxhighlight>

== Attachement ==
On peut maintenant attacher la socket à un port et une adresse:
<syntaxhighlight lang="c">
struct sockaddr_in adresse;

adresse.sin_family = AF_INET;
// Ecoute sur toutes les adresses (INADDR_ANY <=> 0.0.0.0)
adresse.sin_addr.s_addr = INADDR_ANY;
// Conversion du port en valeur réseaux (Host TO Network Short)
adresse.sin_port = htons(8080);

if (bind(fdsocket, (struct sockaddr *) &adresse, sizeof(adresse)) != 0) {
printf("Echec d'attachement: %s\n", strerror(errno));
exit(EXIT_FAILURE);
}
</syntaxhighlight>

== Mise en écoute ==
La socket est prête à passer à l'écoute des connexions des clients:
<syntaxhighlight lang="c">
// Taille de la file d'attente
#define BACKLOG 3

if (listen(fdsocket, BACKLOG) != 0) {
printf("Echec de la mise en écoute: %s\n", strerror(errno));
exit(EXIT_FAILURE);
}
</syntaxhighlight>

== Acceptation des connexions ==
Il est possible d'accepter les nouvelles connexions:
<syntaxhighlight lang="c">
int clientSocket;
// Structure contenant l'adresse du client
struct sockaddr_in clientAdresse;
unsigned int addrLen = sizeof(clientAdresse);
if ((clientSocket = accept(fdsocket, (struct sockaddr *) &clientAdresse, &addrLen)) != -1) {
// Convertion de l'IP en texte
char ip[INET_ADDRSTRLEN];
inet_ntop(AF_INET, &(clientAdresse.sin_addr), ip, INET_ADDRSTRLEN);
printf("Connexion de %s:%i\n", ip, clientAdresse.sin_port);
}
</syntaxhighlight>
Il est possible d'utiliser ''fcntl'' pour passer le descripteur de la socket en non bloquant, avant l'appel à la fonction ''accept''. Si le descripteur reste bloquant, la fonction ''accept'' ne rendra pas la main tant qu'un client ne se sera connecté, ayant pour résultat le blocage complet du programme !
<syntaxhighlight lang="c">
// Passage en mode non bloquant
fcntl(fdsocket, F_SETFL, O_NONBLOCK);
</syntaxhighlight>
On peut remarquer, au passage, l'utilisation de ''inet_ntop'' pour convertir l'adresse du client du format binaire au format text.

== Lecture / Écriture ==
=== Mode connecté (TCP) ===
On peut maintenant utiliser le descripteur de la socket du client pour lire et écrire.
* avec les fonctions génériques:
<syntaxhighlight lang="c">
#define BUFFER_LEN 200
// Descripteur de la socket du client
int clientSocket;
char buffer[BUFFER_LEN];
// Passage en mode non bloquant, sinon read attend
fcntl(clientSocket, F_SETFL, O_NONBLOCK);
int len = read(clientSocket, buffer, BUFFER_LEN);

write(clientSocket, "Coucou\n", strlen("Coucou\n"));
</syntaxhighlight>
* avec les fonctions spécifiques:
<syntaxhighlight lang="c">
#define BUFFER_LEN 200
// Descripteur de la socket du client
int clientSocket;
char buffer[BUFFER_LEN];

int len = recv(clientSocket, buffer, BUFFER_LEN, MSG_DONTWAIT);

send(clientSocket, "Coucou\n", strlen("Coucou\n"), MSG_DONTWAIT);
</syntaxhighlight>

Analysons le retour de la fonction ''read'' ou ''recv'' lorsque l'on utilise un descripteur non bloquant d'après la [http://man7.org/linux/man-pages/man2/recvmsg.2.html documentation] :
<pre>
NAME
recv, recvfrom, recvmsg - receive a message from a socket
[...]
MSG_DONTWAIT (since Linux 2.2)
Enables nonblocking operation; if the operation would block, the call fails with the error EAGAIN or EWOULDBLOCK (this can also be enabled using the O_NONBLOCK flag with the F_SETFL fcntl(2)).
[...]
RETURN VALUE
[...]
These calls return the number of bytes received, or -1 if an error
occurred. In the event of an error, errno is set to indicate the
error.
When a stream socket peer has performed an orderly shutdown, the
return value will be 0 (the traditional "end-of-file" return).
[...]
</pre>
Le retour est :
* lorsque le descripteur est vide (aucune donnée de la part du client) ''-1'' et ''errno'' sera positionné à la valeur ''EAGAIN'', il ne faut donc pas fermer la socket si le retour est ''-1'' ! Il faut d'abord vérifier que ''errno'' '''n'a pas''' la valeur ''EAGAIN'';
* lorsque le retour est ''0'', cela signifie que l'extrémité est fermée, il faut donc fermer le descripteur local;
* lorsque la valeur est supérieure à ''0'' elle correspond au nombre d'octets reçus.

On peut donc en déduire le morceau de code suivant pour gérer le retour de ''read'' ou ''recv'':
<syntaxhighlight lang="c">
int len = recv(clientSocket, buffer, BUFFER_LEN, MSG_DONTWAIT);

if (len == -1 && errno != EAGAIN) {
// Une erreur est survenue
} else if (len == 0) {
// Le client s'est déconnecté (extrémité de la socket fermée)
} else if (len > 0) {
// Le client à envoyé des données
}
</syntaxhighlight>

=== Mode datagramme (UDP) ===
===Lecture===
Pour lire dans une socket on peut utiliser ''recvfrom'':
<syntaxhighlight lang="c">
#include <unistd.h>

ssize_t recvfrom(int fd, void *buf, size_t count, int flags, const struct sockaddr *addr, socklen_t addrlen);
</syntaxhighlight>
* sockfd → le fichier descripteur de la socket;
* buf → le tableau de caractères où mettre le message reçu;
* count → le nombre de caractères à recevoir;
* flags → liste de drapeaux (eg. ''O_NONBLOCK'');
* addr → une structure symbolisant l'adresse du client (cf. ci-dessus)
* addrlen → la taille de l'objet addr;
* le code retour correspond au nombre de caractères reçus ou ''-1'' si une erreur survient (errno est positionné);

===Écriture===
Pour écrire dans une socket ou peut utiliser ''sendto'':
<syntaxhighlight lang="c">
#include <unistd.h>

ssize_t sendto(int fd, const void *buf, size_t count, const struct sockaddr *addr, socklen_t addrlen);
</syntaxhighlight>
* sockfd → le fichier descripteur de la socket;
* buf → le tableau de caractères contenant le message à envoyer;
* count → le nombre de caractères à envoyer;
* flags → liste de drapeaux (eg. ''MSG_DONTWAIT '', ...);
* addr → une structure symbolisant l'adresse du client (cf. ci-dessus)
* addrlen → la taille de l'objet addr;
* le code retour correspond au nombre de caractères envoyer ou ''-1'' si une erreur survient (errno est positionné);

= Exemples =
== Serveur TCP ==
Voici un exemple de serveur ''echo'' qui renvoie le message au client. Les connexions utilisent TCP et un simple client comme telnet suffit pour l'utiliser.
<syntaxhighlight lang="c">
#include <unistd.h>
#include <stdio.h>
#include <sys/socket.h>
#include <stdlib.h>
#include <netinet/in.h>
#include <string.h>
#include <errno.h>
#include <arpa/inet.h>
#include <fcntl.h>

// Port d'écoute de la socket
#define PORT 8080
// Adresse d'écoute (toutes les adresses)
#define IP INADDR_ANY
// Taille de la file d'attente
#define BACKLOG 3
// Nombre de connexions clients
#define NB_CLIENTS 2
// Taille du tampon de lecture des messages
#define BUFFER_LEN 200
// Commande pour arrêter le serveur
#define EXIT_WORD "exit"

void initAdresse(struct sockaddr_in * adresse);
int initSocket(struct sockaddr_in * adresse);
int waitForClient(int * serverSocket);
void addClientToTab(int clientSocket, int clients[]);
void manageClient(int clients[]);

int main(void) {
// Création et initialisation du tableau contenant les descripteurs des sockets clients
int clients[NB_CLIENTS];
for (int i = 0; i < NB_CLIENTS; i++) {
clients[i] = -1;
}
// Structure contenant l'adresse
struct sockaddr_in adresse;
initAdresse(&adresse);
// Descripteur de la socket du serveur
int serverSocket = initSocket(&adresse);
int clientSocket;
while (1) {
// Descripteur de la socket du client, on attend une connexion
if ((clientSocket = waitForClient(&serverSocket)) != -1) {
// On ajoute le nouveau client au tableau des descripteurs
addClientToTab(clientSocket, clients);
}
manageClient(clients);
}
return EXIT_SUCCESS;
}
// Initialisation de la structure sockaddr_in
void initAdresse(struct sockaddr_in * adresse) {
(*adresse).sin_family = AF_INET;
(*adresse).sin_addr.s_addr = IP;
(*adresse).sin_port = htons( PORT);
}
// Démarrage de la socket serveur
int initSocket(struct sockaddr_in * adresse) {
// Descripteur de socket
int fdsocket;
// Nombre d'options
int opt = 1;
// Création de la socket en TCP
if ((fdsocket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) == -1) {
printf("Echéc de la création: %s\n", strerror(errno));
exit(EXIT_FAILURE);
}
printf("Création de la socket\n");
// Paramètrage de la socket
if (setsockopt(fdsocket, SOL_SOCKET, SO_REUSEADDR | SO_REUSEPORT, &opt,
sizeof(opt)) != 0) {
printf("Echéc de paramètrage: %s\n", strerror(errno));
exit(EXIT_FAILURE);
}
printf("Paramètrage de la socket\n");
// Attachement de la socket sur le port et l'adresse IP
if (bind(fdsocket, (struct sockaddr *) adresse, sizeof(*adresse)) != 0) {
printf("Echéc d'attachement: %s\n", strerror(errno));
exit(EXIT_FAILURE);
}
printf("Attachement de la socket sur le port %i\n", PORT);
// Passage en écoute de la socket
if (listen(fdsocket, BACKLOG) != 0) {
printf("Echéc de la mise en écoute: %s\n", strerror(errno));
exit(EXIT_FAILURE);
}
// Passage en mode non bloquant
fcntl(fdsocket, F_SETFL, O_NONBLOCK);
printf("Mise en écoute de la socket\n");
return fdsocket;
}
// Attente de connexion d'un client
int waitForClient(int * serverSocket) {
int clientSocket;
// Structure contenant l'adresse du client
struct sockaddr_in clientAdresse;
int addrLen = sizeof(clientAdresse);
if ((clientSocket = accept(*serverSocket, (struct sockaddr*) &clientAdresse,
(socklen_t*) &addrLen)) != -1) {
// Convertion de l'IP en texte
char ip[INET_ADDRSTRLEN];
inet_ntop(AF_INET, &(clientAdresse.sin_addr), ip, INET_ADDRSTRLEN);
printf("Connexion de %s:%i\n", ip, clientAdresse.sin_port);
// Passage en mode non bloquant
int opt = 1;
setsockopt(clientSocket, SOL_SOCKET, SO_KEEPALIVE, &opt, sizeof(1));
}
return clientSocket;
}
// Ajoute les clients au tableau
void addClientToTab(int clientSocket, int clients[]) {
// On vérifie si on à de la place de libre
int found = -1;
for (int i = 0; i < NB_CLIENTS; i++) {
// On cherche de la place
if (clients[i] == -1) {
// On ajoute le client
printf("Ajout du client à l'index %i\n", i);
clients[i] = clientSocket;
// Nouvelle connexion, envoie du message de bienvenu
send(clientSocket, "Entrez 'exit' pour quitter\n", strlen("Entrez 'exit' pour quitter\n"),
MSG_DONTWAIT);
found = 0;
break;
}
}
if (found == -1) {
// On a plus de place de libre
puts("Plus de place, désolé");
close(clientSocket);
}
}
// On traite l'input des clients
void manageClient(int clients[]) {
// Création d'un tampon pour stocker les messages des clients dans la heap
static char buffer[BUFFER_LEN + 1];
for (int i = 0; i < NB_CLIENTS; i++) {
// On vérifie les messages
int clientSocket = clients[i];
if (clientSocket == -1) {
continue;
}
int len = recv(clientSocket, buffer, BUFFER_LEN, MSG_DONTWAIT);
// Booléen pour suivre l'état de la socket
int isClosed = 0;
if (len == -1 && errno != EAGAIN) {
// Une erreur est survenue
printf("Errno [%i] : %s\n", errno, strerror(errno));
isClosed = 1;
} else if (len == 0) {
// Le client s'est déconnecté (extrémité de la socket fermée)
isClosed = 1;
} else if (len > 0) {
// Ajout du terminateur de chaîne
buffer[len] = '\0';
if (strncmp(buffer, EXIT_WORD, 4) == 0) {
// Le client veut se déconnecter
send(clientSocket, "Bye\n", strlen("Bye\n"), 0);
isClosed = 1;
} else {
// On renvoie le texte au client dans un buffer assez grand
int len = strlen("Vous avez dit : ") + strlen(buffer) + 1;
char response[len];
strcpy(response, "Vous avez dit : ");
strcat(response, buffer);
// Un seul envoie permet de ne pas surcharger le réseau
send(clientSocket, response, strlen(response), 0);
}
}
if (isClosed == 1) {
// La socket est fermé ou le client veut quitter le serveur !
printf("Fermeture de la connexion avec le client\n");
// Fermeture de la socket
close(clientSocket);
// On fait de la place dans le tableau
clients[i] = -1;
}
}
}
</syntaxhighlight>

On peut interroger notre serveur avec ''telnet'' (''yum -y install telnet''):
<pre>
# telnet 127.0.0.1 8080
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Entrez 'exit' pour quitter
coucou
Vous avez dit : coucou
</pre>

== Serveur UDP ==
Si on essaie de reproduire le même type de serveur mais cette fois-ci avec une socket en UDP, cela devient beaucoup plus simple. En effet, en UDP, plus besoin de tenir un tableau avec les descripteurs des sockets des clients car... on est en mode déconnecté (datagramme) ! Entendez par là que les clients envoient un message sans attendre de réponse et sans se soucier de savoir si le message est arrivé au serveur.

<syntaxhighlight lang="c">
#include <unistd.h>
#include <stdio.h>
#include <sys/socket.h>
#include <stdlib.h>
#include <netinet/in.h>
#include <string.h>
#include <errno.h>
#include <arpa/inet.h>
#include <fcntl.h>

// Port d'écoute de la socket
#define PORT 8080
// Adresse d'écoute (toutes les adresses)
#define IP INADDR_ANY
// Taille de la file d'attente
#define BACKLOG 3
// Taille du tampon de lecture des messages
#define BUFFER_LEN 200

void initAdresse(struct sockaddr_in * adresse);
int initSocket(struct sockaddr_in * adresse);
void manageClient(int serverSocket);

int main(void) {
// Structure contenant l'adresse
struct sockaddr_in adresse;
initAdresse(&adresse);
// Descripteur de la socket du serveur
int serverSocket = initSocket(&adresse);
while (1) {
// Descripteur de la socket du client, on attend une connexion
manageClient(serverSocket);
}
return EXIT_SUCCESS;
}
// Initialisation de la structure sockaddr_in
void initAdresse(struct sockaddr_in * adresse) {
(*adresse).sin_family = AF_INET;
(*adresse).sin_addr.s_addr = IP;
(*adresse).sin_port = htons( PORT);
}
// Démarrage de la socket serveur
int initSocket(struct sockaddr_in * adresse) {
// Descripteur de socket
int fdsocket;
// Nombre d'options
int opt = 1;
// Création de la socket en UDP
if ((fdsocket = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) == -1) {
printf("Echéc de la création: %s\n", strerror(errno));
exit(EXIT_FAILURE);
}
printf("Création de la socket\n");
// Paramètrage de la socket
if (setsockopt(fdsocket, SOL_SOCKET, SO_REUSEADDR | SO_REUSEPORT, &opt,
sizeof(opt)) != 0) {
printf("Echéc de paramètrage: %s\n", strerror(errno));
exit(EXIT_FAILURE);
}
printf("Paramètrage de la socket\n");
// Attachement de la socket sur le port et l'adresse IP
if (bind(fdsocket, (struct sockaddr *) adresse, sizeof(*adresse)) != 0) {
printf("Echéc d'attachement: %s\n", strerror(errno));
exit(EXIT_FAILURE);
}
printf("Attachement de la socket sur le port %i\n", PORT);
return fdsocket;
}
// On traite l'input des clients
void manageClient(int serverSocket) {
// Création d'un tampon pour stocker les messages des clients
static char buffer[BUFFER_LEN + 1];
// Structure contenant l'adresse du client
struct sockaddr_in clientAdresse;
unsigned int addrLen = sizeof(clientAdresse);
// On vérifie si on a reçu un message
int len = recvfrom(serverSocket, buffer, BUFFER_LEN, MSG_DONTWAIT,
(struct sockaddr*) &clientAdresse, &addrLen);
if (len == -1 && errno != EAGAIN) {
printf("Problème de socket %s\n", strerror(errno));
exit(EXIT_FAILURE);
} else if (len > 0) {
printf("Message reçu de %s:%i\n", inet_ntoa(clientAdresse.sin_addr),
ntohs(clientAdresse.sin_port));
// Ajout du terminateur de chaîne
buffer[len] = '\0';
// On renvoie le texte au client dans un buffer assez grand
len = strlen("Vous avez dit : ") + strlen(buffer) + 1;
char response[len];
strcpy(response, "Vous avez dit : ");
strcat(response, buffer);
// Un seul envoie permet de ne pas surcharger le réseau
sendto(serverSocket, response, strlen(response), MSG_DONTWAIT,
(struct sockaddr*) &clientAdresse, addrLen);
}
}
</syntaxhighlight>
On peut interroger notre serveur avec ''netcat'' (''yum -y install nc''):
<pre>
# nc -u 127.0.0.1 8080
coucou
Vous avez dit : coucou
</pre>

== Cas du multicast ==
Il est intéressant parfois de s'abonner à un groupe multicast pour recevoir des messages.

Pour cela il suffit d'utiliser la structure ''mreq'':
<syntaxhighlight lang="c">
struct ip_mreq mreq;
mreq.imr_multiaddr.s_addr = inet_addr(ip); // ip correspond à l'adresse multicast eg. "235.0.0.1"
mreq.imr_interface.s_addr = htonl(INADDR_ANY); // cette ip correspond à l'adresse locale
</syntaxhighlight>

Il faut ensuite positionner l'option sur le descripteur de fichier de la socket concernée:
<syntaxhighlight lang="c">
if (setsockopt(fdsocket, IPPROTO_IP, IP_ADD_MEMBERSHIP, (char*) &mreq, sizeof(mreq)) < 0) {
printf("Echéc de paramètrage: %s\n", strerror(errno));
exit(EXIT_FAILURE);
}
</syntaxhighlight>

= Notification évènementielle avec epoll =
Depuis la version 2.5 du noyau Linux il est possible d'utiliser une série de fonctions, appartenant à l'espace utilisateur (user-space), permettant de suivre l'état d'un descripteur de fichier.
La différence avec read, recv ou encore recvfrom c'est que l'on va pouvoir surveiller plusieurs descripteurs de fichiers en même temps, laissant le CPU libre pour effectuer autre chose !

== Utilisation ==
Tout d'abord il faut créer un descripteur de fichier de type ''epoll'':
<syntaxhighlight lang="c">
#include <sys/epoll.h>

int epoll_create1(int flags);
</syntaxhighlight>
* flags → EPOLL_CLOEXEC pour éviter les situations de compétition en environnement parallélisé;
* le code retour correspond au descripteur ''epoll'' ou ''-1'' en cas d'erreur (''errno'' est positionnée).

Une fois le descripteur ''epoll'' créé, il faut lui associer un événement:
<syntaxhighlight lang="c">
#include <sys/epoll.h>

int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
</syntaxhighlight>
* epfd → le descripteur ''epoll'' à modifier;
* op → une opération parmi:
** EPOLL_CTL_ADD → pour ajouter un événement sur un descripteur de fichier;
** EPOLL_CTL_MOD → pour modifier un événement sur un descripteur de fichier;
** EPOLL_CTL_DEL → pour supprimer un événement sur un descripteur de fichier;
* fd → un descripteur de fichier à surveiller;
* event → la structure contenant l'événement à surveiller (''EPOLLIN'', ''EPOLLOUT'', EPOLLRDHUP'', ...);
* le code retour varie entre ''0'' en cas de succès ou ''-1'' en cas d'erreur (''errno'' est positionnée).

Voici la structure ''epoll_event'':
<syntaxhighlight lang="c">
#include <sys/epoll.h>

struct epoll_event {
uint32_t events; /* Epoll events */
epoll_data_t data; /* User data variable */
};

typedef union epoll_data {
void *ptr;
int fd;
uint32_t u32;
uint64_t u64;
} epoll_data_t;
</syntaxhighlight>

Enfin, il ne reste plus qu'à ''attendre'' des événements:
<syntaxhighlight lang="c">
#include <sys/epoll.h>

int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);
</syntaxhighlight>
* epfd → le descripteur ''epoll'' à modifier;
* events → un tableau de ''epoll_event contenant les événements;
* maxevents → le nombre maximum d'événements à traiter (selon la taille du tableau);
* timeout → le temps, en millisecondes que la fonction attend:
** ''-1'' → la fonction devient bloquante;
** ''0'' → retourne immédiatement;
** ''> 0'' → attend le nombre de millisecondes spécifiées;
* le code retour correspond au nombre d'événements ou ''-1'' en cas d'erreur (''errno'' est positionnée).

== Améliorations architecturales ==
=== Gestion des utilisateurs===
Tout d'abord, le fait de laisser ''epoll'' gérer les descripteurs de socket nous permet de supprimer le tableau ''clients'' ainsi que la variable ''NB_CLIENTS''. En effet, la référence vers le descripteur est maintenue par ''epoll'' et nous pouvons gérer maintenant un nombre ''illimité'' de clients.

=== Performances ===
La boucle ''while'' de notre serveur consomme énormément de CPU, environ 100% de CPU par client ! On aurait pu utiliser un temporisateur avec ''nanosleep'' pour baisser la consommation CPU entre 5% et 10%...
Le fait de basculer sur une fonction bloquante comme ''epoll_wait'' qui utilise des signaux (interruptions) permet de réduire considérablement la consommation CPU. Gardez à l'esprit qu'il n'y a rien de mieux que les interruptions, la preuve, lorsque l'on fait un ''top'', notre programme a complètement disparu de la liste !

== Modification du serveur ==
Modifions le code du serveur TCP pour y intégrer ''epoll'':
<syntaxhighlight lang="c">
#include <unistd.h>
#include <stdio.h>
#include <sys/socket.h>
#include <stdlib.h>
#include <netinet/in.h>
#include <string.h>
#include <errno.h>
#include <arpa/inet.h>
#include <sys/epoll.h>

// Port d'écoute de la socket
#define PORT 8080
// Adresse d'écoute (toutes les adresses)
#define IP INADDR_ANY
// Taille de la file d'attente
#define BACKLOG 3
// Nombre de connexions clients
#define NB_EVENTS 2
// Taille du tampon de lecture des messages
#define BUFFER_LEN 200
// Commande pour arrêter le serveur
#define EXIT_WORD "exit"

void initAdresse(struct sockaddr_in * adresse);
int initSocket(struct sockaddr_in * adresse);
int waitForClient(int * serverSocket);
void addClientToTab(int * epfd, int * clientSocket);
void manageClient(int * epfd, int * clientSocket);
void addEpollEvent(int * epfd, int * socket);
void delEpollEvent(int * epfd, int * socket);

int main(void) {
// Création du descripteur EPOLL
int epfd = epoll_create1(0);
// Structure contenant les événements EPOLL
struct epoll_event events[NB_EVENTS];
// Structure contenant l'adresse
struct sockaddr_in adresse;
initAdresse(&adresse);
// Descripteur de la socket du serveur
int serverSocket = initSocket(&adresse);
addEpollEvent(&epfd, &serverSocket);
int clientSocket;
while (1) {
int nfds = epoll_wait(epfd, events, NB_EVENTS, -1);
for (int i = 0; i < nfds; i++) {
if (events[i].data.fd == serverSocket) {
if ((clientSocket = waitForClient(&serverSocket)) != -1) {
// On ajoute le nouveau client au tableau des descripteurs
addClientToTab(&epfd, &clientSocket);
}
} else if (events[i].events & EPOLLIN) {
// On a reçu quelque chose
manageClient(&epfd, &events[i].data.fd);
}
}
}
close(serverSocket);
return EXIT_SUCCESS;
}
// Initialisation de la structure sockaddr_in
void initAdresse(struct sockaddr_in * adresse) {
(*adresse).sin_family = AF_INET;
(*adresse).sin_addr.s_addr = IP;
(*adresse).sin_port = htons( PORT);
}
// Démarrage de la socket serveur
int initSocket(struct sockaddr_in * adresse) {
// Descripteur de socket
int fdsocket;
// Nombre d'options
int opt = 1;
// Création de la socket en TCP
if ((fdsocket = socket(AF_INET, SOCK_STREAM, 0)) == -1) {
printf("Echéc de la création: %s\n", strerror(errno));
exit(EXIT_FAILURE);
}
printf("Création de la socket\n");
// Paramètrage de la socket
if (setsockopt(fdsocket, SOL_SOCKET, SO_REUSEADDR | SO_REUSEPORT, &opt,
sizeof(opt)) != 0) {
printf("Echéc de paramètrage: %s\n", strerror(errno));
exit(EXIT_FAILURE);
}
printf("Paramètrage de la socket\n");
// Attachement de la socket sur le port et l'adresse IP
if (bind(fdsocket, (struct sockaddr *) adresse, sizeof(*adresse)) != 0) {
printf("Echéc d'attachement: %s\n", strerror(errno));
exit(EXIT_FAILURE);
}
printf("Attachement de la socket sur le port %i\n", PORT);
// Passage en écoute de la socket
if (listen(fdsocket, BACKLOG) != 0) {
printf("Echéc de la mise en écoute: %s\n", strerror(errno));
exit(EXIT_FAILURE);
}
printf("Mise en écoute de la socket\n");
return fdsocket;
}
// Attente de connexion d'un client
int waitForClient(int * serverSocket) {
int clientSocket;
// Structure contenant l'adresse du client
struct sockaddr_in clientAdresse;
int addrLen = sizeof(clientAdresse);
if ((clientSocket = accept(*serverSocket, (struct sockaddr*) &clientAdresse,
(socklen_t*) &addrLen)) != -1) {
// Convertion de l'IP en texte
char ip[INET_ADDRSTRLEN];
inet_ntop(AF_INET, &(clientAdresse.sin_addr), ip, INET_ADDRSTRLEN);
printf("Connexion de %s:%i\n", ip, clientAdresse.sin_port);
// Passage en mode non bloquant
int opt = 1;
setsockopt(clientSocket, SOL_SOCKET, SO_KEEPALIVE, &opt, sizeof(1));
}
return clientSocket;
}
// Ajoute les clients au tableau
void addClientToTab(int * epfd, int * clientSocket) {
addEpollEvent(epfd, clientSocket);
// Nouvelle connexion, envoie du message de bienvenu
send(*clientSocket, "Entrez 'exit' pour quitter\n",
strlen("Entrez 'exit' pour quitter\n"), MSG_DONTWAIT);
}
// On traite l'input des clients
void manageClient(int * epfd, int * clientSocket) {
// Création d'un tampon pour stocker les messages des clients dans la heap
static char buffer[BUFFER_LEN + 1];
int len = recv(*clientSocket, buffer, BUFFER_LEN, MSG_DONTWAIT);
// Booléen pour suivre l'état de la socket
int isClosed = 0;
if (len == -1 && errno != EAGAIN) {
// Une erreur est survenue
printf("Errno [%i] : %s\n", errno, strerror(errno));
isClosed = 1;
} else if (len == 0) {
// Le client s'est déconnecté (extrémité de la socket fermée)
isClosed = 1;
} else if (len > 0) {
// Ajout du terminateur de chaîne
buffer[len] = '\0';
if (strncmp(buffer, EXIT_WORD, 4) == 0) {
// Le client veut se déconnecter
send(*clientSocket, "Bye\n", strlen("Bye\n"), 0);
isClosed = 1;
} else {
// On renvoie le texte au client dans un buffer assez grand
int len = strlen("Vous avez dit : ") + strlen(buffer) + 1;
char response[len];
strcpy(response, "Vous avez dit : ");
strcat(response, buffer);
// Un seul envoie permet de ne pas surcharger le réseau
send(*clientSocket, response, strlen(response), 0);
}
}
if (isClosed == 1) {
// On enlève la socket des événements EPOLL
delEpollEvent(epfd, clientSocket);
// La socket est fermé ou le client veut quitter le serveur !
printf("Fermeture de la connexion avec le client\n");
// Fermeture de la socket
close(*clientSocket);
}
}
// Ajoute un descripteur de socket aux événements EPOLL
void addEpollEvent(int * epfd, int * socket) {
printf("Ajout de la socket %i dans les événements EPOLL\n", *socket);
// Structure contenant les événements EPOLL
struct epoll_event event;
// Initialisation de la structure
memset(&event, 0, sizeof(struct epoll_event));
// On enregistre la socket du serveur comme descripteur EPOLL
event.data.fd = *socket;
// On surveille les message entrant, la fermeture de la socket
event.events = EPOLLIN | EPOLLRDHUP;
epoll_ctl(*epfd, EPOLL_CTL_ADD, *socket, &event);
}
// Efface un descripteur de socket des événements EPOLL
void delEpollEvent(int * epfd, int * socket) {
printf("Suppression de la socket %i des événements EPOLL\n", *socket);
// Structure contenant les événements EPOLL
struct epoll_event event;
// Initialisation de la structure
memset(&event, 0, sizeof(struct epoll_event));
// On enregistre la socket du serveur comme descripteur EPOLL
event.data.fd = *socket;
// On surveille les message entrant, la fermeture de la socket
event.events = EPOLLIN | EPOLLRDHUP;
epoll_ctl(*epfd, EPOLL_CTL_DEL, *socket, &event);
}
</syntaxhighlight>
Voici ce que l'on peut observer dans la console:
<pre>
Création de la socket
Paramètrage de la socket
Attachement de la socket sur le port 8080
Mise en écoute de la socket
Ajout de la socket 4 dans les événements EPOLL
Connexion de 127.0.0.1:17607
Ajout de la socket 5 dans les événements EPOLL
Suppression de la socket 5 des événements EPOLL
Fermeture de la connexion avec le client
Connexion de 127.0.0.1:18119
Ajout de la socket 5 dans les événements EPOLL
Connexion de 127.0.0.1:18631
Ajout de la socket 6 dans les événements EPOLL
Suppression de la socket 5 des événements EPOLL
Fermeture de la connexion avec le client
</pre>

Nagios

2025-12-20T16:12:06Z

Jc.forton :

= Prérequis =
Dans un premier temps, il faudra avoir une connexion à Internet, utiliser un serveur DNS et désactiver SELinux.

Pour ceux qui auraient manqué des étapes, les voici:
* [[resolv.conf|Configuration du client DNS]]
* [[ifcfg-ethX|Paramétrer sa carte réseau]]
* [[SELinux#Changement_d.27.C3.A9tat|Désactiver SELinux]]

Une fois ces étapes effectuées, assurez-vous d'avoir installé le [[Linux_repository | dépôt EPEL]] car la majeure partie de nos paquets viennent de cette source !

= Installation =
Nagios a besoin d'un serveur web pour fonctionner, ce qui nous donne :
<pre>
yum -y install httpd nagios nagios-plugins-all
</pre>
Avant d'aller plus loin, intéressons-nous au fonctionnement de Nagios.

= Fonctionnement =

== Configuration ==
Plusieurs éléments de configuration sont présents dans Nagios:
===timeperiods===
Elles permettent de fixer les plages de notifications des contacts et de contrôle des hôtes et services.
===contact===
Ceux sont les personnes qu'il faut alerter par la supervision.
===contactgroup===
Ceux sont des groupes de plusieurs ''contact'' qui vont être alertés en même temps. Ceux sont souvent des personnes occupant le même poste (administrateur système, webmestre
, responsable d'exploitation, etc...)
===hosts===
Ils représentent les machines physiques à superviser.
===hostgroup===
Permettent de rassembler plusieurs ''host'' occupant le même rôle ou faisant tourner une même application.
===services===
Ceux sont les contrôles à effectuer sur un ''host'' (DNS, est-ce que le démon SSH tourne ?, % d'utilisation CPU, % d'utilisation mémoire, l’IO disque, ...)
===servicegroup===
Permet de rassembler des services pour les considérer comme un bloc comme c'est souvent le cas dans un cluster applicatif.
===template===
Ils permettent d'éviter les redondances au niveau des définitions d’hôtes et de services en regroupant des variables communes.

[[Fichier:nagios_config_operation.png|centré]]

== Notifications ==
#Au début le service est disponible, le voyant est au vert (état OK)
#Quand le service ne répond plus, Nagios le passe de l’état ''OK'' à ''Warning''. Le service passe en état ''SOFT'', Nagios va déclencher le cycle de vérification de la fiabilité de l’incident (utilisation de retry_check et max_check_attemps)
# Au bout du cycle de vérification, Nagios passe le service en état ''HARD'', l’incident est certifié. Le cycle de notification va commencer (tous les notification_interval).
# Quand le service répond de nouveau, Nagios envoie une dernière notification pour signaler que le service est repassé à l'état ''OK''.

[[Fichier:nagios_service_notification.png|centré]]

== Vérifications distantes ==
Pour assurer des vérifications ''locales'' sur des machines distantes, il faut un moyen d'exécuter les ''plugins'' sur la machine distante. Ce moyen c'est ''NRPE'' pour ''Nagios Remote Plugins Executor''.
[[Fichier:nagios_nrpe_operation.png|centré]]

= Fichiers de configuration =
Commençons par observer le contenu du répertoire ''/etc/nagios/objects'':
<pre>
# ll /etc/nagios/objects
total 48
-rw-rw-r--. 1 root root 7704 31 août 2013 commands.cfg
-rw-rw-r--. 1 root root 2166 31 août 2013 contacts.cfg
-rw-rw-r--. 1 root root 5403 31 août 2013 localhost.cfg
-rw-rw-r--. 1 root root 3124 31 août 2013 printer.cfg
-rw-rw-r--. 1 root root 3293 31 août 2013 switch.cfg
-rw-rw-r--. 1 root root 11158 31 août 2013 templates.cfg
-rw-rw-r--. 1 root root 3208 31 août 2013 timeperiods.cfg
-rw-rw-r--. 1 root root 4019 31 août 2013 windows.cfg
</pre>
== Timeperiods.cfg ==
Dans ce fichier sont déclarés les périodes que nous allons pouvoir utiliser pour la vérification des hôtes ou des services.
Ci-dessous un exemple :
<pre>
define timeperiod{
timeperiod_name 24x7
alias 24 Hours A Day, 7 Days A Week
sunday 00:00-24:00
monday 00:00-24:00
tuesday 00:00-24:00
wednesday 00:00-24:00
thursday 00:00-24:00
friday 00:00-24:00
saturday 00:00-24:00
}
</pre>
On voit qu'une période se définit comme suit :
* ''timeperiod_name'' : identifiant de la période, doit être unique dans toute la configuration de 'Nagios'';
* ''alias'' : appellation longue, permettant de mieux identifier la période;
* ''monday 00:00-24:00'', ''tuesday 00:00-24:00'', ... : les jours de la semaine suivis de l'heure de début et de l'heure de fin.

Pas très compliqué de créer sa propre période. Imaginons que nous voulions une période qui correspond aux lundis matin entre 8h et 9h :
<pre>
define timeperiod{
timeperiod_name week_start
alias Lundi matin de 8h à 9h
monday 08:00-09:00
}
</pre>

== contact.cfg ==
=== Contact ===
Dans ce fichier sont déclarés les contacts qui vont pouvoir être contactés quand un problème surviendra. Ci-dessous un exemple :
<pre>
define contact{
contact_name nagiosadmin ; Short name of user
use generic-contact ; Inherit default values from generic-contact template (defined above)
alias Nagios Admin ; Full name of user
email nagios@localhost ; <<***** CHANGE THIS TO YOUR EMAIL ADDRESS ******
}
</pre>
Si on regarde bien, ce contact utilise un template qui contient les lignes suivantes:
<pre>
define contact{
name generic-contact ; The name of this contact template
service_notification_period 24x7 ; service notifications can be sent anytime
host_notification_period 24x7 ; host notifications can be sent anytime
service_notification_options w,u,c,r,f,s ; send notifications for all service states, flapping events, and scheduled downtime events
host_notification_options d,u,r,f,s ; send notifications for all host states, flapping events, and scheduled downtime events
service_notification_commands notify-service-by-email ; send service notifications via email
host_notification_commands notify-host-by-email ; send host notifications via email
register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL CONTACT, JUST A TEMPLATE!
}
</pre>
Quelques précisions :
* les ''notification_options'' prennent les paramètres suivants :
**w: notification sur les états ''WARNING'';
**u: notification sur les états ''UNKNOWN'';
**c: notification sur les états ''CRITICAL'';
**r: notification quand le service repasse à l'état ''OK'' (''RECOVERY'');
**f: notification quand il y a du ''flapping'' (quand le service démarre et s'arrête sans cesse);
**s: notification quand la période d'arrêt programmée (''SCHEDULED DOWNTIME'') est terminée;
**n: pas de notification (''NONE'').
=== Notifications ===
*les ''notification_commands'' sont déclarées dans le fichier ''/etc/nagios/objects/commands.cfg:
<pre>
# 'notify-host-by-email' command definition
define command{
command_name notify-host-by-email
command_line /usr/bin/printf "%b" "***** Nagios *****\n
\nNotification Type: $NOTIFICATIONTYPE$
\nHost: $HOSTNAME$
\nState: $HOSTSTATE$
\nAddress: $HOSTADDRESS$
\nInfo: $HOSTOUTPUT$
\n\nDate/Time: $LONGDATETIME$\n" | /bin/mail -s "** $NOTIFICATIONTYPE$ Host Alert: $HOSTNAME$ is $HOSTSTATE$ **" $CONTACTEMAIL$
}

# 'notify-service-by-email' command definition
define command{
command_name notify-service-by-email
command_line /usr/bin/printf "%b" "***** Nagios *****\n
\nNotification Type: $NOTIFICATIONTYPE$
\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$
\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$
\n\nDate/Time: $LONGDATETIME$
\n\nAdditional Info:\n\n$SERVICEOUTPUT$\n" | /bin/mail -s "** $NOTIFICATIONTYPE$ Service Alert: $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$
}
</pre>
Ces deux commandes envoient un mail (''/bin/mail'') au contact désigné.
=== Groupe ===
Toujours dans le fichier ''/etc/nagios/objects/contact.cfg'' on peut trouver la déclaration d'un groupe de contact :
<pre>
define contactgroup{
contactgroup_name admins
alias Nagios Administrators
members nagiosadmin
}
</pre>
Dans ce groupe figure uniquement le contact ''nagiosadmin'' mais il est possible d'en ajouter en les séparant par une virgule.

==commands.cfg==
=== Déclaration d'une commande===
Dans ce fichier sont écrites différentes commandes que l'on peut utiliser pour faire des vérifications sur des hôtes.
Ces commandes utilisent des 'plugins' qui se trouvent dans le répertoire ''/usr/lib64/nagios/plugins'' et nous allons plutôt détailler l'usage de ces 'plugins'.

Pour terminer avec ce fichier, nous allons prendre un exemple. Le plugin ''check_procs'', qui permet de vérifier combien de processus tournent sur une machine et utilisé dans le fichier commande comme suit :
<pre>
define command{
command_name check_local_procs
command_line $USER1$/check_procs -w $ARG1$ -c $ARG2$ -s $ARG3$
}
</pre>
Seulement, ce n'est pas la seule façon d'utiliser ''check_procs'', et on peut s'en rendre compte en demandant le ''help'' du 'plugin':
<pre>
# /usr/lib64/nagios/plugins/check_procs -h
</pre>
On peut utiliser l'option ''-u'' pour vérifier si un utilisateur a lancé un processus. Cela peut être pratique si vous voulez vérifier que certain démon fonctionnent, comme par exemple ''ntp'' :
<pre>
# ps -ef | grep ntp | grep -v grep
ntp 10458 1 0 07:55 ? 00:00:00 ntpd -u ntp:ntp -p /var/run/ntpd.pid -g
# ./check_procs -u ntp
PROCS OK: 1 processus avec UID = 38 (ntp)
</pre>
Cependant, la commande ''check_local_procs'' ne permet pas d'utiliser le 'plugin' avec cet argument... Déclarons une nouvelle commande !
<pre>
define command{
command_name check_user_process
command_line $USER1$/check_procs -w $ARG1$ -c $ARG2$ -u $ARG3$
}
</pre>
On laisse les options ''-w'' et ''-c'' pour nous pouvoir mettre des paliers sur le nombre de processus lancés.
Dans le cas d'un serveur Apache, cela peut être intéressant de déclencher des alarmes en fonction du nombre de processus lancés.
En effet, si trop de processus sont démarrés, le serveur est peut-être trop sollicité ou sous en train de subir une attaque DDOS.
On peut de toute façon, passer la valeur ''-1'' à ''-w'' ou ''-c'' pour les désactiver.

===Listes des commandes ===
*notify-host-by-email
*notify-service-by-email
*check-host-alive
*check_local_disk
*check_local_load
*check_local_procs
*check_local_users
*check_local_swap
*check_local_mrtgtraf
*check_ftp
*check_hpjd
*check_snmp
*check_http
*check_ssh
*check_dhcp
*check_ping
*check_pop
*check_imap
*check_smtp
*check_tcp
*check_udp
*check_nt
*process-host-perfdata
*process-service-perfdata

== localhost.cfg ==
===Définition d'un hôte===
Au début du fichier, on trouve la déclaration de l'hôte:
<pre>
define host{
use linux-server ; Name of host template to use
host_name localhost
alias localhost
address 127.0.0.1
}
</pre>
On peut remarquer que cette déclaration utilise le template ''linux-server'':
<pre>
define host{
name linux-server ; The name of this host template
use generic-host ; This template inherits other values from the generic-host template
check_period 24x7 ; By default, Linux hosts are checked round the clock
check_interval 5 ; Actively check the host every 5 minutes
retry_interval 1 ; Schedule host check retries at 1 minute intervals
max_check_attempts 10 ; Check each Linux host 10 times (max)
check_command check-host-alive ; Default command to check Linux hosts
notification_period workhours ; Linux admins hate to be woken up, so we only notify during the day
notification_interval 120 ; Resend notifications every 2 hours
notification_options d,u,r ; Only send notifications for specific host states
contact_groups admins ; Notifications get sent to the admins by default
register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL HOST, JUST A TEMPLATE!
}
</pre>
Qui lui-même utilise le template ''generic-host'':
<pre>
define host{
name generic-host ; The name of this host template
notifications_enabled 1 ; Host notifications are enabled
event_handler_enabled 1 ; Host event handler is enabled
flap_detection_enabled 1 ; Flap detection is enabled
failure_prediction_enabled 1 ; Failure prediction is enabled
process_perf_data 1 ; Process performance data
retain_status_information 1 ; Retain status information across program restarts
retain_nonstatus_information 1 ; Retain non-status information across program restarts
notification_period 24x7 ; Send host notifications at any time
register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL HOST, JUST A TEMPLATE!
}
</pre>

=== Définition des services ===
Plus loin dans le fichier, nous pouvons voir la déclaration des services. Les services utilisent quatre paramètres:
* un ''template' ;
* un ''host'' ;
* une description ;
* une commande.
<pre>
define service{
use local-service ; Name of service template to use
host_name localhost
service_description Root Partition
check_command check_local_disk!20%!10%!/
}
</pre>
On peut remarquer que cette déclaration utilise le template ''local-service'':
<pre>
define service{
name local-service ; The name of this service template
use generic-service ; Inherit default values from the generic-service definition
max_check_attempts 4 ; Re-check the service up to 4 times in order to determine its final (hard) state
normal_check_interval 5 ; Check the service every 5 minutes under normal conditions
retry_check_interval 1 ; Re-check the service every minute until a hard state can be determined
register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE!
}
</pre>
Qui lui même utilise le template ''generic-host'':
<pre>
define service{
name generic-service ; The 'name' of this service template
active_checks_enabled 1 ; Active service checks are enabled
passive_checks_enabled 1 ; Passive service checks are enabled/accepted
parallelize_check 1 ; Active service checks should be parallelized (disabling this can lead to major performance problems)
obsess_over_service 1 ; We should obsess over this service (if necessary)
check_freshness 0 ; Default is to NOT check service 'freshness'
notifications_enabled 1 ; Service notifications are enabled
event_handler_enabled 1 ; Service event handler is enabled
flap_detection_enabled 1 ; Flap detection is enabled
failure_prediction_enabled 1 ; Failure prediction is enabled
process_perf_data 1 ; Process performance data
retain_status_information 1 ; Retain status information across program restarts
retain_nonstatus_information 1 ; Retain non-status information across program restarts
is_volatile 0 ; The service is not volatile
check_period 24x7 ; The service can be checked at any time of the day
max_check_attempts 3 ; Re-check the service up to 3 times in order to determine its final (hard) state
normal_check_interval 10 ; Check the service every 10 minutes under normal conditions
retry_check_interval 2 ; Re-check the service every two minutes until a hard state can be determined
contact_groups admins ; Notifications get sent out to everyone in the 'admins' group
notification_options w,u,c,r ; Send notifications about warning, unknown, critical, and recovery events
notification_interval 60 ; Re-notify about service problems every hour
notification_period 24x7 ; Notifications can be sent out at any time
register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE!
}
</pre>

= Configuration =
Les ajouts de configuration se font dans le répertoire ''/etc/nagios/conf.d''.
== Hôtes ==
Dans cet exemple, nous considérerons un serveur DHCP à l'adresse ''192.168.3.251''. Les lignes de configuration seront écrites dans le fichier ''/etc/nagios/conf.d/sdhcpd.conf''
===Déclaration de l'hôte===
<pre>
define host{
use linux-server
host_name dhcp.tala-informatique.fr
alias sdhcpd
address 192.168.3.251
}
</pre>

===Vérifications externes ===
Dans un premier temps, nous allons déclarer des vérifications externes qui ne nécessitent aucune intervention sur la machine à surveiller.
<pre>
## SERVICE DEFINITION ##
define service{
use local-service
host_name dhcp.tala-informatique.fr
service_description Host alive
check_command check-host-alive
}
define service{
use local-service
host_name dhcp.tala-informatique.fr
service_description Check dhcpd
check_command check_dhcp
}
</pre>
Pour que ''check_dhcp'' fonctionne, n'oubliez pas d'ouvrir le pare-feu :
<pre>
# iptables -I INPUT 2 -p udp --dport 68 -j ACCEPT
</pre>
= Pre fly check =
Avant de démarrer ''Nagios'', il est intéressant de faire une vérification de la configuration pour voir s'il n'y a pas d'erreur:
<pre>
# nagios -v /etc/nagios/nagios.cfg

Nagios Core 3.5.1
Copyright (c) 2009-2011 Nagios Core Development Team and Community Contributors
Copyright (c) 1999-2009 Ethan Galstad
Last Modified: 08-30-2013
License: GPL

Website: http://www.nagios.org
Reading configuration data...
Read main config file okay...
Processing object config file '/etc/nagios/objects/commands.cfg'...
Processing object config file '/etc/nagios/objects/contacts.cfg'...
Processing object config file '/etc/nagios/objects/timeperiods.cfg'...
Processing object config file '/etc/nagios/objects/templates.cfg'...
Processing object config file '/etc/nagios/objects/localhost.cfg'...
Processing object config directory '/etc/nagios/conf.d'...
Processing object config file '/etc/nagios/conf.d/www.cfg'...
Processing object config file '/etc/nagios/conf.d/sdhcpd.cfg'...
Read object config files okay...

Running pre-flight check on configuration data...

Checking services...
Checked 11 services.
Checking hosts...
Checked 3 hosts.
Checking host groups...
Checked 1 host groups.
Checking service groups...
Checked 0 service groups.
Checking contacts...
Checked 1 contacts.
Checking contact groups...
Checked 1 contact groups.
Checking service escalations...
Checked 0 service escalations.
Checking service dependencies...
Checked 0 service dependencies.
Checking host escalations...
Checked 0 host escalations.
Checking host dependencies...
Checked 0 host dependencies.
Checking commands...
Checked 24 commands.
Checking time periods...
Checked 5 time periods.
Checking for circular paths between hosts...
Checking for circular host and service dependencies...
Checking global event handlers...
Checking obsessive compulsive processor commands...
Checking misc settings...

Total Warnings: 0
Total Errors: 0

Things look okay - No serious problems were detected during the pre-flight check
</pre>
=Démarrage =
Une fois la configuration terminée, on démarre ''Nagios'' et on l'enregistre dans le chargeur de démarrage:
* Pour SystemVInit:
<pre>
service nagios start
chkconfig nagios on
</pre>
* Pour SystemD:
<pre>
systemctl start nagios.service
systemctl enable nagios.service
</pre>

=Accès Web=
== Accès administrateur ==
Pour accéder à l'interface Web de ''Nagios'', il faut avant tout paramétrer un mot de passe et autoriser l'accès depuis une autre machine que ''127.0.0.1'':
Cela se passe dans le fichier ''/etc/httpd/conf.d/nagios.conf'', où il faut commenter les lignes suivantes:
<pre>
# Order deny,allow
# Deny from all
# Allow from 127.0.0.1
</pre>
Maintenant, il ne nous reste plus qu'à définir un mot de passe:
<pre>
# htpasswd /etc/nagios/passwd nagiosadmin
New password:
Re-type new password:
Updating password for user nagiosadmin
</pre>
Une fois que vous avez configuré et démarré [[HTTPD#Configuration_de_base | HTTPD]], vous avez accès à l’interface Web:
[[Fichier:Web interface nagios intro.png|centré]]

== Autres accès ==
Si vous décidez de créer d'autres utilisateurs que ''nagiosadmin'', il faudra leur donner accès à certaines informations.
Cela se passe dans le fichier ''/etc/nagios/cgi.conf'':
<pre>
use_authentication=1
#edit username
authorized_for_all_host_commands=username
authorized_for_all_hosts=username
authorized_for_all_service_commands=username
authorized_for_all_services=username
authorized_for_configuration_information=username
authorized_for_system_commands=username
authorized_for_system_information=username
</pre>
Il suffit d'ajouter les noms d'utilisateurs séparés d'une virgule.
=NRPE : vérifications locales sur hôte distant =
Les vérifications externes sont très intéressantes mais, malheureusement, pas suffisantes pour garantir le bon fonctionnement d'un hôte.

Pour faire des vérifications locales sur un hôte distant, nous allons utiliser ''NRPE'' sur le serveur ''DHCP''.
== Installation ==
Pour faire des vérifications sur des machines distantes (autre que le serveur ''Nagios''), il faut installer le module ''NRPE'' sur ces machines:
<pre>
# yum -y install nrpe nagios-plugins-all
</pre>

On n'oublie pas d'ouvrir le pare-feu:
<pre>
# iptables -I INPUT 2 -p tcp --dport 5666 -j ACCEPT
</pre>

== Configuration ==
=== Autorisation ===
Nous allons modifier son fichier de configuration ''/etc/nagios/nrpe.cfg'' pour y ajouter l'adresse du serveur ''Nagios'':
<pre>
allowed_hosts=127.0.0.1, 192.168.3.242
</pre>
=== Commandes ===
À la fin du fichier on peut voir les commandes qui sont déclarées :
<pre>
command[check_users]=/usr/lib64/nagios/plugins/check_users -w 5 -c 10
command[check_load]=/usr/lib64/nagios/plugins/check_load -w 15,10,5 -c 30,25,20
command[check_hda1]=/usr/lib64/nagios/plugins/check_disk -w 20% -c 10% -p /dev/hda1
command[check_zombie_procs]=/usr/lib64/nagios/plugins/check_procs -w 5 -c 10 -s Z
command[check_total_procs]=/usr/lib64/nagios/plugins/check_procs -w 150 -c 200
</pre>
On peut modifier ''check_hda1'' en :
<pre>
command[check_sda]=/usr/lib64/nagios/plugins/check_disk -w 20% -c 10% -p /dev/sda
</pre>
== Démarrage ==
Maintenant on peut démarrer ''NRPE'':
<pre>
# service nrpe start
</pre>
Et on l'enregistre dans le chargeur de démarrage:
<pre>
# chkconfig nrpe on
</pre>

== Intégration dans ''Nagios'' ==
=== Installation du plugin ===
De retour sur le serveur ''Nagios'', nous allons tout d'abord installer le plugin ''NRPE'':
<pre>
# yum -y install nagios-plugins-nrpe
</pre>
== Test de connectivité ==
Toujours sur le serveur ''Nagios'', pour être sûr que la connectivité est bonne, on peut utiliser le plugin:
<pre>
# /usr/lib64/nagios/plugins/check_nrpe -H 192.168.3.251
NRPE v2.15
</pre>
Pourquoi pas une commande:
<pre>
# /usr/lib64/nagios/plugins/check_nrpe -H 192.168.3.251 -c check_sda
DISK OK - free space: / 5472 MB (85% inode=95%);| /=947MB;5410;6086;0;6763
</pre>
Tout semble fonctionner, intégrons cela à la configuration !
=== Modification de la configuration ===
Tout d'abord, il faut ajouter une commande soit dans le fichier ''/etc/nagios/objects/commands.cfg'' soit dans le fichier ''/etc/nagios/conf.d/nrpe_plugin.cfg'' :
<pre>
#######################################################
#
# Ajout pour NRPE
#
#######################################################
define command{
command_name check_nrpe
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}
</pre>
Nous pouvons maintenant modifier le fichier ''/etc/nagios/conf.d/sdhcp.cfg'' pour prendre en compte ces vérifications :
<pre>
define service{
use local-service
host_name dhcp.tala-informatique.fr
service_description Check users
check_command check_nrpe!check_users
}
define service{
use local-service
host_name dhcp.tala-informatique.fr
service_description Check disk /dev/sda
check_command check_nrpe!check_sda
}
define service{
use local-service
host_name dhcp.tala-informatique.fr
service_description Check load
check_command check_nrpe!check_load
}
define service{
use local-service
host_name dhcp.tala-informatique.fr
service_description Check zombies
check_command check_nrpe!check_zombie_procs
}
define service{
use local-service
host_name dhcp.tala-informatique.fr
service_description Check total process
check_command check_nrpe!check_total_procs
}
</pre>
Si on retourne sur l'interface Web, on peut observer ces nouvelles vérifications:
[[Fichier:Nagios check nrpe web.png|centré]]

= Développement d'un plugin =
Que faire lorsque rien ne permet de vérifier ce que vous voulez vérifier ?

Pas de panique, il suffit de développer son propre plugin. Avant d'aller plus loin, intéressons-nous au fonctionnement des plugins :
* les plugins renvoient trois états : 0 = OK ; 1 = WARNING ; 2 = CRITICAL
* les plugins peuvent renvoyer '''une''' (1) ligne de retour

Développons un script pour retourner le nombre de machines qui ont eu une adresse IP dans la journée.
== La date ==
Sur nos machines françaises la date est la suivante :
<pre>
# date
Thu Jan 14 04:28:04 CET 2016
</pre>
Or, dans le ''/var/log/message'', la date est formatée comme suit :
<pre>
Jan 14 00:54:08 dhcp dhcpd: added reverse map from 242.3.168.192.in-addr.arpa. to nagios.tala-informatique.fr
</pre>
Les mois ne correspondent pas... Il faut changer de langue pour que les mois s'affichent comme dans le ''/var/log/message''
<pre>
# LC_ALL=en_US.utf8
# export LC_ALL
# date
Thu Jan 14 04:28:04 CET 2016
# date +"%b %d"
Jan 14
</pre>
On a la date du jour, maintenant filtrons les entrées qui concernent le serveur dhcpd:
<pre>
# cat /var/log/message | grep "$(date +"%b %d")" | grep dhcpd | grep DHCPACK
Jan 14 00:17:12 dhcp dhcpd: DHCPACK on 192.168.3.242 to 00:0c:29:32:07:4a via eth0
Jan 14 00:54:08 dhcp dhcpd: DHCPACK on 192.168.3.242 to 00:0c:29:32:07:4a via eth0
Jan 14 01:00:27 dhcp dhcpd: DHCPACK on 192.168.3.242 to 00:0c:29:32:07:4a via eth0
Jan 14 03:41:37 dhcp dhcpd: DHCPACK on 192.168.3.242 to 00:0c:29:32:07:4a via eth0
</pre>

== Les IPs ==
Ceux sont vraiment les adresses IP qui nous intéressent, nous allons utiliser un filtre en colonne:
<pre>
# cat /var/log/messages | grep "$(date +"%b %d")" | grep dhcpd | grep DHCPACK | awk -F ' ' '{ print $8 }'
192.168.3.242
192.168.3.242
192.168.3.242
192.168.3.242
</pre>
Enfin, nous allons utiliser la commande ''sort'' pour faire ressortir uniquement les adresses différentes:
<pre>
# cat /var/log/messages | grep "$(date +"%b %d")" | grep dhcpd | grep DHCPACK | awk -F ' ' '{ print $8 }' | sort -u
192.168.3.242
</pre>
Nous pourrions retourner l'adresse MAC associée à cette IP:
<pre>
# cat /var/log/messages | grep "$(date +"%b %d")" | grep dhcpd | grep DHCPACK | grep 192.168.3.242 | awk -F ' ' '{ print $10 }' | sort -u
00:0c:29:32:07:4a
</pre>
== Le plugin ==
Ce qui nous donne les lignes suivantes que nous placerons dans ''/opt/nagios/check_dhcp_ip.sh'' :
<syntaxhighlight lang="bash">
#!/bin/bash
## Setting local time lang
LC_ALL=en_US.utf8
RET=""
export LC_ALL
## Getting IPs
IPS=$(cat /var/log/messages | grep "$(date +"%b %d")" | grep dhcpd | grep DHCPACK | awk -F ' ' '{ print $8 }' | sort -u)
NBIP=0
## Getting MACs
for IP in ${IPS};do
MAC=$(cat /var/log/messages | grep "$(date +"%b %d")" | grep dhcpd | grep DHCPACK | grep $IP | awk -F ' ' '{ print $10 }' | sort -u)
if [ "${RET}" != "" ];then
RET="${RET} ;"
fi
RET="${RET} ${IP} <-> ${MAC}"
let NBIP++
done
## Echoing return
echo "${NBIP} ip delivered by dhcp : ${RET}"
exit 0
</syntaxhighlight>
Cela donne le résultat suivant:
<pre>
# ./check_dhcp_ip.sh
2 ip delivered by dhcp : 192.168.3.242 <-> 00:0c:29:32:07:4a ; 192.168.3.243 <-> 00:0c:29:8f:03:25
</pre>
== Les droits ==
Si on fait un :
<pre>
# ps -ef | grep nrpe | grep -v grep
nrpe 3518 1 0 05:39 ? 00:00:00 /usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -d
</pre>
On constate que ''NRPE'' se lance avec l'utilisateur ''nrpe'', et si on fait un :
<pre>
# ll /var/log/messages
-rw------- 1 root root 33596 14 janv. 05:46 /var/log/messages
</pre>
On constate que le fichier ''/var/log/messages'' est lisible uniquement par ''root''. On va donc ''étendre'' les droits du fichier :
<pre>
# chmod 555 /var/log/messages
</pre>
De la sorte notre plugin sera fonctionnel, même exécuté par l'utilisateur ''nrpe''.

== Ajout dans nrpe.cfg ==
Nous allons maintenant déclarer notre plugin dans le fichier ''/etc/nagios/nrpe.cfg'' :
<pre>
#####################
#
# SPECIFIC PLUGINS
#
#####################
command[check_dhcp_ip]=/opt/nagios/check_dhcp_ip.sh
</pre>
On n'oublie pas de redémarrer ''NRPE'' :
<pre>
# service nrpe restart
</pre>
== Ajout sur le serveur Nagios ==
Nous allons faire de même sur le serveur Nagios dans le fichier ''/etc/nagios/conf.d/sdhcpd.cfg'' :
<pre>
define service{
use local-service
host_name dhcp.tala-informatique.fr
service_description Check DHCP IP
check_command check_nrpe!check_dhcp_ip
}
</pre>
On n'oublie pas de redémarrer ''Nagios'' :
<pre>
# service nagios restart
</pre>
Et on vérifie sur l'interface web :
[[Fichier:Check dhcp ip web.png|centré]]

Proxmox fail2ban

2025-12-20T16:07:32Z

Jc.forton : /* Modification de AnyEvent.pm */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 3
findtime = 2d
bantime = 1h
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>
== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Tests =
Il faut maintenant tester le filtre et pour ça on peut utiliser un partage de connexion et réaliser le nombre d'échecs spécifié par la directive "maxretry" (ici 3) :
<pre>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 3
| `- Journal matches: _SYSTEMD_UNIT=pvedaemon.service
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 37.167.23.159
</pre>
On voit bien l'IP 37.167.23.159 qui est bannie !
N'oubliez pas de l'ajouter à ''ignoreip'' dans le fichier ''jails.local'' ou de faire
<pre>
# fail2ban-client unban 37.167.23.159
</pre>

= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification.
Il est donc plus simple de faire un ''tail'' ou un ''cat'':
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Que d'utiliser ''journalctl'' pour voir les IPs :
<pre>
# journalctl -fu pvedaemon
Dec 14 10:43:01 labo unix_chkpwd[1326506]: password check failed for user (root)
Dec 14 10:43:01 labo IPCC.xs[1320783]: pam_unix(proxmox-ve-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=37.167.23.159 user=root
Dec 14 10:43:03 labo pvedaemon[1320783]: authentication failure; rhost=37.167.23.159 user=root@pam msg=Authentication failure
</pre>
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête '''uniquement''' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<syntaxhighlight lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</syntaxhighlight>
C'est un peu plus loin qu'il faut insérer le code :
<syntaxhighlight lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</syntaxhighlight>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<syntaxhighlight lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</syntaxhighlight>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<syntaxhighlight lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</syntaxhighlight>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<syntaxhighlight lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</syntaxhighlight>
Il ne reste plus qu'à le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

Arduino SR501

2025-12-20T16:06:16Z

Jc.forton : /* Récupérer la présence de mouvement */

= Partie électronique =
== Le composant ==
Le ''SR501'' est généralement monté sur une platine.
[[Fichier:SR501.jpg|centré|150px]]

Ce composant possède une sortie numérique qui est à ''0v'' en l'absence de mouvement et ''5v'' sinon.

D'autres réglages sont possibles comme:
*la sensibilité
*le délais
*le type de déclenchement (impulsion simple ou répétée)
[[Fichier:SR501_config.png|centré|250px]]

== Le montage ==
Le montage suivant prévoit un fil ''data'' qui nous permettra de lire le retour du ''SR501'' sur le PIN 2 de ''l'Arduino''.
[[Fichier:SR501_diagram.png|centré|400px]]

= Partie logicielle =
== Récupérer la présence de mouvement ==
Un exemple de code qui permet de récupérer la présence de mouvement. Notez l'utilisation d'une résistance de ''pull-up'' sur le PIN 2 !
<syntaxhighlight lang="c">
int pirPin = 2;
int pirState = LOW;

void setup() {
// Met la broche 2 en entrée
pinMode(pirPin, INPUT);
// Utilisation d'une résistance de pull-up sur le PIN 2
digitalWrite(pirPin, HIGH);
// Active le port série
Serial.begin(9600);
}

void loop(){
// Vérification de l'état du capteur
if (digitalRead(pirPin ) == HIGH) {
if (pirState == LOW) {
// Mouvement !
Serial.println("Motion !");
pirState = HIGH;
}
} else {
if (pirState == HIGH){
// Pas de mouvement...
Serial.println("No motion...");
pirState = LOW;
}
}
}
</syntaxhighlight>

== Résultat ==
Voila le résultat :
[[Fichier:Arduino SR501 reading serial.png|centré|400px]]

MediaWiki:Common.css

2025-12-20T15:56:18Z

Jc.forton :

/* Le CSS placé ici sera appliqué à tous les habillages. */

MediaWiki:Common.css

2025-12-20T15:43:06Z

Jc.forton : Page créée avec « /* Le CSS placé ici sera appliqué à tous les habillages. */ // Source - https://stackoverflow.com/a // Posted by Jinlye // Retrieved 2025-12-20, License - CC BY-SA 3.0 /***** Overcome mediawiki bug whereby the WikiEdit sprite is a no-show *****/ .wikiEditor-toolbar-spritedButton { background-image: linear-gradient(transparent, transparent), url("/extensions/WikiEditor/modules/images/toolbar/button-sprite.svg?v=001") !important; background-position: 0px 0p... »

/* Le CSS placé ici sera appliqué à tous les habillages. */
// Source - https://stackoverflow.com/a
// Posted by Jinlye
// Retrieved 2025-12-20, License - CC BY-SA 3.0

/***** Overcome mediawiki bug whereby the WikiEdit sprite is a no-show *****/
.wikiEditor-toolbar-spritedButton {
background-image: linear-gradient(transparent, transparent), url("/extensions/WikiEditor/modules/images/toolbar/button-sprite.svg?v=001") !important;
background-position: 0px 0px; /* This gets over-ridden with inline style to move sprite into view of relevant part */
background-repeat: no-repeat !important;
}

Php $get $post $session

2025-12-16T14:32:12Z

Jc.forton :

= Introduction =
== Les concepts ==
Lorsque l'on conçoit une application Web, il y a un moment ou on est obligé de communiquer des informations entre les différentes pages de cette application.
Les pages sont demandées par la partie cliente, généralement un navigateur (eg. Firefox, Chrome, Safari, ...), et sont distribuées par la partie serveur (eg. Apache HTTPd, Nginx, IIS, ...).

Cette échange est encadré par l'utilisation du protocole [[:Media:HTTP.pdf|HTTP]] et doit donc utiliser des '''méthodes HTTP''', aussi appellées '''verbes HTTP''', consacrés :
* ''GET'';
* ''POST'';
* ''PUT'';
* ''DELETE'';
Les deux premiers sont utilisés dans les applications Web au travers de formulaires et les deux derniers sont plutôt utilisés dans le cadre de [[:Media:webservices.pdf|Web services RESTful]].

On distingue donc deux cas de figure :
*l'envoie d'informations du client au serveur;
*la conservation d'information côté serveur.
Dans le premier cas de figure, on peut utiliser les méthodes ''GET'' ou ''POST'', alors que dans le deuxième cas de figure on utilisera les sessions.

== Création d'un projet ==
Pour illustrer ces propos nous allons créer un projet dans [[eclipse_install|Eclipse]] et pour cela assurez-vous d'avoir la perspective Php ainsi que d'avoir suivi le tutoriel [[Php_xdebug | Xdebug]].

Commençons par la création du projet:
* Première écran de l'assistant :
** on créé le projet sur le [[Php_xdebug#Ajout_d.27un_serveur_Web|serveur local]];
** on active le support de JavaScript
[[Fichier:Eclipse php project create first screen.png|centré|450px]]
* Deuxième écran de l'assistant :
** On créé un repertoire ''src''
[[Fichier:Eclipse php project create second screen.png|centré|450px]]
* On clique sur ''finish'' pour terminer l'assistant

Une fois le projet créé, on va y ajouter une page ''index.php''
<source lang="html">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Formulaire</title>
</head>
<body>
<div align="center">
<form action="php/traitement.php" method="get">
Login :
<input type="text" name="login"><br>
Password :
<input type="password" name="password"><br>
<input type="submit" value="Connexion">
</form>
</div>
</body>
</html>
</source>

Comme vous pouvez le constater, cette page ne contient pas le code Php en charge du traitement du formulaire. Elle envoie les informations à la page ''traitement.php'' qui se trouve dans le répertoire ''php''.
Voici le code de cette page :
<source lang="php">
<?php

var_dump($_GET);
</source>

= La méthode ''GET'' =
Pour l'instant, en phase de découverte, nous allons utiliser la fonction ''var_dump'' qui permet d'afficher le contenu d'une variable, peu importe son type.
On pourrait également utiliser la vue ''Debug'' d'Eclipse pour voir le contenu de la variable en mémoire.
Peu importe la solution retenue, l'important et de voir la corrélation entre :
*les données du formulaire;
*l'URL;
*le tableau ''$_GET'' créé par l'interpréteur Php.
== Envoie d'information ==
Lorsque l'on valide le formulaire, le navigateur va construivre l'URL suivante :

http://localhost/Form/src/php/traitement.php?login=toto&password=titi

Et l'interpréteur Php va remplir le tableau ''$_GET'' de la manière suivante (résultat du ''var_dump'') :

<pre>
array (size=2)
'login' => string 'toto' (length=4)
'password' => string 'titi' (length=4)
</pre>

On peut s'amuser à modifier les valeurs dans l'URL pour comprendre l'impact sur le contenu du tableau ''$_GET'' : l'interpréteur construit un tableau associatif ou figurera chacun des tuples présent dans l'URL.
Le caractère ''?'' sert à séparer la ressource demandée de la liste des tuples et le caractère ''&'' sert à séparer chacun des tuples dans la liste.

== Réception d'information ==
La récupération d'une valeur semble simple : il suffit d'y accéder en spécifiant son nom.

<source lang="php">
<?php

$login = $_GET["login"];
$password = $_GET["password"];

echo "Votre login est : ".$login;
echo "<br>";
echo "Votre mot de passe est : ".$password;
</source>

= La méthode ''POST'' =
== Envoie d'information ==
Très similaire à la méthode ''GET'' à la différence que les tuples sont envoyé dans le corps de la requête ''HTTP'' et non dans l'URL.
Pour l'utiliser, il suffit de modifier la ligne suivante du fichier ''index.php'' :
<source lang="php">
<form action="php/traitement.php" method="get">
</source>
en
<source lang="php">
<form action="php/traitement.php" method="post">
</source>
== Réception d'information ==
La récupération des informations ce fait non plus dans le tableau ''$_GET'' mais dans le tableau ''$_POST'' :
<source lang="php">
<?php

$login = $_POST["login"];
$password = $_POST["password"];

echo "Votre login est : ".$login;
echo "<br>";
echo "Votre mot de passe est : ".$password;
</source>

= Limitations =
==Une variable manque à l'appel !==
Que se passe t-il si l'un des paramètres manque ? Si, par exemple, il manque le tuple ''password'' comme c'est le cas avec l'URL suivante:

http://localhost/Form/src/php/traitement.php?login=toto

Ci-dessous un extrait du fichier ''/var/log/httpd/error_log''
<pre>
[Mon Jun 27 04:49:56 2016] [error] [client 192.168.100.1] PHP Notice: Undefined index: password in /var/www/html/Form/src/php/traitement.php on line 4
[Mon Jun 27 04:49:56 2016] [error] [client 192.168.100.1] PHP Stack trace:
[Mon Jun 27 04:49:56 2016] [error] [client 192.168.100.1] PHP 1. {main}() /var/www/html/Form/src/php/traitement.php:0
</pre>

Pour ne pas prendre de risque il faudrait tester si l'index existe en utilisant la fonction ''isset'' :
<source lang="php">
<?php
if (isset ( $_GET ["login"] )) {
$login = $_GET ["login"];
echo "Votre login est : " . $login;
echo "<br>";
}
if (isset ( $_GET ["password"] )) {
$password = $_GET ["password"];
echo "Votre mot de passe est : " . $password;
}
</source>
==Ma variable est vide !==
Que se passe t-il si la variable est vide ? Si, par exemple, le tuple ''password'' ne possède pas de valeur comme c'est le cas avec l'URL suivante:

http://localhost/Form/src/php/traitement.php?login=toto&password

Aucune erreur n'est générée mais le reste du code risque de ne pas fonctionner correctement...
Il faudrait tester si la variable n'est pas vide grâce à la fonction ''empty''

<source lang="php">
if (isset ( $_GET ["login"] )) {
$login = $_GET ["login"];
if (! empty ( $login )) {
echo "Votre login est : " . $login;
echo "<br>";
}
}
if (isset ( $_GET ["password"] )) {
$password = $_GET ["password"];
if (! empty ( $password )) {
echo "Votre mot de passe est : " . $password;
}
}
</source>
== Réfléxion... ==
Pour ce formulaire composé de seulement deux champs on constate que la quantité de code qu'il faut écrire, si on veut faire un traitement efficace des valeurs, est colossale.
On imagine facilement que plus il y aura de champs plus cela sera pénible...

Il faudrait un moyen, pas trop compliqué, de savoir si une variable existe et si elle à une valeur. On va en profiter pour gérer le cas des nombre, en effet, le chiffre ''0'' est considéré comme ''empty''.

Nous allons écrire deux fonctions pour cela dans le fichier ''php/helper.php'' :

<source lang="php">
<?php
function getVar($name) {
if (isset ( $_GET [$name] )) {
if(is_numeric($tab[$name])){
return $tab[$name];
}
if (! empty ( $_GET [$name] )) {
return $_GET [$name];
}
return TRUE;
}
return FALSE;
}

function postVar($name) {
if (isset ( $_POST [$name] )) {
if(is_numeric($tab[$name])){
return $tab[$name];
}
if (! empty ( $_POST[$name] )) {
return $_POST[$name];
}
return TRUE;
}
return FALSE;
}
</source>
Bon d'accord ! On peut encore compresser :
<source lang=php>
<?php
function getVar($name) {
return retrieveVar($name, $_GET);
}
function postVar($name) {
return retrieveVar($name, $_POST);
}
function retrieveVar($name, $tab){
if (isset($tab[$name])) {
if(is_numeric($tab[$name])){
return $tab[$name];
}
if (! empty($tab[$name])) {
return $tab[$name];
}
return TRUE;
}
return FALSE;
}
</source>

Ces fonctions renvoies :
* faux si la variable n'existe pas ;
* vrai si elle existe mais est vide ;
* sinon sa valeur.

La philosophie est simple:
* soit on à besoin que la variable '''existe''' et on fait le test suivant :
<source lang="php">
$var = getVar("var");

// Si différent de faux, la variable existe avec une valeur ou non !
if($var !== FALSE){
...
}
</source>
* soit il faut '''absolument''' une valeur on fait le test suivant :
<source lang="php">
$var = getVar("var");

// Si la variable n'est pas un booleen, elle à une valeur !
if(!is_bool($var)){
...
}
</source>

Voyez comme le code est plus clair, simple, efficace :

<source lang="php">
<?php
include 'helper.php';

$login = getVar ( "login" );
$password = getVar ( "password" );

if (! is_bool ( $login )) {
echo "Votre login est : " . $login;
echo "<br>";
}
if (! is_bool ( $password )) {
echo "Votre mot de passe est : " . $password;
}
</source>

= Interaction =
==Redirection après vérification==
Il faudrait maintenant tester les valeurs des champs pour confirmer ou infirmer l'authentification. Pour ce faire, nous allons modifier la page ''traitement.php'':
<source lang="php">
<?php
include 'helper.php';

// Valeur par défaut
$stored_login = "root";
$stored_password = "toor";

$login = getVar ( "login" );
$password = getVar ( "password" );

if (! is_bool ( $login ) && ! is_bool ( $password )) {
if($login == $stored_login && $password == $stored_password){
// Authentification réussie
return header("Location: ../logged.php");
}
}
// Authentification échoué
header("Location: ../index.php");
</source>
Dans ce script :
* on définit au début les valeurs du couple login / mot de passe mais on aurait pu récupérer ces valeur dans une base de données;
* on utilise la fonction ''header'' avec la valeur ''Location'' qui permet de '''rediriger le navigateur''' en ajoutant un ''header HTTP'' à la réponse.
Si l'authentification se passe correctement, on est redirigé vers la page ''logged.php'' (que nous allons créer), si elle échoue on revient sur la page ''index.php'' pour faire une nouvelle tentative de connexion.
Voici le code de la page ''logged.php'':
<source lang="php">
<?php

echo "Authentification réussie !";
</source>
==User eXperience==
En UX, on s'intéresse beaucoup à l'utilisateur et son ressenti. Que va t-il se passer si l'authentification échoue ? Il sera redirigé tellement vite sur la page ''index.php'' qu'il aura l'impression que rien ne s'est passé... Il faut absolument que la page ''index.php'' affiche un message qui informe de l'échec de l'authentification !

C'est ''traitement.php'' qui détient l'information de l’échec ou de la réussite de l'authentification... Il faudrait que cette page transmette l'information à ''index.php'' ! Comment faire... avec un ''GET'' mais, cette fois, sans formulaire et uniquement en modifiant l'URL de redirection en cas d'échec. Dans le fichier ''traitement.php'' modifiez la ligne suivante :
<source lang="php">
<?php
// Authentification échoué
header("Location: ../index.php");
</source>
en
<source lang="php">
<?php
// Authentification échoué
header("Location: ../index.php?echec");
</source>
Il suffit maintenant de récupérer l'information dans la page ''index.php''. Ajouter, au dessus de la ''div'' existante, le code suivant :
<source lang="php">
<div align="center">
<?php
include 'php/helper.php';
$echec = getVar("echec");
if($echec !== FALSE){
echo "Echec de l'authentification !";
}
?>
</div>
</source>
Lorsque l'on échoue l'authentification, un message s'affiche !
= Les sessions =
Les sessions en PHP permettent de mémoriser des informations dans le tableau $_SESSION accessible après l'appel de la fonction ''session_start''.
Ce tableau est unique pour chaque connexion et ne peut être partagé entre plusieurs clients.
== Mémoire d'éléphant ==
Si on essaye d'accéder à la page ''logged.php'' sans passer par la page ''index.php''... cela fonctionne.

Il faut absolument que notre application web se souvienne si la personne est authentifiée sinon elle doit rediriger vers ''index.php''. Nous allons utiliser les ''sessions'' pour doter notre application Web d'une mémoire !

Dans la page ''traitement.php'' modifiez les lignes suivantes :
<source lang="php">
// Authentification réussie
session_start();
$_SESSION["logged"] = true;
return header("Location: ../logged.php");
</source>

Pour accéder à cette variable nous allons utiliser une fonction, comme pour ''GET'' et ''POST'', que nous allons placer dans le fichier ''helper.php'' :
<source lang="php">
function sessionVar($name) {
if (session_status() !== PHP_SESSION_ACTIVE) {
session_start();
}
if (isset ( $_SESSION [$name] )) {
if (! empty ( $_SESSION [$name] )) {
return $_SESSION [$name];
}
return TRUE;
}
return FALSE;
}
</source>
ou pour reprendre l'exemple plus haut :
<source lang=php>
function sessionVar($name) {
if (session_status() !== PHP_SESSION_ACTIVE) {
session_start();
}
return retrieveVar($name, $_SESSION);
}
</source>
La fonction ''session_status'' permet de connaître le statut d'une session est peut prendre plusieurs valeurs :
*PHP_SESSION_DISABLED : si les sessions sont désactivées sur le serveur;
*PHP_SESSION_NONE : si les sessions sont actives mais qu'aucune n'existe;
*PHP_SESSION_ACTIVE : si une session existe
Cette fonction est très utile car elle nous permet de tester l’existence d'une session avant de la démarrer. Php lèvera une notification si on appel deux fois de suite à la fonction ''session_start'' :
<pre>
PHP Notice: A session had already been started - ignoring session_start()
</pre>
Il ne nous reste plus qu'à récupérer cette valeur dans la page ''logged.php'' et à rediriger les ''petits malin'' non authentifiés vers la page ''index.php'':
<source lang=php>
<?php
include 'php/helper.php';
$logged = sessionVar("logged");
if($logged === FALSE){
return header("Location: index.php");
}
echo "Authentification réussie !";
</source>

== Perte de mémoire !==
Si on veut déconnecter l'utilisateur de l'application il faut ''oublier'' qu'il est connecté et, pour cela, il faut utiliser la fonction ''session_destroy''.
Nous allons créer une page ''php/unlog.php'' qui contiendra les lignes suivantes :
<source lang=php>
<?php
session_start();
session_destroy();
header("Location: index.php");
</source>
Dans cette page on :
* démarre la session;
* détruit la session;
* redirige l'utilisateur vers ''index.php''
Il ne reste plus qu'à mettre un lien dans la page ''logged.php'', a la fin du fichier :
<source lang=php>
echo "<br>";
echo "<a href='php/unlog.php' >déconnexion</a>";
</source>
Pour résumer :
* session_start : permet de démarrer une session;
* session _status : permet de connaître l'état d'une session;
* session_destroy : permet de détruire une session.

=Pour aller plus loin=
On pourrait même modifier l'URL pour que la page ''index.php'' affiche le message suivant : ''Vous devez être connecté pour voir cette page !'' :
* sur la page ''logged.php'' modifiez la ligne suivante :
<source lang=php>
return header("Location: index.php?unlogged");
</source>
* sur la page ''index.php'' modifiez les lignes suivantes :
<source lang=php>
<?php
include 'php/helper.php';
if(getVar("echec")!== FALSE){
echo "Echec de l'authentification !";
}else if(getVar("logged")!== FALSE){
echo "Vous devez être connecté pour voir cette page !";
}
?>
</source>

Php $get $post $session

2025-12-16T14:24:42Z

Jc.forton : /* Réception d'information */

= Introduction =
== Les concepts ==
Lorsque l'on conçoit une application Web, il y a un moment ou on est obligé de communiquer des informations entre les différentes pages de cette application.
Les pages sont demandées par la partie cliente, généralement un navigateur (eg. Firefox, Chrome, Safari, ...), et sont distribuées par la partie serveur (eg. Apache HTTPd, Nginx, IIS, ...).

Cette échange est encadré par l'utilisation du protocole [[:Media:HTTP.pdf|HTTP]] et doit donc utiliser des '''méthodes HTTP''', aussi appellées '''verbes HTTP''', consacrés :
* ''GET'';
* ''POST'';
* ''PUT'';
* ''DELETE'';
Les deux premiers sont utilisés dans les applications Web au travers de formulaires et les deux derniers sont plutôt utilisés dans le cadre de [[:Media:webservices.pdf|Web services RESTful]].

On distingue donc deux cas de figure :
*l'envoie d'informations du client au serveur;
*la conservation d'information côté serveur.
Dans le premier cas de figure, on peut utiliser les méthodes ''GET'' ou ''POST'', alors que dans le deuxième cas de figure on utilisera les sessions.

== Création d'un projet ==
Pour illustrer ces propos nous allons créer un projet dans [[eclipse_install|Eclipse]] et pour cela assurez-vous d'avoir la perspective Php ainsi que d'avoir suivi le tutoriel [[Php_xdebug | Xdebug]].

Commençons par la création du projet:
* Première écran de l'assistant :
** on créé le projet sur le [[Php_xdebug#Ajout_d.27un_serveur_Web|serveur local]];
** on active le support de JavaScript
[[Fichier:Eclipse php project create first screen.png|centré|450px]]
* Deuxième écran de l'assistant :
** On créé un repertoire ''src''
[[Fichier:Eclipse php project create second screen.png|centré|450px]]
* On clique sur ''finish'' pour terminer l'assistant

Une fois le projet créé, on va y ajouter une page ''index.php''
<source lang="html">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Formulaire</title>
</head>
<body>
<div align="center">
<form action="php/traitement.php" method="get">
Login :
<input type="text" name="login"><br>
Password :
<input type="password" name="password"><br>
<input type="submit" value="Connexion">
</form>
</div>
</body>
</html>
</source>

Comme vous pouvez le constater, cette page ne contient pas le code Php en charge du traitement du formulaire. Elle envoie les informations à la page ''traitement.php'' qui se trouve dans le répertoire ''php''.
Voici le code de cette page :
<source lang="php">
<?php

var_dump($_GET);
</source>

= La méthode ''GET'' =
Pour l'instant, en phase de découverte, nous allons utiliser la fonction ''var_dump'' qui permet d'afficher le contenu d'une variable, peu importe son type.
On pourrait également utiliser la vue ''Debug'' d'Eclipse pour voir le contenu de la variable en mémoire.
Peu importe la solution retenue, l'important et de voir la corrélation entre :
*les données du formulaire;
*l'URL;
*le tableau ''$_GET'' créé par l'interpréteur Php.
== Envoie d'information ==
Lorsque l'on valide le formulaire, le navigateur va construivre l'URL suivante :

http://localhost/Form/src/php/traitement.php?login=toto&password=titi

Et l'interpréteur Php va remplir le tableau ''$_GET'' de la manière suivante (résultat du ''var_dump'') :

<pre>
array (size=2)
'login' => string 'toto' (length=4)
'password' => string 'titi' (length=4)
</pre>

On peut s'amuser à modifier les valeurs dans l'URL pour comprendre l'impact sur le contenu du tableau ''$_GET'' : l'interpréteur construit un tableau associatif ou figurera chacun des tuples présent dans l'URL.
Le caractère ''?'' sert à séparer la ressource demandée de la liste des tuples et le caractère ''&'' sert à séparer chacun des tuples dans la liste.

== Réception d'information ==
La récupération d'une valeur semble simple : il suffit d'y accéder en spécifiant son nom.

<source lang="php">
<?php

$login = $_GET["login"];
$password = $_GET["password"];

echo "Votre login est : ".$login;
echo "<br>";
echo "Votre mot de passe est : ".$password;
</source>

= La méthode ''POST'' =
== Envoie d'information ==
Très similaire à la méthode ''GET'' à la différence que les tuples sont envoyé dans le corps de la requête ''HTTP'' et non dans l'URL.
Pour l'utiliser, il suffit de modifier la ligne suivante du fichier ''index.php'' :
<syntaxhighlight lang="php">
<form action="php/traitement.php" method="get">
</syntaxhighlight>
en
<syntaxhighlight lang="php">
<form action="php/traitement.php" method="post">
</syntaxhighlight>
== Réception d'information ==
La récupération des informations ce fait non plus dans le tableau ''$_GET'' mais dans le tableau ''$_POST'' :
<syntaxhighlight lang="php">
<?php

$login = $_POST["login"];
$password = $_POST["password"];

echo "Votre login est : ".$login;
echo "<br>";
echo "Votre mot de passe est : ".$password;
</syntaxhighlight>

= Limitations =
==Une variable manque à l'appel !==
Que se passe t-il si l'un des paramètres manque ? Si, par exemple, il manque le tuple ''password'' comme c'est le cas avec l'URL suivante:

http://localhost/Form/src/php/traitement.php?login=toto

Ci-dessous un extrait du fichier ''/var/log/httpd/error_log''
<pre>
[Mon Jun 27 04:49:56 2016] [error] [client 192.168.100.1] PHP Notice: Undefined index: password in /var/www/html/Form/src/php/traitement.php on line 4
[Mon Jun 27 04:49:56 2016] [error] [client 192.168.100.1] PHP Stack trace:
[Mon Jun 27 04:49:56 2016] [error] [client 192.168.100.1] PHP 1. {main}() /var/www/html/Form/src/php/traitement.php:0
</pre>

Pour ne pas prendre de risque il faudrait tester si l'index existe en utilisant la fonction ''isset'' :
<syntaxhighlight lang="php">
<?php
if (isset ( $_GET ["login"] )) {
$login = $_GET ["login"];
echo "Votre login est : " . $login;
echo "<br>";
}
if (isset ( $_GET ["password"] )) {
$password = $_GET ["password"];
echo "Votre mot de passe est : " . $password;
}
</syntaxhighlight>
==Ma variable est vide !==
Que se passe t-il si la variable est vide ? Si, par exemple, le tuple ''password'' ne possède pas de valeur comme c'est le cas avec l'URL suivante:

http://localhost/Form/src/php/traitement.php?login=toto&password

Aucune erreur n'est générée mais le reste du code risque de ne pas fonctionner correctement...
Il faudrait tester si la variable n'est pas vide grâce à la fonction ''empty''

<syntaxhighlight lang="php">
if (isset ( $_GET ["login"] )) {
$login = $_GET ["login"];
if (! empty ( $login )) {
echo "Votre login est : " . $login;
echo "<br>";
}
}
if (isset ( $_GET ["password"] )) {
$password = $_GET ["password"];
if (! empty ( $password )) {
echo "Votre mot de passe est : " . $password;
}
}
</syntaxhighlight>
== Réfléxion... ==
Pour ce formulaire composé de seulement deux champs on constate que la quantité de code qu'il faut écrire, si on veut faire un traitement efficace des valeurs, est colossale.
On imagine facilement que plus il y aura de champs plus cela sera pénible...

Il faudrait un moyen, pas trop compliqué, de savoir si une variable existe et si elle à une valeur. On va en profiter pour gérer le cas des nombre, en effet, le chiffre ''0'' est considéré comme ''empty''.

Nous allons écrire deux fonctions pour cela dans le fichier ''php/helper.php'' :

<syntaxhighlight lang="php">
<?php
function getVar($name) {
if (isset ( $_GET [$name] )) {
if(is_numeric($tab[$name])){
return $tab[$name];
}
if (! empty ( $_GET [$name] )) {
return $_GET [$name];
}
return TRUE;
}
return FALSE;
}

function postVar($name) {
if (isset ( $_POST [$name] )) {
if(is_numeric($tab[$name])){
return $tab[$name];
}
if (! empty ( $_POST[$name] )) {
return $_POST[$name];
}
return TRUE;
}
return FALSE;
}
</syntaxhighlight>
Bon d'accord ! On peut encore compresser :
<syntaxhighlight lang=php>
<?php
function getVar($name) {
return retrieveVar($name, $_GET);
}
function postVar($name) {
return retrieveVar($name, $_POST);
}
function retrieveVar($name, $tab){
if (isset($tab[$name])) {
if(is_numeric($tab[$name])){
return $tab[$name];
}
if (! empty($tab[$name])) {
return $tab[$name];
}
return TRUE;
}
return FALSE;
}
</syntaxhighlight>

Ces fonctions renvoies :
* faux si la variable n'existe pas ;
* vrai si elle existe mais est vide ;
* sinon sa valeur.

La philosophie est simple:
* soit on à besoin que la variable '''existe''' et on fait le test suivant :
<syntaxhighlight lang="php">
$var = getVar("var");

// Si différent de faux, la variable existe avec une valeur ou non !
if($var !== FALSE){
...
}
</syntaxhighlight>
* soit il faut '''absolument''' une valeur on fait le test suivant :
<syntaxhighlight lang="php">
$var = getVar("var");

// Si la variable n'est pas un booleen, elle à une valeur !
if(!is_bool($var)){
...
}
</syntaxhighlight>

Voyez comme le code est plus clair, simple, efficace :

<syntaxhighlight lang="php">
<?php
include 'helper.php';

$login = getVar ( "login" );
$password = getVar ( "password" );

if (! is_bool ( $login )) {
echo "Votre login est : " . $login;
echo "<br>";
}
if (! is_bool ( $password )) {
echo "Votre mot de passe est : " . $password;
}
</syntaxhighlight>

= Interaction =
==Redirection après vérification==
Il faudrait maintenant tester les valeurs des champs pour confirmer ou infirmer l'authentification. Pour ce faire, nous allons modifier la page ''traitement.php'':
<syntaxhighlight lang="php">
<?php
include 'helper.php';

// Valeur par défaut
$stored_login = "root";
$stored_password = "toor";

$login = getVar ( "login" );
$password = getVar ( "password" );

if (! is_bool ( $login ) && ! is_bool ( $password )) {
if($login == $stored_login && $password == $stored_password){
// Authentification réussie
return header("Location: ../logged.php");
}
}
// Authentification échoué
header("Location: ../index.php");
</syntaxhighlight>
Dans ce script :
* on définit au début les valeurs du couple login / mot de passe mais on aurait pu récupérer ces valeur dans une base de données;
* on utilise la fonction ''header'' avec la valeur ''Location'' qui permet de '''rediriger le navigateur''' en ajoutant un ''header HTTP'' à la réponse.
Si l'authentification se passe correctement, on est redirigé vers la page ''logged.php'' (que nous allons créer), si elle échoue on revient sur la page ''index.php'' pour faire une nouvelle tentative de connexion.
Voici le code de la page ''logged.php'':
<syntaxhighlight lang="php">
<?php

echo "Authentification réussie !";
</syntaxhighlight>
==User eXperience==
En UX, on s'intéresse beaucoup à l'utilisateur et son ressenti. Que va t-il se passer si l'authentification échoue ? Il sera redirigé tellement vite sur la page ''index.php'' qu'il aura l'impression que rien ne s'est passé... Il faut absolument que la page ''index.php'' affiche un message qui informe de l'échec de l'authentification !

C'est ''traitement.php'' qui détient l'information de l’échec ou de la réussite de l'authentification... Il faudrait que cette page transmette l'information à ''index.php'' ! Comment faire... avec un ''GET'' mais, cette fois, sans formulaire et uniquement en modifiant l'URL de redirection en cas d'échec. Dans le fichier ''traitement.php'' modifiez la ligne suivante :
<syntaxhighlight lang="php">
<?php
// Authentification échoué
header("Location: ../index.php");
</syntaxhighlight>
en
<syntaxhighlight lang="php">
<?php
// Authentification échoué
header("Location: ../index.php?echec");
</syntaxhighlight>
Il suffit maintenant de récupérer l'information dans la page ''index.php''. Ajouter, au dessus de la ''div'' existante, le code suivant :
<syntaxhighlight lang="php">
<div align="center">
<?php
include 'php/helper.php';
$echec = getVar("echec");
if($echec !== FALSE){
echo "Echec de l'authentification !";
}
?>
</div>
</syntaxhighlight>
Lorsque l'on échoue l'authentification, un message s'affiche !
= Les sessions =
Les sessions en PHP permettent de mémoriser des informations dans le tableau $_SESSION accessible après l'appel de la fonction ''session_start''.
Ce tableau est unique pour chaque connexion et ne peut être partagé entre plusieurs clients.
== Mémoire d'éléphant ==
Si on essaye d'accéder à la page ''logged.php'' sans passer par la page ''index.php''... cela fonctionne.

Il faut absolument que notre application web se souvienne si la personne est authentifiée sinon elle doit rediriger vers ''index.php''. Nous allons utiliser les ''sessions'' pour doter notre application Web d'une mémoire !

Dans la page ''traitement.php'' modifiez les lignes suivantes :
<syntaxhighlight lang="php">
// Authentification réussie
session_start();
$_SESSION["logged"] = true;
return header("Location: ../logged.php");
</syntaxhighlight>

Pour accéder à cette variable nous allons utiliser une fonction, comme pour ''GET'' et ''POST'', que nous allons placer dans le fichier ''helper.php'' :
<syntaxhighlight lang="php">
function sessionVar($name) {
if (session_status() !== PHP_SESSION_ACTIVE) {
session_start();
}
if (isset ( $_SESSION [$name] )) {
if (! empty ( $_SESSION [$name] )) {
return $_SESSION [$name];
}
return TRUE;
}
return FALSE;
}
</syntaxhighlight>
ou pour reprendre l'exemple plus haut :
<syntaxhighlight lang=php>
function sessionVar($name) {
if (session_status() !== PHP_SESSION_ACTIVE) {
session_start();
}
return retrieveVar($name, $_SESSION);
}
</syntaxhighlight>
La fonction ''session_status'' permet de connaître le statut d'une session est peut prendre plusieurs valeurs :
*PHP_SESSION_DISABLED : si les sessions sont désactivées sur le serveur;
*PHP_SESSION_NONE : si les sessions sont actives mais qu'aucune n'existe;
*PHP_SESSION_ACTIVE : si une session existe
Cette fonction est très utile car elle nous permet de tester l’existence d'une session avant de la démarrer. Php lèvera une notification si on appel deux fois de suite à la fonction ''session_start'' :
<pre>
PHP Notice: A session had already been started - ignoring session_start()
</pre>
Il ne nous reste plus qu'à récupérer cette valeur dans la page ''logged.php'' et à rediriger les ''petits malin'' non authentifiés vers la page ''index.php'':
<syntaxhighlight lang=php>
<?php
include 'php/helper.php';
$logged = sessionVar("logged");
if($logged === FALSE){
return header("Location: index.php");
}
echo "Authentification réussie !";
</syntaxhighlight>

== Perte de mémoire !==
Si on veut déconnecter l'utilisateur de l'application il faut ''oublier'' qu'il est connecté et, pour cela, il faut utiliser la fonction ''session_destroy''.
Nous allons créer une page ''php/unlog.php'' qui contiendra les lignes suivantes :
<syntaxhighlight lang=php>
<?php
session_start();
session_destroy();
header("Location: index.php");
</syntaxhighlight>
Dans cette page on :
* démarre la session;
* détruit la session;
* redirige l'utilisateur vers ''index.php''
Il ne reste plus qu'à mettre un lien dans la page ''logged.php'', a la fin du fichier :
<syntaxhighlight lang=php>
echo "<br>";
echo "<a href='php/unlog.php' >déconnexion</a>";
</syntaxhighlight>
Pour résumer :
* session_start : permet de démarrer une session;
* session _status : permet de connaître l'état d'une session;
* session_destroy : permet de détruire une session.

=Pour aller plus loin=
On pourrait même modifier l'URL pour que la page ''index.php'' affiche le message suivant : ''Vous devez être connecté pour voir cette page !'' :
* sur la page ''logged.php'' modifiez la ligne suivante :
<syntaxhighlight lang=php>
return header("Location: index.php?unlogged");
</syntaxhighlight>
* sur la page ''index.php'' modifiez les lignes suivantes :
<syntaxhighlight lang=php>
<?php
include 'php/helper.php';
if(getVar("echec")!== FALSE){
echo "Echec de l'authentification !";
}else if(getVar("logged")!== FALSE){
echo "Vous devez être connecté pour voir cette page !";
}
?>
</syntaxhighlight>

Php $get $post $session

2025-12-16T14:22:50Z

Jc.forton : /* Création d'un projet */

= Introduction =
== Les concepts ==
Lorsque l'on conçoit une application Web, il y a un moment ou on est obligé de communiquer des informations entre les différentes pages de cette application.
Les pages sont demandées par la partie cliente, généralement un navigateur (eg. Firefox, Chrome, Safari, ...), et sont distribuées par la partie serveur (eg. Apache HTTPd, Nginx, IIS, ...).

Cette échange est encadré par l'utilisation du protocole [[:Media:HTTP.pdf|HTTP]] et doit donc utiliser des '''méthodes HTTP''', aussi appellées '''verbes HTTP''', consacrés :
* ''GET'';
* ''POST'';
* ''PUT'';
* ''DELETE'';
Les deux premiers sont utilisés dans les applications Web au travers de formulaires et les deux derniers sont plutôt utilisés dans le cadre de [[:Media:webservices.pdf|Web services RESTful]].

On distingue donc deux cas de figure :
*l'envoie d'informations du client au serveur;
*la conservation d'information côté serveur.
Dans le premier cas de figure, on peut utiliser les méthodes ''GET'' ou ''POST'', alors que dans le deuxième cas de figure on utilisera les sessions.

== Création d'un projet ==
Pour illustrer ces propos nous allons créer un projet dans [[eclipse_install|Eclipse]] et pour cela assurez-vous d'avoir la perspective Php ainsi que d'avoir suivi le tutoriel [[Php_xdebug | Xdebug]].

Commençons par la création du projet:
* Première écran de l'assistant :
** on créé le projet sur le [[Php_xdebug#Ajout_d.27un_serveur_Web|serveur local]];
** on active le support de JavaScript
[[Fichier:Eclipse php project create first screen.png|centré|450px]]
* Deuxième écran de l'assistant :
** On créé un repertoire ''src''
[[Fichier:Eclipse php project create second screen.png|centré|450px]]
* On clique sur ''finish'' pour terminer l'assistant

Une fois le projet créé, on va y ajouter une page ''index.php''
<source lang="html">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Formulaire</title>
</head>
<body>
<div align="center">
<form action="php/traitement.php" method="get">
Login :
<input type="text" name="login"><br>
Password :
<input type="password" name="password"><br>
<input type="submit" value="Connexion">
</form>
</div>
</body>
</html>
</source>

Comme vous pouvez le constater, cette page ne contient pas le code Php en charge du traitement du formulaire. Elle envoie les informations à la page ''traitement.php'' qui se trouve dans le répertoire ''php''.
Voici le code de cette page :
<source lang="php">
<?php

var_dump($_GET);
</source>

= La méthode ''GET'' =
Pour l'instant, en phase de découverte, nous allons utiliser la fonction ''var_dump'' qui permet d'afficher le contenu d'une variable, peu importe son type.
On pourrait également utiliser la vue ''Debug'' d'Eclipse pour voir le contenu de la variable en mémoire.
Peu importe la solution retenue, l'important et de voir la corrélation entre :
*les données du formulaire;
*l'URL;
*le tableau ''$_GET'' créé par l'interpréteur Php.
== Envoie d'information ==
Lorsque l'on valide le formulaire, le navigateur va construivre l'URL suivante :

http://localhost/Form/src/php/traitement.php?login=toto&password=titi

Et l'interpréteur Php va remplir le tableau ''$_GET'' de la manière suivante (résultat du ''var_dump'') :

<pre>
array (size=2)
'login' => string 'toto' (length=4)
'password' => string 'titi' (length=4)
</pre>

On peut s'amuser à modifier les valeurs dans l'URL pour comprendre l'impact sur le contenu du tableau ''$_GET'' : l'interpréteur construit un tableau associatif ou figurera chacun des tuples présent dans l'URL.
Le caractère ''?'' sert à séparer la ressource demandée de la liste des tuples et le caractère ''&'' sert à séparer chacun des tuples dans la liste.

== Réception d'information ==
La récupération d'une valeur semble simple : il suffit d'y accéder en spécifiant son nom.

<syntaxhighlight lang="php">
<?php

$login = $_GET["login"];
$password = $_GET["password"];

echo "Votre login est : ".$login;
echo "<br>";
echo "Votre mot de passe est : ".$password;
</syntaxhighlight>

= La méthode ''POST'' =
== Envoie d'information ==
Très similaire à la méthode ''GET'' à la différence que les tuples sont envoyé dans le corps de la requête ''HTTP'' et non dans l'URL.
Pour l'utiliser, il suffit de modifier la ligne suivante du fichier ''index.php'' :
<syntaxhighlight lang="php">
<form action="php/traitement.php" method="get">
</syntaxhighlight>
en
<syntaxhighlight lang="php">
<form action="php/traitement.php" method="post">
</syntaxhighlight>
== Réception d'information ==
La récupération des informations ce fait non plus dans le tableau ''$_GET'' mais dans le tableau ''$_POST'' :
<syntaxhighlight lang="php">
<?php

$login = $_POST["login"];
$password = $_POST["password"];

echo "Votre login est : ".$login;
echo "<br>";
echo "Votre mot de passe est : ".$password;
</syntaxhighlight>

= Limitations =
==Une variable manque à l'appel !==
Que se passe t-il si l'un des paramètres manque ? Si, par exemple, il manque le tuple ''password'' comme c'est le cas avec l'URL suivante:

http://localhost/Form/src/php/traitement.php?login=toto

Ci-dessous un extrait du fichier ''/var/log/httpd/error_log''
<pre>
[Mon Jun 27 04:49:56 2016] [error] [client 192.168.100.1] PHP Notice: Undefined index: password in /var/www/html/Form/src/php/traitement.php on line 4
[Mon Jun 27 04:49:56 2016] [error] [client 192.168.100.1] PHP Stack trace:
[Mon Jun 27 04:49:56 2016] [error] [client 192.168.100.1] PHP 1. {main}() /var/www/html/Form/src/php/traitement.php:0
</pre>

Pour ne pas prendre de risque il faudrait tester si l'index existe en utilisant la fonction ''isset'' :
<syntaxhighlight lang="php">
<?php
if (isset ( $_GET ["login"] )) {
$login = $_GET ["login"];
echo "Votre login est : " . $login;
echo "<br>";
}
if (isset ( $_GET ["password"] )) {
$password = $_GET ["password"];
echo "Votre mot de passe est : " . $password;
}
</syntaxhighlight>
==Ma variable est vide !==
Que se passe t-il si la variable est vide ? Si, par exemple, le tuple ''password'' ne possède pas de valeur comme c'est le cas avec l'URL suivante:

http://localhost/Form/src/php/traitement.php?login=toto&password

Aucune erreur n'est générée mais le reste du code risque de ne pas fonctionner correctement...
Il faudrait tester si la variable n'est pas vide grâce à la fonction ''empty''

<syntaxhighlight lang="php">
if (isset ( $_GET ["login"] )) {
$login = $_GET ["login"];
if (! empty ( $login )) {
echo "Votre login est : " . $login;
echo "<br>";
}
}
if (isset ( $_GET ["password"] )) {
$password = $_GET ["password"];
if (! empty ( $password )) {
echo "Votre mot de passe est : " . $password;
}
}
</syntaxhighlight>
== Réfléxion... ==
Pour ce formulaire composé de seulement deux champs on constate que la quantité de code qu'il faut écrire, si on veut faire un traitement efficace des valeurs, est colossale.
On imagine facilement que plus il y aura de champs plus cela sera pénible...

Il faudrait un moyen, pas trop compliqué, de savoir si une variable existe et si elle à une valeur. On va en profiter pour gérer le cas des nombre, en effet, le chiffre ''0'' est considéré comme ''empty''.

Nous allons écrire deux fonctions pour cela dans le fichier ''php/helper.php'' :

<syntaxhighlight lang="php">
<?php
function getVar($name) {
if (isset ( $_GET [$name] )) {
if(is_numeric($tab[$name])){
return $tab[$name];
}
if (! empty ( $_GET [$name] )) {
return $_GET [$name];
}
return TRUE;
}
return FALSE;
}

function postVar($name) {
if (isset ( $_POST [$name] )) {
if(is_numeric($tab[$name])){
return $tab[$name];
}
if (! empty ( $_POST[$name] )) {
return $_POST[$name];
}
return TRUE;
}
return FALSE;
}
</syntaxhighlight>
Bon d'accord ! On peut encore compresser :
<syntaxhighlight lang=php>
<?php
function getVar($name) {
return retrieveVar($name, $_GET);
}
function postVar($name) {
return retrieveVar($name, $_POST);
}
function retrieveVar($name, $tab){
if (isset($tab[$name])) {
if(is_numeric($tab[$name])){
return $tab[$name];
}
if (! empty($tab[$name])) {
return $tab[$name];
}
return TRUE;
}
return FALSE;
}
</syntaxhighlight>

Ces fonctions renvoies :
* faux si la variable n'existe pas ;
* vrai si elle existe mais est vide ;
* sinon sa valeur.

La philosophie est simple:
* soit on à besoin que la variable '''existe''' et on fait le test suivant :
<syntaxhighlight lang="php">
$var = getVar("var");

// Si différent de faux, la variable existe avec une valeur ou non !
if($var !== FALSE){
...
}
</syntaxhighlight>
* soit il faut '''absolument''' une valeur on fait le test suivant :
<syntaxhighlight lang="php">
$var = getVar("var");

// Si la variable n'est pas un booleen, elle à une valeur !
if(!is_bool($var)){
...
}
</syntaxhighlight>

Voyez comme le code est plus clair, simple, efficace :

<syntaxhighlight lang="php">
<?php
include 'helper.php';

$login = getVar ( "login" );
$password = getVar ( "password" );

if (! is_bool ( $login )) {
echo "Votre login est : " . $login;
echo "<br>";
}
if (! is_bool ( $password )) {
echo "Votre mot de passe est : " . $password;
}
</syntaxhighlight>

= Interaction =
==Redirection après vérification==
Il faudrait maintenant tester les valeurs des champs pour confirmer ou infirmer l'authentification. Pour ce faire, nous allons modifier la page ''traitement.php'':
<syntaxhighlight lang="php">
<?php
include 'helper.php';

// Valeur par défaut
$stored_login = "root";
$stored_password = "toor";

$login = getVar ( "login" );
$password = getVar ( "password" );

if (! is_bool ( $login ) && ! is_bool ( $password )) {
if($login == $stored_login && $password == $stored_password){
// Authentification réussie
return header("Location: ../logged.php");
}
}
// Authentification échoué
header("Location: ../index.php");
</syntaxhighlight>
Dans ce script :
* on définit au début les valeurs du couple login / mot de passe mais on aurait pu récupérer ces valeur dans une base de données;
* on utilise la fonction ''header'' avec la valeur ''Location'' qui permet de '''rediriger le navigateur''' en ajoutant un ''header HTTP'' à la réponse.
Si l'authentification se passe correctement, on est redirigé vers la page ''logged.php'' (que nous allons créer), si elle échoue on revient sur la page ''index.php'' pour faire une nouvelle tentative de connexion.
Voici le code de la page ''logged.php'':
<syntaxhighlight lang="php">
<?php

echo "Authentification réussie !";
</syntaxhighlight>
==User eXperience==
En UX, on s'intéresse beaucoup à l'utilisateur et son ressenti. Que va t-il se passer si l'authentification échoue ? Il sera redirigé tellement vite sur la page ''index.php'' qu'il aura l'impression que rien ne s'est passé... Il faut absolument que la page ''index.php'' affiche un message qui informe de l'échec de l'authentification !

C'est ''traitement.php'' qui détient l'information de l’échec ou de la réussite de l'authentification... Il faudrait que cette page transmette l'information à ''index.php'' ! Comment faire... avec un ''GET'' mais, cette fois, sans formulaire et uniquement en modifiant l'URL de redirection en cas d'échec. Dans le fichier ''traitement.php'' modifiez la ligne suivante :
<syntaxhighlight lang="php">
<?php
// Authentification échoué
header("Location: ../index.php");
</syntaxhighlight>
en
<syntaxhighlight lang="php">
<?php
// Authentification échoué
header("Location: ../index.php?echec");
</syntaxhighlight>
Il suffit maintenant de récupérer l'information dans la page ''index.php''. Ajouter, au dessus de la ''div'' existante, le code suivant :
<syntaxhighlight lang="php">
<div align="center">
<?php
include 'php/helper.php';
$echec = getVar("echec");
if($echec !== FALSE){
echo "Echec de l'authentification !";
}
?>
</div>
</syntaxhighlight>
Lorsque l'on échoue l'authentification, un message s'affiche !
= Les sessions =
Les sessions en PHP permettent de mémoriser des informations dans le tableau $_SESSION accessible après l'appel de la fonction ''session_start''.
Ce tableau est unique pour chaque connexion et ne peut être partagé entre plusieurs clients.
== Mémoire d'éléphant ==
Si on essaye d'accéder à la page ''logged.php'' sans passer par la page ''index.php''... cela fonctionne.

Il faut absolument que notre application web se souvienne si la personne est authentifiée sinon elle doit rediriger vers ''index.php''. Nous allons utiliser les ''sessions'' pour doter notre application Web d'une mémoire !

Dans la page ''traitement.php'' modifiez les lignes suivantes :
<syntaxhighlight lang="php">
// Authentification réussie
session_start();
$_SESSION["logged"] = true;
return header("Location: ../logged.php");
</syntaxhighlight>

Pour accéder à cette variable nous allons utiliser une fonction, comme pour ''GET'' et ''POST'', que nous allons placer dans le fichier ''helper.php'' :
<syntaxhighlight lang="php">
function sessionVar($name) {
if (session_status() !== PHP_SESSION_ACTIVE) {
session_start();
}
if (isset ( $_SESSION [$name] )) {
if (! empty ( $_SESSION [$name] )) {
return $_SESSION [$name];
}
return TRUE;
}
return FALSE;
}
</syntaxhighlight>
ou pour reprendre l'exemple plus haut :
<syntaxhighlight lang=php>
function sessionVar($name) {
if (session_status() !== PHP_SESSION_ACTIVE) {
session_start();
}
return retrieveVar($name, $_SESSION);
}
</syntaxhighlight>
La fonction ''session_status'' permet de connaître le statut d'une session est peut prendre plusieurs valeurs :
*PHP_SESSION_DISABLED : si les sessions sont désactivées sur le serveur;
*PHP_SESSION_NONE : si les sessions sont actives mais qu'aucune n'existe;
*PHP_SESSION_ACTIVE : si une session existe
Cette fonction est très utile car elle nous permet de tester l’existence d'une session avant de la démarrer. Php lèvera une notification si on appel deux fois de suite à la fonction ''session_start'' :
<pre>
PHP Notice: A session had already been started - ignoring session_start()
</pre>
Il ne nous reste plus qu'à récupérer cette valeur dans la page ''logged.php'' et à rediriger les ''petits malin'' non authentifiés vers la page ''index.php'':
<syntaxhighlight lang=php>
<?php
include 'php/helper.php';
$logged = sessionVar("logged");
if($logged === FALSE){
return header("Location: index.php");
}
echo "Authentification réussie !";
</syntaxhighlight>

== Perte de mémoire !==
Si on veut déconnecter l'utilisateur de l'application il faut ''oublier'' qu'il est connecté et, pour cela, il faut utiliser la fonction ''session_destroy''.
Nous allons créer une page ''php/unlog.php'' qui contiendra les lignes suivantes :
<syntaxhighlight lang=php>
<?php
session_start();
session_destroy();
header("Location: index.php");
</syntaxhighlight>
Dans cette page on :
* démarre la session;
* détruit la session;
* redirige l'utilisateur vers ''index.php''
Il ne reste plus qu'à mettre un lien dans la page ''logged.php'', a la fin du fichier :
<syntaxhighlight lang=php>
echo "<br>";
echo "<a href='php/unlog.php' >déconnexion</a>";
</syntaxhighlight>
Pour résumer :
* session_start : permet de démarrer une session;
* session _status : permet de connaître l'état d'une session;
* session_destroy : permet de détruire une session.

=Pour aller plus loin=
On pourrait même modifier l'URL pour que la page ''index.php'' affiche le message suivant : ''Vous devez être connecté pour voir cette page !'' :
* sur la page ''logged.php'' modifiez la ligne suivante :
<syntaxhighlight lang=php>
return header("Location: index.php?unlogged");
</syntaxhighlight>
* sur la page ''index.php'' modifiez les lignes suivantes :
<syntaxhighlight lang=php>
<?php
include 'php/helper.php';
if(getVar("echec")!== FALSE){
echo "Echec de l'authentification !";
}else if(getVar("logged")!== FALSE){
echo "Vous devez être connecté pour voir cette page !";
}
?>
</syntaxhighlight>

Proxmox fail2ban

2025-12-14T10:06:20Z

Jc.forton :

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 3
findtime = 2d
bantime = 1h
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>
== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Tests =
Il faut maintenant tester le filtre et pour ça on peut utiliser un partage de connexion et réaliser le nombre d'échecs spécifié par la directive "maxretry" (ici 3) :
<pre>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 3
| `- Journal matches: _SYSTEMD_UNIT=pvedaemon.service
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 37.167.23.159
</pre>
On voit bien l'IP 37.167.23.159 qui est bannie !
N'oubliez pas de l'ajouter à ''ignoreip'' dans le fichier ''jails.local'' ou de faire
<pre>
# fail2ban-client unban 37.167.23.159
</pre>

= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification.
Il est donc plus simple de faire un ''tail'' ou un ''cat'':
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Que d'utiliser ''journalctl'' pour voir les IPs :
<pre>
# journalctl -fu pvedaemon
Dec 14 10:43:01 labo unix_chkpwd[1326506]: password check failed for user (root)
Dec 14 10:43:01 labo IPCC.xs[1320783]: pam_unix(proxmox-ve-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=37.167.23.159 user=root
Dec 14 10:43:03 labo pvedaemon[1320783]: authentication failure; rhost=37.167.23.159 user=root@pam msg=Authentication failure
</pre>
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête '''uniquement''' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<source lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</source>
C'est un peu plus loin qu'il faut insérer le code :
<source lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</source>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<source lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</source>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<source lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</source>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<source lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</source>
Il ne reste plus qu'à le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

Proxmox fail2ban

2025-12-14T10:02:32Z

Jc.forton : /* Tests */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 3
findtime = 2d
bantime = 1h
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>
== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Tests =
Il faut maintenant tester le filtre est pour ça on peut utiliser un partage de connexion et réaliser le nombre d'échecs spécifié par la directive "maxretry" (ici 3) :
<pre>
# fail2ban-client status proxmox
Status for the jail: proxmox
|- Filter
| |- Currently failed: 0
| |- Total failed: 3
| `- Journal matches: _SYSTEMD_UNIT=pvedaemon.service
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 37.167.23.159
</pre>
On voit bien l'IP 37.167.23.159 qui est bannie !
N'oubliez pas de l'ajouter à ''ignoreip'' dans le fichier ''jails.local'' ou de faire
<pre>
# fail2ban-client unban 37.167.23.159
</pre>

= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification.
Il est donc plus simple de faire un ''tail'' ou un ''cat'':
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Que d'utiliser ''journalctl'' pour voir les IPs :
<pre>
# journalctl -fu pvedaemon
Dec 14 10:43:01 labo unix_chkpwd[1326506]: password check failed for user (root)
Dec 14 10:43:01 labo IPCC.xs[1320783]: pam_unix(proxmox-ve-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=37.167.23.159 user=root
Dec 14 10:43:03 labo pvedaemon[1320783]: authentication failure; rhost=37.167.23.159 user=root@pam msg=Authentication failure
</pre>
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête ''uniquement'' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<source lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</source>
C'est un peu plus loin qu'il faut insérer le code :
<source lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</source>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<source lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</source>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<source lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</source>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<source lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</source>
Il ne plus qu'a le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

Proxmox fail2ban

2025-12-14T10:00:17Z

Jc.forton : /* Filtre pour PVEPROXY */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 3
findtime = 2d
bantime = 1h
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>
== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Tests =
Il faut maintenant tester le filtre est pour ça on peut utiliser un partage de connexion et réaliser le nombre d'échecs spécifié par la directive "maxretry"

= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification.
Il est donc plus simple de faire un ''tail'' ou un ''cat'':
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Que d'utiliser ''journalctl'' pour voir les IPs :
<pre>
# journalctl -fu pvedaemon
Dec 14 10:43:01 labo unix_chkpwd[1326506]: password check failed for user (root)
Dec 14 10:43:01 labo IPCC.xs[1320783]: pam_unix(proxmox-ve-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=37.167.23.159 user=root
Dec 14 10:43:03 labo pvedaemon[1320783]: authentication failure; rhost=37.167.23.159 user=root@pam msg=Authentication failure
</pre>
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête ''uniquement'' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<source lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</source>
C'est un peu plus loin qu'il faut insérer le code :
<source lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</source>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<source lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</source>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<source lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</source>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<source lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</source>
Il ne plus qu'a le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

Proxmox fail2ban

2025-12-14T09:56:21Z

Jc.forton : /* Proxification */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 3
findtime = 2d
bantime = 1h
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>
== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification.
Il est donc plus simple de faire un ''tail'' ou un ''cat'':
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Que d'utiliser ''journalctl'' pour voir les IPs :
<pre>
# journalctl -fu pvedaemon
Dec 14 10:43:01 labo unix_chkpwd[1326506]: password check failed for user (root)
Dec 14 10:43:01 labo IPCC.xs[1320783]: pam_unix(proxmox-ve-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=37.167.23.159 user=root
Dec 14 10:43:03 labo pvedaemon[1320783]: authentication failure; rhost=37.167.23.159 user=root@pam msg=Authentication failure
</pre>
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête ''uniquement'' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<source lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</source>
C'est un peu plus loin qu'il faut insérer le code :
<source lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</source>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<source lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</source>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<source lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</source>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<source lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</source>
Il ne plus qu'a le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

Proxmox fail2ban

2025-12-14T09:55:56Z

Jc.forton : /* Proxification */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 3
findtime = 2d
bantime = 1h
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>
== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
{|style="width:100%" align="center"
|
[[Fichier:Warning-icon.png|centré|60px]]
|valign="top"|
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification.
Il est donc plus simple de faire un ''tail'' ou un ''cat'':
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Que d'utiliser ''journalctl'' pour voir les IPs :
<pre>
# journalctl -fu pvedaemon
Dec 14 10:43:01 labo unix_chkpwd[1326506]: password check failed for user (root)
Dec 14 10:43:01 labo IPCC.xs[1320783]: pam_unix(proxmox-ve-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=37.167.23.159 user=root
Dec 14 10:43:03 labo pvedaemon[1320783]: authentication failure; rhost=37.167.23.159 user=root@pam msg=Authentication failure
</pre>
|}
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête ''uniquement'' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<source lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</source>
C'est un peu plus loin qu'il faut insérer le code :
<source lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</source>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<source lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</source>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<source lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</source>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<source lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</source>
Il ne plus qu'a le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

Proxmox fail2ban

2025-12-14T09:54:15Z

Jc.forton : /* Proxification */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 3
findtime = 2d
bantime = 1h
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>
== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
{|style="width:100%" align="center"
|
[[Fichier:Warning-icon.png|centré|60px]]
|valign="top"|
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification. Il est donc plus simple de faire un ''tail'' que d'utiliser ''journalctl'' pour voir les IPs
|}
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête ''uniquement'' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<source lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</source>
C'est un peu plus loin qu'il faut insérer le code :
<source lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</source>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<source lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</source>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<source lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</source>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<source lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</source>
Il ne plus qu'a le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

Proxmox fail2ban

2025-12-14T09:53:34Z

Jc.forton : /* Proxification */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 3
findtime = 2d
bantime = 1h
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>
== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
{|style="width:100%" align="center"
|
[[Fichier:Warning-icon.png|centré|60px]]
|valign="top"|
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification
|}
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête ''uniquement'' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<source lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</source>
C'est un peu plus loin qu'il faut insérer le code :
<source lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</source>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<source lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</source>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<source lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</source>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<source lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</source>
Il ne plus qu'a le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

Proxmox fail2ban

2025-12-14T09:53:25Z

Jc.forton : /* Proxification */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 3
findtime = 2d
bantime = 1h
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>
== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
{|style="width:100%" align="center"
|
[[Fichier:Warning-icon.png|centré|60px]]
|valign="top"|
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
...
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
...
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification
|}
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête ''uniquement'' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<source lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</source>
C'est un peu plus loin qu'il faut insérer le code :
<source lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</source>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<source lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</source>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<source lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</source>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<source lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</source>
Il ne plus qu'a le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

Proxmox fail2ban

2025-12-14T09:53:04Z

Jc.forton : /* Proxification */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 3
findtime = 2d
bantime = 1h
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>
== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
{|style="width:100%" align="center"
|
[[Fichier:Warning-icon.png|centré|60px]]
|valign="top"|
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log'' et ''pvedaemon'' ne journalise que les échecs d'authentification
|}
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête ''uniquement'' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<source lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</source>
C'est un peu plus loin qu'il faut insérer le code :
<source lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</source>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<source lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</source>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<source lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</source>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<source lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</source>
Il ne plus qu'a le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

Proxmox fail2ban

2025-12-14T09:50:47Z

Jc.forton : /* Proxification */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 3
findtime = 2d
bantime = 1h
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>
== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
{|style="width:800px" align="center"
|
[[Fichier:Warning-icon.png|centré|30px]]
|valign="top"|
Même si le filtre ''fail2ban'' est configuré pour utiliser la commande ''journactl'' sur le démon ''pvedaemon'':
<pre>
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
Les adresses viennent de pveproxy qui journalise tout dans ''/var/log/pveproxy/access.log''
|}
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête ''uniquement'' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<source lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</source>
C'est un peu plus loin qu'il faut insérer le code :
<source lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</source>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<source lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</source>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<source lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</source>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<source lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</source>
Il ne plus qu'a le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

Proxmox fail2ban

2025-12-14T09:44:52Z

Jc.forton : /* Double IPs ou IPv6 */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 3
findtime = 2d
bantime = 1h
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>
== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête ''uniquement'' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<source lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</source>
C'est un peu plus loin qu'il faut insérer le code :
<source lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</source>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<source lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</source>
=== Double IPv4 ou préfixe IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<source lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</source>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<source lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</source>
Il ne plus qu'a le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

Proxmox fail2ban

2025-12-14T09:41:19Z

Jc.forton : /* Automatisation */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 3
findtime = 2d
bantime = 1h
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>
== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête ''uniquement'' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<source lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</source>
C'est un peu plus loin qu'il faut insérer le code :
<source lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</source>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<source lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</source>
=== Double IPs ou IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<source lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</source>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<source lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
if(\$reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
\$reqstate->{peer_host} = \$1;
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</source>
Il ne plus qu'a le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

Proxmox fail2ban

2025-12-14T09:40:51Z

Jc.forton :

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 3
findtime = 2d
bantime = 1h
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>
== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête ''uniquement'' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<source lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</source>
C'est un peu plus loin qu'il faut insérer le code :
<source lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</source>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<source lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</source>
=== Double IPs ou IPv6 ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/resources HTTP/1.1" 200 1226
::ffff:192.168.20.22 - - [14/12/2025:09:34:42 +0100] "GET /api2/json/cluster/tasks HTTP/1.1" 200 1090
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
::ffff:192.168.20.22 - root@pam [14/12/2025:09:34:42 +0100] "GET /api2/json/nodes/labo/lxc/100/status/current HTTP/1.1" 200 523
</pre>
Il nous reste un peu de nettoyage à faire, dans certains cas :
* l'adresse apparaît non pas une fois mais deux, séparées par une virgule
<pre>
37.167.182.207, 37.167.182.207
</pre>
* l'adresse IPv4 (32 bits) est affichée dans sa représentation IPv6 (128 bits), avec le préfixe ''::ffff:
<pre>
::ffff:192.168.20.22
</pre>

On a deux possibilités pour faire le nettoyage :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<source lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
# Remove trailing ip
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
if($reqstate->{peer_host} =~ /.*\:([\d]*\..*)/) {
# Remove IPv6 subnet for IPv4
$reqstate->{peer_host} = $1;
}
</source>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=.*:?<HOST>,? user=.* msg=.*
...
</pre>

=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<source lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</source>
Il ne plus qu'a le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

Proxmox fail2ban

2025-12-14T08:30:46Z

Jc.forton : /* Automatisation */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 3
findtime = 2d
bantime = 1h
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>
== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête ''uniquement'' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<source lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</source>
C'est un peu plus loin qu'il faut insérer le code :
<source lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</source>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<source lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</source>
=== Double IPs ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_2.css HTTP/1.1" 200 6217
</pre>
L'adresse apparaît non pas une fois mais deux, séparées par une virgule...

On a deux possibilités pour se débarrasser de la virgule ainsi que de la deuxième adresse :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<source lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
</source>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf pour ajouter '',.*'' après ''<HOST>'' :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=<HOST>,.* user=.* msg=.*
...
</pre>
=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant, que l'on peut créer dans /root/remoteip_fix.sh :

<source lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</source>
Il ne plus qu'a le rendre exécutable et le lancer :
<pre>
# chmod +x /root/remoteip_fix.sh
# /root/remoteip_fix.sh
</pre>
Il ne faudra pas oublier de redémarrer ''pveproxy'' pour appliquer les changements !

The Linux Craftsman

2025-12-14T08:28:06Z

Jc.forton : /* La pratique */

= Ce wiki =
<div align="center">
{|class="wikitable" width="100%"
! Le contenu !! Public visé !! L'auteur
|-valign=top
|width="33%"|
Ce wiki propose des articles, cours, TPs et TDs sur des sujets gravitant autour des technologies du système d'information, notamment sur le système Linux, sur la distribution CentOS et maintenant Rocky Linux.

Vous y trouverez des articles traitant de la mise en place de services réseaux tels que DHCP et DNS mais également des articles sur la mise en place de pare-feu, site Web, etc... Il y a un peu de tout et je vous encourage à utiliser le champ de recherche pour trouver ce dont vous avez besoin.
|width="33%"|

Ce wiki s'adresse principalement à mes élèves mais il peut également servir à des enseignants qui désirent monter leurs cours sans se "prendre la tête".

Tout est disponible sous [http://www.gnu.org/copyleft/fdl.html licence GNU Free Documentation License 1.3] ou ultérieure et vous pouvez récupérer les contenus et en faire ce que vous voulez !
|width="33%"|

Je m'appelle Jean-Christophe FORTON et je suis professeur d'informatique depuis 2011 mais cela n'a pas toujours été mon métier, plus d'info [[jcf|ici]]...

N'hésitez pas à faire un tour sur :
{|
|-valign=middle
|align=center|
[[Image:Logo-YouTube-rouge.png|30px|link=https://www.youtube.com/@tala-informatique]]
|| ma chaîne Youtube pour découvrir mes aventures ou (re)visionner certains cours
|-valign=middle
|align=center|
[[Fichier:Logo-Tipeee.png|27px|link=https://fr.tipeee.com/tala-informatique]]
||mon Tipeee pour me remercier
|}
|}
</div>

= Les cours =
<div align="center">
{|class="wikitable" width="100%"
! Système !! Sécurité !! Réseaux !! Développement !! Général
|-valign=top
||
<hr>
<div align="center">Linux</div>
<hr>
* [[:Media:intro_linux.pdf|Introduction au système Linux]]
* [[:Media:tp_linux_commandes_de_bases.pdf|TP Linux : commandes de bases]]
<hr>
<div align="center">Windows</div>
<hr>
* Architecture des ordinateurs en environnement Windows
** [[:Media:materiel.pdf|Le matériel]]
** [[:Media:system_exploitation.pdf|Le système d'exploitation]]
** [[:Media:gestion_disques.pdf|La gestion des disques]]
** [[:Media:sauvegarde.pdf|La sauvegarde]]
* Active Directory
** [[:Media:ad_intro.pdf|Les principes fondamentaux]]
** [[:Media:ad_gpo.pdf|Gestion des stratégies]]
||
<hr>
<div align="center">Réseaux</div>
<hr>
* [[:Media:Les pare-feux.pdf|Les pare-feux]]
* [[:Media:Les pare-feux_tech.pdf|Les pare-feux (fiche technique)]]
* [[:Media:Les VPN.pdf|Les VPN]]
* [[:Media:Haute_dispo.pdf|Haute disponibilité]]
* [[:Media:sauvegarde_pca.pdf|La sauvegarde]]
<hr>
<div align="center">Sécurité des Systèmes d’Information</div>
<hr>
* [[:Media:principes_SSI.pdf|Les principes fondamentaux]]
* [[:Media:implémentation_concrete_SSI.pdf|Implémentation concrète de la sécurité]]
* [[:Media:cryptographie.pdf|Cryptographie]]
* [[:Media:TD1_SSI.pdf|TD1: Principes Fondamentaux]]
* [[:Media:TP1_SSI.pdf|TP1: Écoute d'une connexion]]
* [[:Media:TP2_SSI.pdf|TP2: Chiffrement asymétrique avec PGP]]
<hr>
<div align="center">Web</div>
<hr>
* [[:Media:apache server.pdf|Le serveur Apache]]
* [[:Media:pilotage web bdd.pdf|Pilotage d'une page web]]
* [[:Media:web app security.pdf|Sécurité des applications Web]]
||
<hr>
<div align="center">Modèle OSI</div>
<hr>
*[[:Media:OSI.pdf|Le modèle OSI en version cours]]
*[[:Media:OSI_Slides.pdf|Le modèle OSI en version slides]]
<hr>
<div align="center">OSI 1 </div>
<hr>
* [[:Media:Normes_cablages.pdf|Les normes de câblage]]
<hr>
<div align="center">OSI 2</div>
<hr>
* [[:Media:Ethernet-802.3.pdf|La norme Ethernet (802.3)]]
* [[:Media:WiFi-802.11.pdf|La norme Wi-Fi (802.11)]]
* [[:Media:Bridge.pdf|Les bridges]]
* [[:Media:STP.pdf|Spanning Tree Protocol]]
* [[:Media:VLAN.pdf|Les Vlans]]
<hr>
<div align="center">OSI 3+</div>
<hr>
* Routage:
** [[:Media:CIDR.pdf|Classless Inter-Domain Routing]]
** [[:Media:resume_protocoles_vecteur_distance.pdf|Résumé sur les protocoles à vecteur de distance]]
** [[:Media:EIGRP.pdf|Enhanced Interior Gateway Routing Protocol]]
** [[:Media:OSPF.pdf|Open Shortest Path First]]
** [[:Media:BGP.pdf|Border Gateway Protocol]]
*Services:
** [[:Media:DHCP.pdf|DHCP]]
** [[:Media:DNS.pdf|DNS]]
** [[:Media:SAMBA.pdf|Samba]]
<hr>
<div align="center">Qualité de service</div>
<hr>
* [[:Media:QoS.pdf|La QoS]]
* [[:Media:Iproute2_QoS.pdf|Iproute2 et la QoS]]
<hr>
<div align="center">Protocole</div>
<hr>
* [[:Media:HTTP.pdf|HTTP]]
* [[:Media:SNMP.pdf|SNMP]]
||
<hr>
<div align="center">L'algorithmique</div>
<hr>
* [[:Media:algo_intro.pdf|Introduction]]
* [[:Media:algo_langage.pdf|Le Langage]]
<hr>
<div align="center">SQL</div>
<hr>
* [[:Media:conception_bdd.pdf|Conception de base de données]]
* [[:Media:conception_bdd_simple.pdf|Conception de base de données (simplifié)]]
* [[:Media:langage_de_requête.pdf|Langage de requête]]
<hr>
<div align="center">Langages du Web</div>
<hr>
* [[:Media:HTML xHTML intro.pdf|Le langage HTML]]
* [[:Media:css.pdf|Le langage CSS]]
* [[:Media:javascript.pdf|Le langage JavaScript]]
* [[:Media:php.pdf|Le langage PHP]]
<hr>
<div align="center">Langage bas niveau</div>
<hr>
* [[:Media:C lang.pdf|Le langage C]]
<hr>
<div align="center">Architecture SOA</div>
<hr>
* [[:Media:webservices.pdf|Les Web Services RESTful]]
<hr>
<div align="center">Informatique embarquée</div>
<hr>
* [[:Media:arduino_avr.pdf|Arduino et AVR]]
* [[:Media:IOT.pdf|L'Internet des objets]]
||
<hr>
<div align="center">Gestion</div>
<hr>
* [[:Media:gestion_projet.pdf|Gestion de projet]]
<hr>
<div align="center">Bureautique</div>
<hr>
* [[:Media:powerpoint.pdf|PowerPoint]]
* [[:Media:excel.pdf|Excel]]
* [[:Media:bdd_com.pdf|Les bases de données]]
<hr>
<div align="center">Histoire / évolutions</div>
<hr>
* [[:Media:expertise_codage.pdf|Expertise codage]]
|}
</div>

= La pratique =
<div align="center">
{|class="wikitable" width="100%"
! Système !! Sécurité !! Réseaux !! Développement !! Embarquée !! Virtualisation
|-valign="top"
|align=left|
<hr>
<div align="center">Général</div>
<hr>
* [[Installation de CentOS]]
* [[Installation de Rocky]]
* [[migration_centos8torocky8| Migration CentOS 8 → Rocky 8]]
* [[upgrade_rocky8to9| Upgrade Rocky 8 → 9]]
* [[WSL | WSL : Installation de Linux sur Windows 10]]
* [[Vi / Vim]]
* [[linux_repository|Les dépots (EPEL, EL, ...)]]
* [[cron| Gestionnaire des tâches: cron]]
* [[rpm_yum| Gestionnaires de paquetages: RPM & YUM]]
* [[Les logs]]
* [[users_groups|Utilisateurs et groupes]]
* [[Gestion des disques]]
* CentOS ≥ 7 (≈ Rocky) [[Fichier:Warning-icon.png|20px]]
** [[systemctl|Systemctl sur SystemD]]
** [[systemctl service|Créer un service avec Systemctl (démon)]]
** [[iptables_on_systemd | Firewalld ?!? Rendez moi Iptables ! ]]
** [[chrony|''NTP'' est mort, vive ''Chrony'']]
* CentOS 6
** [[Gestionnaire de démarrage|Gestionnaire de démarrage SysVInit]]
** [[start_stop_daemon|Création d'un service avec start-stop-daemon (SysVInit)]]
<hr>
<div align="center">Réseaux</div>
<hr>
* [[ifcfg-ethX|Les interfaces réseaux]]
* [[sysconfig-network|Les paramètres réseaux]]
* [[resolv.conf|Configuration du client DNS]]
* [[ntpd|Configuration du client NTP]]
<hr>
<div align="center">Haute disponibilité</div>
<hr>
* [[drbd|Réplication à chaud avec DRBD]]
<hr>
<div align="center">Multimédia</div>
<hr>
* [[DLNA|Partage de contenu cross-platform avec DLNA]]
|
<hr>
<div align="center">Réseaux</div>
<hr>
* [[Iptables]]
* [[Squid]]
* [[Snort]]
* [[:Media:Chillispot.pdf|Hotspot avec Chillispot]]
* [[Sécuriser un service avec Fail2ban]]
* [[Openvpn]]
* [[Wireguard]]
<hr>
<div align="center">Système</div>
<hr>
* [[SSH]]
* [[SELinux]]
|
<hr>
<div align="center">Les outils</div>
<hr>
* [[tcpdump | Le scanner ''tcpdump'']]
* [[iproute2 | Contrôle réseau avec la commande ''ip'']]
<hr>
<div align="center">OSI 2</div>
<hr>
* [[source routing|Le routage source]]
* [[bridge|Les bridges]]
* [[alias|Les alias]]
* [[vlan|Les vlans]]
* [[one-arm_router|La passerelle ''one-arm'']]
* [[transparent_firewall|Le proxy ''transparent'']]
<hr>
<div align="center">OSI 3+</div>
<hr>
* Services:
** [[DHCP]]
** [[DNS]]
*Haute-disponibilité
** [[Ucarp]]
<hr>
<div align="center">OSI 7</div>
<hr>
* Services:
** [[SAMBA]]
** [[HTTPD]]
** [[xmpp | Serveur XMPP avec Ejabberd]]
** [[vnc|Installer un serveur VNC]]
* Industrialisation:
** [[:Media:pxe.pdf|Monter un serveur PXE (pdf)]]
** [[PXE|Monter un serveur PXE]]
* Supervision
** [[Nagios| Nagios]]
** [[Cacti| Installer un serveur Cacti]]
** [[SNMP | Utiliser SNMP]]
<hr>
<div align="center">Cisco ISR (routeur)</div>
<hr>
* [[ISR-basics|Les bases]]
|
<hr>
<div align="center">Général</div>
<hr>
* [[eclipse_install|Mise en place de l'environnement de développement]]
* [[svn|Serveur de version SVN]]
<hr>
<div align="center">PHP</div>
<hr>
*Les basiques :
** [[php_httpd_install | Installation sous Linux]]
** [[php_devel| Premier projet en ''PHP'']]
** [[php_algo|Un peu d'algorithmique]]
** [[php_object| Les objets]]
** [[php_xdebug| Debugger avec ''Xdebug'']]
** [[phpunit| Les tests en PHP]]
* La partie CLI :
** [[php_memcached| Memcached un serveur de cache]]
** [[php_daemon | Écriture d'un démon]]
** [[php_socket | Utilisation des sockets]]
* La partie Web :
** [[php_$get_$post_$session| Passer des informations entres pages]]
** [[php_pdo| Utiliser une base MySQL avec PDO]]
** [[php_slim | Le framework SLIM]]
<hr>
<div align="center">JavaScript</div>
<hr>
*Les basiques :
** [[js_devel| Premier projet en ''JavaScript'']]
** [[js_algo| Un peu d'algorithmique]]
** [[js_object| Les objets]]
*Les RIA (''R''ich ''I''nternet ''A''pplication) :
** [[js_AJAX| Client AJAX pour utiliser des Web Services]]
** [[js_AJAX_auth | Authentification avec un client AJAX]]
** [[js_AJAX_fetch_api | Découverte de l'API ''fetch'']]
<hr>
<div align="center">Java</div>
<hr>
*Les basiques :
** [[java_devel| Premier projet en ''Java'']]
** [[java_jar|Mon premier objet]]
** [[java_algo| Un peu d'algorithmique]]
** [[junit| Les tests en Java]]
* La partie Web:
** [[java_servlet|Les Servlets]]
** [[java_ws_restful| Web Service Restful]]
* Stocker des informations:
** [[java_mysql| Utiliser une base MySQL avec Java]]
** [[java_memcached| Memcached un serveur de cache]]
<hr>
<div align="center">C</div>
<hr>
*Les basiques :
** [[c_devel| Premier projet en ''C'']]
** [[c_devel_cross| Compilation croisée (Cross Compilation)]]
** [[c_algo| Un peu d'algorithmique]]
*Execution parallèle :
** [[c_pthread| Les threads]]
** [[c_fork| Les forks]]
* IPC:
** [[c_pipe| Les tubes]]
** [[c_semaphore| Les sémaphores]]
** [[c_signals| Les signaux POSIX]]
** [[c_socket| Les sockets]]
* GP-GPU avec CUDA:
** [[cuda_install| Installation de CUDA]]
** [[cuda_hello_world| Les concepts et bases]]
<hr>
<div align="center">Python</div>
<hr>
* [[python_devel| Premier projet en ''Python'']]
* [[python_algo|Un peu d'algorithmique]]
<hr>
<div align="center">SQL</div>
<hr>
* [[sql_install| Installation d'un SGBDR]]
* [[SQL_import| Importation d'une base de données]]
|
<hr>
<div align="center">Général</div>
<hr>
* [[Arduino_sketch_writing | Écriture d'un sketch]]
* [[Arduino_CH340_driver_install | Installation du pilote CH340 (Serial TTL)]]
* [[Arduino_FTDI_driver_install | Installation du pilote FTDI(Serial TTL)]]
* [[Arduino_CP210X_driver_install | Installation du pilote CP210X(Serial TTL)]]
* [[Arduino_Eclipse_sketch | Création d'un projet sous Eclipse]]
* [[arduino_diagram | Schémas des cartes Arduino]]
* [[esp8266_diagram | Schémas des cartes ESP8266]]
* [[esp32_diagram | Schémas des cartes ESP32]]
* [[sbc_diagram | Schémas des SBC]]
* [[µc_datasheet | Fiches techniques des microcontrôleurs]]
<hr>
<div align="center">Capteurs</div>
<hr>
* [[Arduino_LDR | Luminosité avec une photorésistance]]
* [[Arduino_BH1750 | Luminosité avec le BH1750]]
* [[Arduino_DS18B20 | Température avec le DS18B20]]
* [[Arduino_LM35DZ | Température avec le LM35]]
* [[Arduino_DHT11 | Température et humidité avec le DHT11]]
* [[Arduino_BMP280 | Température, pression et altitude avec le BMP280]]
* [[Arduino_A3144 | Effet de Hall (magnétisme) avec le A3144 ]]
* [[Arduino_SR501 | Détection de mouvement avec le SR501 (PIR) ]]
* [[Arduino_soil_moisture | Capteur d'humidité du sol ]]
<hr>
<div align="center">Communication</div>
<hr>
* Sans-fil:
** [[Arduino_HC12 | Communication RF433 avec un HC12]]
** [[Arduino_NRF24L01 | Communication 2.4Ghz avec un NRF24L01]]
** [[Arduino_ESP05 | Communication Wi-Fi avec un ESP-05]]
* Shield Ethernet (W5100):
** [[Arduino_W5100_intro | Présentation du shield]]
** [[Arduino_W5100_OSI3 | Configuration OSI 3]]
** [[Arduino_W5100_web_server | Utilisation du Shield Ethernet pour faire un serveur Web]]
<hr>
<div align="center">Composants et montages divers</div>
<hr>
* [[ potentiometre | Potentiomètre ]]
* [[ shift_register | Registre à décalage ]]
* [[ Arduino_2axis_joystick_button | Joystick 2 axes avec bouton ]]
* [[ Arduino_SD_CARD | Module pour cartes SD ]]
<hr>
<div align="center">ESP8266 / ESP32</div>
<hr>
* [[esp_ide_arduino | Cartes ESP et IDE Arduino]]
* [[esp8266_wifi | Utilisation du WiFi ]]
* [[esp8266_webserver | Utilisation du serveur web ]]
* [[esp8266_udp_server | Serveur UDP ]]
* [[esp8266_ntp_client | Client NTP ]]
* [[:Media:esp8266_tp_meteo_dht11.pdf | TP station météo avec le DHT11 ]]
<hr>
<div align="center">Raspberry / Banana / Orange Pi</div>
<hr>
* [[iso_install_sdcard | Installation d'une image ]]
* [[pi_java_install | Mise en place de Java ]]
* [[sbc_qemu_emulation | Émulation avec Qemu ]]
* [[Linux sunxi armbian gpio | Manipulation des GPIO sous Linux]]
* [[Linux sunxi armbian w1 | Utilisation du protocole OneWire sous Linux]]
* [[Linux uart sunxi armbian | Utilisation du protocole UART sous Linux]]
<hr>
<div align="center">Notions avancées</div>
<hr>
* Arduino (ATmega328)
** [[atmega328_registers | Manipulation de registres ]]
** [[atmega328_timers | Les timers ]]
|
<hr>
<div align="center">VmWare</div>
<hr>
* [[vmware_install | Installation ]]
* [[vmware_network | La partie réseau ]]
* [[vmware_create_vm | Création d'une machine virtuelle ]]
* [[vmware_debug_vm | Débogage réseau d'une machine virtuelle]]
<hr>
<div align="center">Proxmox</div>
<hr>
* [[proxmox_install | Installation ]]
* [[proxmox_iptables | Utilisation d'iptables ]]
* [[proxmox_fail2ban | Fail2ban ]]
|}
</div>
<div style="visibility:hidden">
__TOC__
</div>
__NOTOC__

Sécuriser un service avec Fail2ban

2025-12-13T18:30:54Z

Jc.forton : /* Choix de la punition */

= Introduction =
Le but de fail2ban est d'empêcher une attaque par force brute, c'est à dire qu'un individu trouve un tuple identifiant/mot de passe permettant l'accès à un serveur.
Fail2ban va analyser les logs pour compter le nombre de tentatives et bannir l'IP qui essaye de se connecter si elle dépasse le nombre maximal d’essais.

= Installation =
Une fois l'installation du [[Linux_repository#Installation | dépôt EPEL]] terminée, nous pouvons procéder à celle de ''fail2ban'':
<pre>
yum -y install fail2ban
</pre>

= Configuration =

Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps ou l'adresse IP ne peut pas se connecter.

== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Configuration de la section Jail ==
* Sur CentOS 6:
Pour sécuriser le service, il faut repérer sa section jail. Dans cet exemple, nous allons sécuriser ''SSH''.

Nous allons avoir besoin des variables suivantes:
*enabled : permet d'activer le filtrage
*filter : donne un nom au filtre
*action : permet de bloquer le port (ssh) avec une règles Iptables et d'envoyer un mail
*logpath : indique le fichier de log

<pre>
[ssh-iptables]

enabled = true
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
sendmail-whois[name=SSH, dest=MON_EMAIL, sender=fail2ban@MON_DOMAINE, sendername="Fail2Ban"]
logpath = /var/log/secure
</pre>

Remplacez ''MON_EMAIL'' par votre mail ainsi que ''MON_DOMAINE'' par votre domaine !

*Sur CentOS 8:
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>

[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Démarrage et enregistrement dans le chargeur de démarrage =
* Pour SystemVInit:
<pre>
# service fail2ban start
# chkconfig fail2ban on
</pre>
* Pour SystemD:
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>

= Ajout automatique de règles dans Iptables =
Vous pouvez constater que fail2ban ajoute des règles dans la chaîne ''fail2ban-SSH'':

<pre>
Chain fail2ban-SSH (1 references)
pkts bytes target prot opt in out source destination
0 0 REJECT all -- * * 122.225.109.214 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 122.225.109.115 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 61.174.51.212 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 61.174.51.213 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 125.70.0.44 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 61.174.51.210 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 122.226.140.158 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 122.225.109.210 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 222.186.34.117 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 210.14.69.244 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 122.225.109.206 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 74.208.209.116 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 61.174.51.229 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 222.186.34.119 0.0.0.0/0 reject-with icmp-port-unreachable
14 928 REJECT all -- * * 61.55.135.41 0.0.0.0/0 reject-with icmp-port-unreachable
1049 66520 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
</pre>

= Parcours des Logs =
{{#lst:Les_logs|log_fail2ban}}

= Apache =

Voici quelques ajouts intéressants pour le serveur Apache:
<pre>
[apache]
enabled = true
port = http,https
filter = apache-auth
logpath = %(apache_error_log)s

[apache-overflows]
enabled = true
port = http,https
filter = apache-overflows
logpath = %(apache_error_log)s

[apache-dos]
enabled = true
port = http,https
filter = apache-dos
logpath = %(apache_access_log)s
</pre>

Sécuriser un service avec Fail2ban

2025-12-13T18:30:09Z

Jc.forton : /* Choix de la punition */

= Introduction =
Le but de fail2ban est d'empêcher une attaque par force brute, c'est à dire qu'un individu trouve un tuple identifiant/mot de passe permettant l'accès à un serveur.
Fail2ban va analyser les logs pour compter le nombre de tentatives et bannir l'IP qui essaye de se connecter si elle dépasse le nombre maximal d’essais.

= Installation =
Une fois l'installation du [[Linux_repository#Installation | dépôt EPEL]] terminée, nous pouvons procéder à celle de ''fail2ban'':
<pre>
yum -y install fail2ban
</pre>

= Configuration =

Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps ou l'adresse IP ne peut pas se connecter.

== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentative durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Configuration de la section Jail ==
* Sur CentOS 6:
Pour sécuriser le service, il faut repérer sa section jail. Dans cet exemple, nous allons sécuriser ''SSH''.

Nous allons avoir besoin des variables suivantes:
*enabled : permet d'activer le filtrage
*filter : donne un nom au filtre
*action : permet de bloquer le port (ssh) avec une règles Iptables et d'envoyer un mail
*logpath : indique le fichier de log

<pre>
[ssh-iptables]

enabled = true
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
sendmail-whois[name=SSH, dest=MON_EMAIL, sender=fail2ban@MON_DOMAINE, sendername="Fail2Ban"]
logpath = /var/log/secure
</pre>

Remplacez ''MON_EMAIL'' par votre mail ainsi que ''MON_DOMAINE'' par votre domaine !

*Sur CentOS 8:
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>

[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Démarrage et enregistrement dans le chargeur de démarrage =
* Pour SystemVInit:
<pre>
# service fail2ban start
# chkconfig fail2ban on
</pre>
* Pour SystemD:
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>

= Ajout automatique de règles dans Iptables =
Vous pouvez constater que fail2ban ajoute des règles dans la chaîne ''fail2ban-SSH'':

<pre>
Chain fail2ban-SSH (1 references)
pkts bytes target prot opt in out source destination
0 0 REJECT all -- * * 122.225.109.214 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 122.225.109.115 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 61.174.51.212 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 61.174.51.213 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 125.70.0.44 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 61.174.51.210 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 122.226.140.158 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 122.225.109.210 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 222.186.34.117 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 210.14.69.244 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 122.225.109.206 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 74.208.209.116 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 61.174.51.229 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 222.186.34.119 0.0.0.0/0 reject-with icmp-port-unreachable
14 928 REJECT all -- * * 61.55.135.41 0.0.0.0/0 reject-with icmp-port-unreachable
1049 66520 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
</pre>

= Parcours des Logs =
{{#lst:Les_logs|log_fail2ban}}

= Apache =

Voici quelques ajouts intéressants pour le serveur Apache:
<pre>
[apache]
enabled = true
port = http,https
filter = apache-auth
logpath = %(apache_error_log)s

[apache-overflows]
enabled = true
port = http,https
filter = apache-overflows
logpath = %(apache_error_log)s

[apache-dos]
enabled = true
port = http,https
filter = apache-dos
logpath = %(apache_access_log)s
</pre>

Proxmox fail2ban

2025-12-13T18:29:44Z

Jc.forton :

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps où l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcul permet de trouver le nombre maximal de tentatives durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 3
findtime = 2d
bantime = 1h
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>
== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'à spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilise l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête ''uniquement'' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrait ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'à vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jour d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modification peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<source lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</source>
C'est un peu plus loin qu'il faut insérer le code :
<source lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</source>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<source lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</source>
=== Double IPs ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_2.css HTTP/1.1" 200 6217
</pre>
L'adresse apparaît non pas une fois mais deux, séparées par une virgule...

On a deux possibilités pour se débarrasser de la virgule ainsi que de la deuxième adresse :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<source lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
</source>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf pour ajouter '',.*'' après ''<HOST>'' :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=<HOST>,.* user=.* msg=.*
...
</pre>
=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant :

<source lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</source>

Proxmox fail2ban

2025-12-13T18:22:05Z

Jc.forton : /* Automatisation */

= Introduction =
Proxmox utilise une interface web d'administration qui utilise le port TCP 8006 et c'est un vecteur possible d'attaque par force brut. Nous allons donc ''dresser'' fail2ban pour agir en cas d'attaque !

Proxmox utilise Debian, nous allons principalement reproduire les étapes décrites dans le tutoriel de [[Sécuriser_un_service_avec_Fail2ban| Fail2ban pour Rocky]] et adapter à Debian.

Avant d'aller plus loin, assurez-vous d'avoir correctement installé et configuré [[proxmox_iptables |iptables sur Proxmox]]

= Installation =
<pre>
# apt -y install fail2ban
</pre>
= Configuration =
Tout d'abord il faut copier le fichier ''/etc/fail2ban/jail.conf'' en ''/etc/fail2ban/jail.local''

<pre>
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</pre>

Dans ce fichier, on va s'intéresser aux variables suivantes:
*ignoreip : correspond à la suite d'adresses IP qui ne se feront jamais bannir;
*maxretry : correspond au nombre d'essais;
*findtime : correspond à la période pendant laquelle les essais vont incrémenter maxretry;
*bantime : correspond au temps ou l'adresse IP ne peut pas se connecter.

= Configuration de base =
== Choix de la punition ==
Il faut choisir quelque chose de cohérent (une punition suffisante) pour ne pas permettre de se faire cracker son mot de passe:
*maxretry = 3
*findtime = 86400 (correspond à 1 journée)
*bantime = 604800 (correspond à 1 semaine)

Cela signifie que si une adresse IP se trompe 3 fois en 1 journée (86400s) elle se fait bannir pendant 1 semaine (604800s).

Un rapide calcule permet de trouver le nombre maximal de tentative durant une année:

365 jours / 7 jours par semaine * 3 tentatives = 156 essais, ce qui reste raisonnable.

Si le pirate possède un [http://fr.wikipedia.org/wiki/Botnet botnet], il faut bien sûr multiplier ce nombre par le nombre de machines dans le botnet...

'''Attention : fail2ban parcours les logs de connexion pour connaître le numéro de la tentative, ce qui a pour conséquence, si le ''findtime'' est grand, de prendre un certain temps...'''

== Jail pour SSH ==
Il suffit d'ajouter la ligne ''enabled=true'' dans la section à activer !
<pre>
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
</pre>

= Configuration spécifique =
== Jail pour PVEPROXY ==
Pveproxy écoute sur le port 8006 et ne fonctionne pas exactement comme un serveur [[HTTPD | Apache httpd]] qui mettrait ces logs dans le fichier ''error_log''.

Nous allons mettre cette configuration spécifique dans le fichier ''/etc/fail2ban/jail.d/proxmox.conf'' :
<pre>
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 3
findtime = 2d
bantime = 1h
</pre>

Le backend utilisé est systemd, exactement comme si vous utilisiez la commande :
<pre>
# journalctl -fu pvedaemon
</pre>
== Filtre pour PVEPROXY ==
Il ne nous reste plus qu'a spécifier le filtre ''proxmox'' dans le fichier ''/etc/fail2ban/filter.d/proxmox.conf'' :
<pre>
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
</pre>
= Démarrage et enregistrement dans le chargeur de démarrage =
<pre>
# systemctl start fail2ban.service
# systemctl enable fail2ban.service
</pre>
Vous pouvez maintenant démarrer fail2ban

= Proxification=
Lorsque votre serveur Proxmox se trouve derrière un reverse-proxy (Apache, Nginx, Traefik, ...), au niveau 3 OSI, l'adresse IP du client est remplacée par celle du proxy et le serveur utilse l'entêtes ''X-Forwarded-For'' ou ''X-Real-IP'' pour transporter l'adresse du client
[[Fichier:Reverse proxy proxmox.png|700px|centré]]
Le problème est que la seule adresse que fail2ban va voir apparaître dans les logs est celle du reverse-proxy (''192.168.4.100'') :
[[Fichier:Reverse proxy ip logs.png|600px|centré]]
== Configuration de pveproxy ==
Si on veut voir l'adresse du client, il faut dire au [https://fr.wikipedia.org/wiki/Daemon_(informatique)| démon] ''pveproxy'' d'utiliser l'une des deux entêtes précédentes ainsi que préciser l'adresse du proxy.

Préciser l'adresse du proxy est essentiel pour que ''pveproxy'' n'accepte de lire l'adresse du client présente dans l'entête ''uniquement'' si cela provient du proxy, qui est une machine de confiance. Le cas contraire, tout le monde pourrais ajouter une adresse IP dans l'entête pour la faire bannir...

Nous allons créer le fichier ''/etc/default/pveproxy'' avec les lignes suivantes:
<pre>
PROXY_REAL_IP_HEADER="X-Forwarded-For"
PROXY_REAL_IP_HEADER="X-Real-IP"
PROXY_REAL_IP_ALLOW_FROM="192.168.4.100"
</pre>
Il faut maintenant redémarrer ''pveproxy'' pour que les changements s'appliquent. Si vous êtes connecté via l'interface web, cela va vous déconnecter, le temps que le démon redémarre, il faudra ensuite certainement rafraîchir la page web.
<pre>
# systemctl restart pveproxy
</pre>
Il ne reste plus qu'a vérifier dans les logs si les bonnes adresses s'affichent:
<pre>
# tail -f /var/log/pveproxy/access.log
</pre>
Si jamais ce n'est pas le cas, poursuivez avec la modification du fichier ''AnyEvent.pm''
== Modification de AnyEvent.pm ==
=== Application de la modification ===
Au jours d'aujourd'hui (13/12/25) la proxification ne fonctionne plus et il faut apporter une modification dans le fichier ''/usr/share/perl5/PVE/APIServer/AnyEvent.pm'' pour que les bonnes adresses apparaissent !
En fonction des versions cette modifications peut avoir lieu soit ligne '''1504''', soit ligne '''1554'''.

Il faut repérer la fonction suivante:
<source lang=perl>
sub authenticate_and_handle_request {
my ($self, $reqstate) = @_;

my $request = $reqstate->{request};
my $method = $request->method();

...
</source>
C'est un peu plus loin qu'il faut insérer le code :
<source lang=perl>
}
}

### INSERTION ICI ###

if ($self->{spiceproxy}) {
my $connect_str = $request->header('Host');

</source>
Il faut modifier l'attribut ''peer_host'' de l'objet ''reqstate'' si l'une des deux entêtes est présente :
<source lang=perl>
if ($request->header('X-Forwarded-For')) {
$reqstate->{peer_host} = $request->header('X-Forwarded-For');
} elsif ($request->header('X-Real-IP')) {
$reqstate->{peer_host} = $request->header('X-Real-IP');
}
</source>
=== Double IPs ===
Après redémarrage, cela permet de voir l'adresse du client dans les logs :
<pre>
# tail -f /var/log/pveproxy/access.log
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/ext-all.js?ver=7.0.0 HTTP/1.1" 200 683505
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/js/u2f-api.js HTTP/1.1" 200 4898
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /proxmoxlib.js?ver=v5.0.4-t1754316706 HTTP/1.1" 200 157086
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_1.css HTTP/1.1" 200 32919
37.167.182.207, 37.167.182.207 - - [13/12/2025:18:48:18 +0100] "GET /pve2/ext6/theme-crisp/resources/theme-crisp-all_2.css HTTP/1.1" 200 6217
</pre>
L'adresses apparaît non pas une fois mais deux, séparée par une virgule...

On a deux possibilités pour se débarrasser de la virgule ainsi que de la deuxième adresse :
*Soit on ajoute les lignes suivantes dans ''AnyEvent.pm'':
<source lang=perl>
if (index($reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, $reqstate->{peer_host};
$reqstate->{peer_host} = $fields[0];
}
</source>
*Soit on modifie le filtre /etc/fail2ban/filter.d/proxmox.conf pour ajouter '',.*'' après ''<HOST>'' :
<pre>
...
failregex = pvedaemon\[.*authentication failure; rhost=<HOST>,.* user=.* msg=.*
...
</pre>
=== Automatisation ===
On peut automatiser le processus précédent avec le script suivant :

<source lang=bash>
#!/bin/bash

ANYEVENT_PATH="/usr/share/perl5/PVE/APIServer/AnyEvent.pm"
ANYEVENT_REGEX='$self->{spiceproxy}'
TMP_FILE="/tmp/AnyEvent.pm.tmp"

if [ ! -f $ANYEVENT_PATH ]; then
echo "$ANYEVENT_PATH does not exists !"
exit 1
fi

if [ $(grep '### BUGFIX REMOTE_IP FOR FAIL2BAN ###' $ANYEVENT_PATH | wc -l) -eq 1 ]; then
echo "AnyEvent.pm already patched !"
exit 0
fi

LINE_NUMBER_TOP=$(nl -ba $ANYEVENT_PATH | grep $ANYEVENT_REGEX | head -n 1 | awk -F ' ' '{print $1}')
let LINE_NUMBER_TOP-=1

if [ $LINE_NUMBER_TOP -lt 0 ]; then
echo "Did not find the $ANYEVENT_REGEX expr in $ANYEVENT_PATH"
exit 1
fi

echo -n "Applying bugfix: "
trap "rm -f $TMP_FILE" 0 1 2 5 13 15
head -n $LINE_NUMBER_TOP $ANYEVENT_PATH >$TMP_FILE
cat >>$TMP_FILE <<EOF
### BUGFIX REMOTE_IP FOR FAIL2BAN ###
if (\$request->header('X-Forwarded-For')) {
\$reqstate->{peer_host} = \$request->header('X-Forwarded-For');
} elsif (\$request->header('X-Real-IP')) {
\$reqstate->{peer_host} = \$request->header('X-Real-IP');
}
if (index(\$reqstate->{peer_host}, ',') != -1) {
my @fields = split /,/, \$reqstate->{peer_host};
\$reqstate->{peer_host} = \$fields[0];
}
#####################################
EOF
echo "$ANYEVENT_MODIF" >>$TMP_FILE
cp $ANYEVENT_PATH $ANYEVENT_PATH.ori
LINE_NUMBER_BOTTOM=$(cat $ANYEVENT_PATH | wc -l)
let LINE_NUMBER_BOTTOM-=LINE_NUMBER_TOP
tail -n $LINE_NUMBER_BOTTOM $ANYEVENT_PATH >>$TMP_FILE
cat $TMP_FILE >$ANYEVENT_PATH
rm -f $TMP_FILE
trap 0
echo "done."
</source>