# LPIC Séance 1
## ulimit & /etc/security/limits.conf
ulimit est une commande linux permettant de limiter les ressources utilisées par un processus. Pour une modification permanente des limites, le fichier /etc/security/limits.conf peut être modifié.
* **Quelle est la différence entre une "soft limit" et une "hard limit" ?**
La principale différence entre les limites souples et strictes se trouve dans la flexibilité qu'elles offrent. Les limites souples sont les limites par défaut et peuvent être augmentées jusqu'à la limite stricte, tandis que les limites strictes représentent les limites maximales que les utilisateurs ne peuvent pas dépasser. Les limites strictes sont mises en place pour garantir que les ressources système sont bien gérées et que les processus individuels ne monopolisent de manière excessive ces ressources.
* **Afficher les limitations des ressources pour deux utilisateurs, idéalement de nature différente. Que voyez-vous ?**
Nous pouvons voir des différences notamment dans les deux catégories : open files et cpu time :
* Proposez une raison pour avoir des limitations différentes suivant les utilisateurs.
Sécurité, cloisonnement, prévention des risques
* **Regroupez de manière pertinente en différentes catégories les ressources pouvant être limitées.**
On retrouve environ 4 différentes catégories concernant les ressources qui peuvent être limitées.
1. Limites du processeur :
Limites de temps CPU (ulimit -t)
Limites de temps d'exécution (ulimit -t)
Limite du nombre de processus par utilisateur (nproc)
2. Limites de la mémoire :
Limite de la taille de la mémoire virtuelle (ulimit -v)
Limite de la taille de la mémoire résidente (ulimit -m)
3. Limites du système de fichiers :
Limite de la taille des fichiers créés (fsize)
Limite du nombre de descripteurs de fichiers (nofile)
Limite du nombre de verrous de fichiers (locks)
4. Limites de l'utilisateur :
Limite du nombre de processus (ulimit -u)
Limite du nombre de fichiers ouverts (ulimit -n)
Définition de limites spécifiques pour certains groupes d'utilisateurs ou d'applications dans "/etc/security/limits.conf".
Définition de limites spécifiques pour chaque utilisateur dans "/etc/security/limits.conf".
* **Choisissez 1 catégorie. Concevez un exemple (notamment un programme) permettant de tester le bon fonctionnement des limites de ressources**
Afin de tester le bon fonctionnement des limites de ressources nous allons utiliser la catégorie "Limites du système de fichiers" avec notamment la limite du nombre de descripteurs de fichiers
Ce script Bash teste la limite de descripteurs de fichiers en essayant d'ouvrir un grand nombre de descripteurs de fichiers jusqu'à ce que la limite soit atteinte
```
#!/bin/bash
# Limite de descripteurs de fichiers (nofile) à tester
limite=20
# Fonction pour essayer d'ouvrir des fichiers jusqu'à atteindre la limite
tester_limite() {
for ((i=0; i<limite; i++)); do
exec {fd}<> /dev/null
if [ $? -ne 0 ]; then
echo "Impossible d'ouvrir le descripteur de fichier $i."
break
fi
done
echo "Atteint la limite de $limite descripteurs de fichiers."
}
# Afficher la limite actuelle
echo "Limite actuelle de descripteurs de fichiers (nofile): $(ulimit -n)"
# Appeler la fonction pour tester la limite
tester_limite
# Remarque : Si vous atteignez la limite, le script affichera un message approprié.
```
Résultat :
* **Est-il possible de savoir a posteriori qu'une limite a été atteinte ?**
Oui, il est possible de savoir a posteriori qu'une limite de descripteurs de fichiers a été atteinte en examinant les journaux système (logs) de l'OS. Pour vérifier cela, nous pouvons utiliser la commande suivante (après avoir démarré le service rsyslog):
```
grep --color -rni "Too many open files" /var/log/
```
* **Peut-on lancer un processus qui ne dépendra pas de ulimit ?**
Les limites de ressources définies par ulimit s'appliquent généralement à tous les processus d'un utilisateur. En revanche, il existe des exceptions pour les processus qui nécessitent des ressources accrues et qui sont gérés différemment. Par exemple, les processus lancés par l'utilisateur root peuvent contourner certaines limites de ressources, mais cela peut compromettre la stabilité et la sécurité du système.
## Cgroups
cgroups est une fonctionnalité du noyau linux permettant de limiter les ressources d'un groupe de processus de façon fine et flexible. L'ensemble des éléments de cette partie est à réaliser en utilisant le namespace "cgroup"
* **Identifiez où se trouve le namespace dans votre système**
```
user@debian-LPIC:~$ ls /sys/fs/cgroup
cgroup.controllers cgroup.procs cpu.pressure dev-hugepages.mount io.cost.qos memory.pressure proc-sys-fs-binfmt_misc.mount sys-kernel-tracing.mount
cgroup.max.depth cgroup.stat cpuset.cpus.effective dev-mqueue.mount io.pressure memory.reclaim sys-fs-fuse-connections.mount system.slice
cgroup.max.descendants cgroup.subtree_control cpuset.mems.effective init.scope io.stat memory.stat sys-kernel-config.mount user.slice
cgroup.pressure cgroup.threads cpu.stat io.cost.model memory.numa_stat misc.capacity sys-kernel-debug.mount
```
* **Affichez les cgroups dont fait parti un shell**
```
user@debian-LPIC:~$ cat /proc/self/cgroup
0::/user.slice/user-1000.slice/user@1000.service/app.slice/app-org.gnome.Terminal.slice/vte-spawn-45941cdd-7f9c-4ecd-893d-c5b380849f5b.scope
```
* **Listez les différentes catégories des ressources pouvant être limité avec cgroup**
- blkio
- cpu
- cpuacct
- cpuset
- devices
- freezer
- memory
- net_cls
- ns
* **Créez un un cgroup enfant**
```
root@debian-LPIC:/# mkdir /sys/fs/cgroup/my_cgroup
```
* **Affectez les controllers "io", "cpu" et "memory" au cgroup enfant**
```
root@debian-LPIC:/# cd /sys/fs/cgroup
root@debian-LPIC:/sys/fs/cgroup# echo "+io" > cgroup.subtree_control
```
Les controlleurs "cpu, "memory" et "pids" sont présent automatiquement à la création d'un cgroup enfant car présent dans cgroup.subtree_control. Il n'est pas possible de retirer "pids" car la ressource est occupé et donc en cours d'utilisation.
* **Concevez un exemple (notamment un programme) permettant de tester le bon fonctionnement des limites de ressources
**
## Systemd & libcgroup
Systemd utilise de façon extensive cgroups pour la gestion des processus. Il est ainsi possible d'utiliser systemd pour configurer de manière permanente les limitations de ressources.
* **Systemd, c'est quoi ?**
systemd est un remplaçant du démon init system V pour Linux. Il a pour but d'offrir une meilleure gestion des dépendances entre services, ainsi que de permettre le chargement en parallèle des services au démarrage. Cela permet réduire le temps de démarrage du système et de lancer moins de processus.
* **Qu'est ce qu'un "slice" pour Systemd ?**
Un fichier de configuration d'unité dont le nom se termine par ".slice" encode des informations sur une unité de tranche. Une unité de tranche est un concept permettant de gérer hiérarchiquement les ressources d'un groupe de processus. Cette gestion s'effectue en créant un nœud dans l'arbre des groupes de contrôle Linux (cgroup).
* **Expliquez le résultat de la commande "systemd-cgls"**
La commande systemd-cgls est une commande utilisée pour afficher une représentation hiérarchique des groupes de contrôle (cgroups) gérés par systemd sur un système Linux.
ex :
```
root@debian-LPIC:/# cd /sys/fs/cgroup
root@debian-LPIC:/sys/fs/cgroup# systemd-cgls
Working directory /sys/fs/cgroup:
├─user.slice (#179)
│ → user.invocation_id: d2490875c460410cbdda2a051f9d4ea2
│ → trusted.invocation_id: d2490875c460410cbdda2a051f9d4ea2
│ └─user-1000.slice (#4147)
│ → user.invocation_id: bb885b4abb994f5e8d2bdb3b292b3f87
│ → trusted.invocation_id: bb885b4abb994f5e8d2bdb3b292b3f87
│ ├─user@1000.service … (#4235)
│ │ → user.delegate: 1
│ │ → trusted.delegate: 1
│ │ → user.invocation_id: 137a6ec984e14078bff54b3be049cd01
│ │ → trusted.invocation_id: 137a6ec984e14078bff54b3be049cd01
│ │ ├─session.slice (#4367)
│ │ │ ├─gvfs-goa-volume-monitor.service (#5747)
│ │ │ │ └─1730 /usr/libexec/gvfs-goa-volume-monitor
│ │ │ ├─org.gnome.SettingsDaemon.MediaKeys.service (#6059)
│ │ │ │ └─1780 /usr/libexec/gsd-media-keys
│ │ │ ├─org.gnome.SettingsDaemon.Smartcard.service (#6293)
│ │ │ │ └─1793 /usr/libexec/gsd-smartcard
│ │ │ ├─xdg-permission-store.service (#5357)
│ │ │ │ └─1653 /usr/libexec/xdg-permission-store
│ │ │ ├─org.gnome.SettingsDaemon.Datetime.service (#5942)
│ │ │ │ └─1775 /usr/libexec/gsd-datetime
│ │ │ ├─xdg-document-portal.service (#6683)
│ │ │ │ ├─2083 /usr/libexec/xdg-document-portal
│ │ │ │ └─2095 fusermount3 -o rw,nosuid,nodev,fsname=portal,auto_unmount,subtype=portal -- /run/user/1000/doc
│ │ │ ├─org.gnome.SettingsDaemon.Housekeeping.service (#5981)
│ │ │ │ └─1776 /usr/libexec/gsd-housekeeping
│ │ │ ├─xdg-desktop-portal.service (#6644)
│ │ │ │ └─2075 /usr/libexec/xdg-desktop-portal
│ │ │ ├─org.freedesktop.IBus.session.GNOME.service (#5825)
│ │ │ │ ├─1759 sh -c /usr/bin/ibus-daemon --panel disable $([ "$XDG_SESSION_TYPE" = "x11" ] && echo "--xim")
│ │ │ │ ├─1779 /usr/bin/ibus-daemon --panel disable
│ │ │ │ ├─2034 /usr/libexec/ibus-memconf
│ │ │ │ ├─2035 /usr/libexec/ibus-extension-gtk3
│ │ │ │ └─2071 /usr/libexec/ibus-engine-simple
│ │ │ ├─pipewire-pulse.service (#4655)
│ │ │ │ └─1434 /usr/bin/pipewire-pulse
│ │ │ ├─org.gnome.SettingsDaemon.Keyboard.service (#6020)
│ │ │ │ └─1777 /usr/libexec/gsd-keyboard
│ │ │ ├─org.gnome.SettingsDaemon.A11ySettings.service (#5864)
│ │ │ │ └─1762 /usr/libexec/gsd-a11y-settings
│ │ │ ├─wireplumber.service (#4616)
│ │ │ │ └─1431 /usr/bin/wireplumber
│ │ │ ├─org.gnome.SettingsDaemon.Wacom.service (#6410)
│ │ │ │ └─1801 /usr/libexec/gsd-wacom
│ │ │ ├─gvfs-daemon.service (#4772)
│ │ │ │ ├─1449 /usr/libexec/gvfsd
│ │ │ │ ├─1465 /usr/libexec/gvfsd-fuse /run/user/1000/gvfs -f
│ │ │ │ └─2382 /usr/libexec/gvfsd-trash --spawner :1.8 /org/gtk/gvfs/exec_spaw/0
│ │ │ ├─gvfs-udisks2-volume-monitor.service (#5513)
│ │ │ │ └─1696 /usr/libexec/gvfs-udisks2-volume-monitor
│ │ │ ├─org.gnome.SettingsDaemon.Sharing.service (#6254)
│ │ │ │ └─1790 /usr/libexec/gsd-sharing
│ │ │ ├─org.gnome.SettingsDaemon.Color.service (#5903)
│ │ │ │ └─1763 /usr/libexec/gsd-color
│ │ │ ├─org.gnome.SettingsDaemon.ScreensaverProxy.service (#6215)
│ │ │ │ └─1789 /usr/libexec/gsd-screensaver-proxy
│ │ │ ├─org.gnome.SettingsDaemon.PrintNotifications.service (#6137)
│ │ │ │ ├─1785 /usr/libexec/gsd-print-notifications
│ │ │ │ └─2032 /usr/libexec/gsd-printer
│ │ │ ├─org.gnome.SettingsDaemon.Power.service (#6098)
│ │ │ │ └─1783 /usr/libexec/gsd-power
│ │ │ ├─org.gnome.Shell@wayland.service (#5201)
│ │ │ │ ├─1582 /usr/bin/gnome-shell
│ │ │ │ └─2056 /usr/bin/Xwayland :0 -rootless -noreset -accessx -core -auth /run/user/1000/.mutter-Xwaylandauth.9ORSB2 -listenfd 4 -listenfd 5 -displayfd 6 -initfd 7
│ │ │ ├─org.gnome.SettingsDaemon.XSettings.service (#6839)
│ │ │ │ ├─2142 /usr/libexec/gsd-xsettings
│ │ │ │ └─2195 /usr/libexec/ibus-x11
│ │ │ ├─gvfs-gphoto2-volume-monitor.service (#5591)
│ │ │ │ └─1714 /usr/libexec/gvfs-gphoto2-volume-monitor
│ │ │ ├─org.gnome.SettingsDaemon.UsbProtection.service (#6371)
│ │ │ │ └─1799 /usr/libexec/gsd-usb-protection
│ │ │ ├─gvfs-metadata.service (#5708)
│ │ │ │ └─1726 /usr/libexec/gvfsd-metadata
│ │ │ ├─org.gnome.SettingsDaemon.Sound.service (#6332)
│ │ │ │ └─1795 /usr/libexec/gsd-sound
│ │ │ ├─pipewire.service (#4538)
│ │ │ │ └─1426 /usr/bin/pipewire
│ │ │ ├─dbus.service (#4694)
│ │ │ │ ├─1438 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
```
etc ...
Cette sortie représente la hiérarchie des cgroups sur le système. Les cgroups sont organisés en une structure arborescente, et chaque niveau peut avoir des limites de ressources spécifiques.
* **Expliquez le résultat de la commande "systemd-cgtop"**
Cette commande permet de présenter les groupes de contrôle de façon ordonnée selon un des champs : CPU, mémoire, ou entrées/sorties disque. L'affichage est rafraichi à intervalles réguliers (par défaut toutes les secondes).
* **Editez la configuration de votre user pour avoir les délégations pour "cpu" et "io"**
commande : `systemctl --user show user-luc.slice`
* **Lancez un processus à l'intérieur d'un slice. Vérifiez que les ressources sont bien limitées.**
Lorsque l'on lance simplement le processus sans spécifier le slice on obtient ce résultat en terme de consommation CPU :
Lorsque qu'à l'inverse on spécifie la charge CPU, on obtient une limite correspondant à la limite éditer dans le fichier resource_limits.conf :
Commande `top` :
Commande `systemd-cgtop` :
## Mini rapport :
Sujet : Cgroups vs Docker :
Dans le contexte de la virtualisation et de la gestion des ressources dans les environnements Linux, les cgroups (control groups) et Docker jouent des rôles essentiels. Les cgroups sont une caractéristique du noyau Linux qui permet de gérer et de limiter les ressources système, tandis que Docker est une plateforme de conteneurisation populaire qui repose sur les cgroups pour fournir un environnement de conteneurs isolé.
### Cgroups
Les cgroups (control groups) sont une fonctionnalité du noyau Linux permettant de gérer et de limiter les ressources système pour différents groupes de processus. Voici les caractéristiques principales des cgroups :
**Gestion des ressources** : Les cgroups permettent de définir des limites et des quotas sur les ressources système telles que le CPU, la mémoire, la bande passante réseau, le disque, etc.
**Isolation** : Ils offrent une isolation entre les groupes de processus, garantissant que les ressources allouées à un groupe ne sont pas utilisées par d'autres groupes, ce qui évite la concurrence indésirable.
**Priorités** : Les cgroups permettent de définir des priorités pour l'accès aux ressources, ce qui peut être crucial dans des environnements multi-utilisateurs ou pour garantir les performances de certaines applications.
**Limitation des utilisateurs** : Ils peuvent être utilisés pour limiter l'utilisation des ressources par les utilisateurs, ce qui est utile pour empêcher qu'un utilisateur monopolise les ressources du système.
**Hiérarchie** : Les cgroups peuvent être organisés hiérarchiquement, ce qui permet une gestion des ressources plus granulaire et structurée.
**Reporting** : Ils fournissent des métriques et des statistiques sur l'utilisation des ressources, ce qui est utile pour la surveillance et le dépannage.
**Compatibilité avec d'autres technologies** : Les cgroups sont souvent utilisés avec d'autres technologies de virtualisation et de gestion de conteneurs, telles que Docker, pour garantir une gestion efficace des ressources.
### Docker
De son côté, Docker se repose sur les cgroups pour fonctionner en fournissant une couche d'abstraction conviviale pour créer, gérer et orchestrer des conteneurs d'applications. Les cgroups fournissent à Docker la capacité de gérer les ressources système, telles que le CPU, la mémoire, la bande passante réseau, permettant ainsi une utilisation efficace des ressources matérielles.
Docker étend également les fonctionnalités des cgroups en ajoutant la notion de conteneurs, ce qui permet d'isoler complètement les applications et leurs dépendances. Les conteneurs Docker encapsulent non seulement les processus, mais aussi le système de fichiers, les bibliothèques et les configurations nécessaires à l'exécution d'une application spécifique. Cette approche offre des avantages significatifs en termes de portabilité, de déploiement rapide et de gestion simplifiée des applications.
### Tableau des différences
Ainsi nous pouvons afficher le tableau des différences entre Docker et Cgroups suivant :
| Caractéristique | Cgroups | Docker |
|--------------------------------|------------------------------------------------|-------------------------------------------------|
| Fonction et Objectif | Gestion des ressources système | Conteneurisation d'applications |
| Niveau d'Abstraction | Bas niveau du noyau | Plus élevé, interface conviviale |
| Isolation vs Conteneurisation | Isolation des ressources pour les processus | Isolation et conteneurisation des applications |
| Portabilité | Spécifique au noyau Linux | Portabilité vers différentes distributions |
| Complexité | Nécessite une connaissance approfondie du système | Interface utilisateur conviviale |
| Utilisation | Principalement par les administrateurs système | Par les développeurs et administrateurs d'applications |
De ce fait, lors de la création d'un nouveau conteneur docker, il est possible de lui attribué des limitation de CPU (comme nous avons fait précédemment) directement dans la commande de création. Dans la commande il suffit d'ajouter simplement --cpuset-cpus=0 à la commande docker run. On peut également configurer les parts de CPU requises.
`$ docker run -d --name='luctest1' --cpuset-cpus=0 --cpu-shares=20 luctest1`
En résumé, les cgroups et Docker sont des technologies complémentaires, les cgroups fournissant un contrôle des ressources au niveau du noyau, tandis que Docker ajoute une couche d'abstraction conviviale pour créer des environnements d'application isolés et portables. Ils sont souvent utilisés ensemble pour fournir des solutions de conteneurisation efficaces dans le domaine de l'informatique moderne.
Actuellement, Kubernetes, un système open source de gestion d'orchestration de conteneurs, connaît une adoption croissante. C'est pourquoi il est intéressant d'explorer davantage comment Kubernetes peut être utilisé pour renforcer la sécurité des conteneurs et comment il complète les fonctionnalités des cgroups.
Google Drive
Gist
Clipboard
Sign in with Wallet
